Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Printing groups #5699

Open
ThomasBreuer opened this issue Apr 6, 2024 · 1 comment
Open

Printing groups #5699

ThomasBreuer opened this issue Apr 6, 2024 · 1 comment

Comments

@ThomasBreuer
Copy link
Contributor

In a message to the GAP Forum, Leonard Soicher mentioned that printing certain groups in GAP looks strange.

gap> G:=OnePrimitiveGroup(NrMovedPoints,7,Size,21);                   
7:3
gap> Print(G);
7:3
gap> View(G);
7:3
gap> Display(G);                                                      
7:3
gap> PrintString(G);
"Group( \>[ (2,4,6)(3,5,7), (1,2,4,3,6,7,5) ]\<\> )\<"
gap> ViewString(G);
"7:3"
gap> DisplayString(G);
"<object>\n"

For the sake of simplicity, let us consider just View, Print, and Display.
(In order to implement a solution, once we agree on it, of course ViewString, PrintString, and DisplayString have to be adjusted accordingly.)

First, the reason for the above output is that OnePrimitiveGroup sets the Name attribute of its output.
The documentation of Name says the following.

‣ Name( obj ) ──────────────────────────────────────────────────── attribute
  
  returns the name, a string, previously assigned to obj via a call to SetName
  (12.8-1). The name of an object is used only for viewing the object via this
  name.
  
  There  are no methods installed for computing names of objects, but the name
  may be set for suitable objects, using SetName (12.8-1).

According to this text, I would say that the Print and Display output shown above are not o.k.
The documentation of Print says that often the output is GAP readable in the sense that reading it will reconstruct the object, and this is how Leaonard wants to use Print in this situation.
Besides that, my interpretation of the text is that SetName should be called only by users, not inside functions like OnePrimitiveGroup.

The attribute StructureDescription gives an example how one can affect only the View result without interfering with Name: If the attribute StructureDescription is set for a group then a ViewObj method that shows its value is applicable, but still the known Name value has priority. A known StructureDescription value does not affect Print and Display.
(One could get the idea to change OnePrimitiveGroup to set StructureDescription instead of Name. I think this would not be o.k. because StructureDescription promises a certain format of its output.)

@ThomasBreuer
Copy link
Contributor Author

O.k., there is no consensus yet how to solve the problem.
So we have to decide what we want. I see the following alternatives.

  1. Keep the current PrintObj method that uses with high priority a stored Name value, document this behaviour, and change the primgrp package such that PrimitiveGroup does no longer set Name.
  2. Remove the current PrintObj method that uses with high priority a stored Name value, state clearly in the documentation that a known Name is used by View but never by Print, and adjust all places in the library (and packages) where Name is currently set in order to be used by Print; as sketched above, this holds for global objects such as Rationals.
  3. Replace the current PrintObj method that uses with high priority a stored Name value by one that uses a stored Name value only in special situations. For example, we can introduce a new filter IsPrintedViaName, and the PrintObj method becomes applicable only for objects in this filter. Then we can set this filter for Rationals etc., in order to get the old behaviour for these objects. We should then recommend that IsPrintedViaName gets set only interactively or in functions that create objects such as Rationals.

(Or are there perhaps better ideas?)

Variant 1. means an easy change in the documentation plus a request to change the primgrp package.
Variant 2. requires to decide how the Print behaviour for objects such as Rationals shall be implemented; variant 3. would be an answer to this question.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant