Adjust printing of GAP groups & group homomorphism to follow OSCAR printing guidelines

[fingolfin]

... as described in https://docs.oscar-system.org/dev/DeveloperDocumentation/printing_details/ (with fixes in PR #2769).

Right now I see this:

julia> H, phi = derived_subgroup(symmetric_group(5))
(Alt( [ 1 .. 5 ] ), Group homomorphism from
Alt( [ 1 .. 5 ] )
to
Sym( [ 1 .. 5 ] ))

julia> phi
Group homomorphism from
Alt( [ 1 .. 5 ] )
to
Sym( [ 1 .. 5 ] )

Note that phi prints the same in all "modes" (detailed, oneline, supercompact)

Based on this discussion I think it rather should look something like this:

julia> phi  # detailed
Group homomorphism
  from Alt( [ 1 .. 5 ] )
  to Sym( [ 1 .. 5 ] )

julia> print(phi)  # oneline
Hom: permutation group -> permutation group

julia> print(IOContext(stdout, :supercompact => true), phi)
Group homomorphism

Of course the above example also assumes that we implement the three modes for permutation groups, and then logically also for other kinds of groups. So that should be tackled at the same time.

[lgoettgens]

I would really like the oneline printing to state the category we are in in the beginning. So e.g. Group hom: ..., as this is already the beginning of the other two printing styles.

[ThomasBreuer]

I support the comment

I would really like the oneline printing to state the category we are in in the beginning. So e.g. Group hom: ..., as this is already the beginning of the other two printing styles.

As long as all homomorphisms respect the structure of domain and codomain, one could argue that the shown description of domain and codomain says what kind of homomorphism the map in question is. I think we will have to support also homomorphisms for which domain and codomain have different structures, and then the meaning of "homomorphism" is not obvious.

(Same for #2773.)

[fingolfin]

I think we will have to support also homomorphisms for which domain and codomain have different structures, and then the meaning of "homomorphism" is not obvious.

One could argue that a homomorphism by definition is a map between two objects in a single category. Of course I can look at maps from e.g. a group into a matrix algebra, but that's then not a homomorphism.

Anyway: the HackMD says "Hom:" and that was already a compromise after a lot of discussion.

In principle I am happy to change it to something else, but that should not be done unilaterally here but in coordination with other areas. At the very least I'd check in with @simonbrandhorst @thofma @fieker .

[simonbrandhorst]

The precise category can be very complicated. Maybe too complicated for compact printing? For instance we have R-algebra homomorphisms, then to state the category one also needs the ring R.

[lgoettgens]

The precise category can be very complicated. Maybe too complicated for compact printing? For instance we have R-algebra homomorphisms, then to state the category one also needs the ring R.

That's true. But currently, the supercompact printing shows more regarding that than the online printing.

[fingolfin]

I don't think it is reasonable to expect that reasonably compact printing can fully specify a homomorphism. If we ever are in a situation where knowing the domain and codomain of a "homomorphism" is not enough to determine what kind of morphism it is (e.g. a map between two QQ-algebras could be a ring morphism aka ZZ-algebra-morphism, or a QQ-algebra-morphism), and we need to know what it is (so some "magic code" we don't know or understand gave it to us? Or what is the scenario?) then we probably need to add functions that allow querying this, e.g. is_algebra_morphism(hom) and another function to get the "coefficient ring" (ZZ or QQ in my "example").

But again, I think this kind of discussion is way beyond the scope of this PR. We agreed on "Hom: domain -> codomain", so that's what I'd like to implement now. If people wish to revise this, I welcome that, but please do it on a new issue or the discussion board or during one of our meetings...

[simonbrandhorst]

Agreed.

[fingolfin]

The precise category can be very complicated. Maybe too complicated for compact printing? For instance we have R-algebra homomorphisms, then to state the category one also needs the ring R.

That's true. But currently, the supercompact printing shows more regarding that than the online printing.

Does it? when I see Hom: perm group -> perm group then the only conclusion I can draw is that this must be a morphism between groups...

(Anyway, if you look at the HackMD, you'll see that I actually argued against the "Hom:" style (and its predecessor, "Map:"), as it seems inconsistent... But I'll live with the compromise for now: once this is in place, it'll be relatively easy to replace the "Hom:" with something else and better, if someone has a bright idea :-)

[fingolfin]

Some further ideas, from discussions on PR #2774:

Of course we can also take inspiration from Magma and Sage and GAP...

Magma:

> Sym(6);
Symmetric group acting on a set of cardinality 6
Order = 720 = 2^4 * 3^2 * 5

so a special name, and the order is also printed factorized, which I guess can be quite handy. Or here:

> H, map := PermutationGroup< 9 | (1,2,4)(5,6,8)(3,9,7), (4,5,6)(7,9,8) >;
> H;
Permutation group H acting on a set of cardinality 9
    (1, 2, 4)(3, 9, 7)(5, 6, 8)
    (4, 5, 6)(7, 9, 8)

So the generators are still printed in this detailed form... But they are hidden in "compact" form, e.g. when printing the map:

> map;
Mapping from: GrpPerm: H to GrpPerm: $, Degree 9, Order 2^7 * 3^4 * 5 * 7

Note the use of H and $ which are the "names" of the group in the session. We can see this when we assign a name to the codomain

> Codomain(map);
Symmetric group acting on a set of cardinality 9
Order = 362880 = 2^7 * 3^4 * 5 * 7
> U := Codomain(map);
> map;
Mapping from: GrpPerm: H to GrpPerm: U

(In our system, assigning a name would drop the GrpPerm / Permutation group bit)

(Should look at how they handle pc and fp groups later, too; and perhaps also look at Sage... well, and GAP, but I know that / that's basically what we are using right now)

---

Also, I think in detailed view it might make sense to print generators again, at least in some cases, e.g. for permutation groups; and for matrix groups it would be nice, but the matrices should be printed "in 2D"

[joschmitt]

Also, I think in detailed view it might make sense to print generators again, at least in some cases, e.g. for permutation groups; and for matrix groups it would be nice, but the matrices should be printed "in 2D"

I don't think I have a say in this, but I would be in favour of printing the generators for the detailed mode. Otherwise one cannot distinguish two matrix groups defined over the same field and of the same degree in the REPL. (Of course I can always ask for gens, I'm just saying that the current detailed printing is in my opinion too vague to be helpful.)

(As I already said in https://github.com/oscar-system/Oscar.jl/pull/2774#discussion_r1331731648, I don't like the idea of printing matrices folded up. Especially if the degree is larger, this will wrap around and becomes unreadable (to me). But our documentation of the detailed printing mode says

• the number of output lines should fit in the terminal

so you can ignore this opinion.)