Print group generators in detailed printing

[fingolfin]

This is an experiment to see what happens if we print the generators of groups, at least in "detailed" mode. I find it quite useful in some cases, but in others it is annoying. Would be interesting to know what others think about this.

[codecov]

Codecov Report

Merging #2878 (602eb9b) into master (f1f060f) will increase coverage by 0.27%.
Report is 6 commits behind head on master.
The diff coverage is 100.00%.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2878      +/-   ##
==========================================
+ Coverage   81.35%   81.63%   +0.27%     
==========================================
  Files         556      545      -11     
  Lines       74495    72788    -1707     
==========================================
- Hits        60604    59417    -1187     
+ Misses      13891    13371     -520     

Files	Coverage Δ
src/Combinatorics/Graphs/functions.jl	93.45% <ø> (ø)
src/Combinatorics/Matroids/matroids.jl	98.61% <ø> (ø)
src/Groups/GAPGroups.jl	93.08% <100.00%> (+0.42%)	⬆️
src/Groups/abelian_aut.jl	97.57% <ø> (ø)
src/Groups/action.jl	97.14% <ø> (ø)
src/Groups/cosets.jl	87.17% <ø> (ø)
src/Groups/directproducts.jl	94.59% <ø> (ø)
src/Groups/group_characters.jl	95.26% <ø> (ø)
src/Groups/group_constructors.jl	94.35% <ø> (ø)
src/Groups/gsets.jl	93.65% <ø> (ø)
... and 16 more

... and 20 files with indirect coverage changes

[lgoettgens]

This needs some change to be useful.

[fingolfin]

I think it is already useful (and compared to not showing anything, conveys infinitely more information). But of course it could be made even more useful :-)

[thofma]

I think this should have been the default in the first place.

Edit: When do you find it annoying?

[fingolfin]

@thofma I find it annoying when I have thirty 200x200 matrices as generators (this is not hypothetical, by the way...). So I'd really like a way to limit it based on the screen size...

Also, the generators of subgroups often are determined by randomized algorithms, which can make this kind of printing a PITA when used in doctests (in GAP frequently minor changes to algorithms require annoying changes to doctests -- even with machinery as we have it to update them semi-automatically, it's often a bother). Of course doctest filters may be able to help with that if we encounter it.

I also don't find it very helpful for pc groups where the are, say, 10 generators named f1 to f10. Perhaps I could add code that checks whether the names of the all the generators are short and then print them in a single line or so.

But none of these are insurmountable! (and I would not have made this PR if I was fundamentally opposed to this change, after all ;-)

[fingolfin]

The printing of the invariant ring should also be adjusted, I just did not yet get to that (CC @joschmitt)

[fingolfin]

Here it would be nice if there was a hint somewhere that a is the name of the generator of the cyclotomic field.

But I notice that the cyclotomic field has no option for printing that. Indeed, even its detailed printing omits the name of its generator:

julia> K, a = cyclotomic_field(3, "a")
(Cyclotomic field of order 3, a)

julia> K
Number field with defining polynomial _$^2 + _$ + 1
  over rational field

julia> gen(K)
a

In fact I am surprised to see that the detailed printing drops the hint that this is a cyclotomic field (I mean, of course one can see this from the defining polynomial, but in larger degrees I would not be able to recognize these reliably).

[fingolfin]

@ThomasBreuer do you have any thoughts on this, pro or contra?

[thofma]

I agree that for some complicated coefficient fields, the printing might not convey all the information, but I think this is outweighed by the advantages.

[ThomasBreuer]

I think that printing full information about group order and generators is meaningful at most for small examples.

For example, try atlas_group(MatrixGroup, "J3"): This is a group with 2 generators in dimension 80 over GF(2), probably nobody wants to see such matrices, except if one asks explicitly to look at them.
Or try sylow_subgroup(symmetric_group(100), 2)[1]: This group has 97 generators, almost nobody wants to see them.
(And then replace degree 100 by 1000 and see what happens.)

I think these examples are not artificially large, already the 10 by 10 matrices generating the group M11 (that occur in one of the examples) are not interesting enough to be shown if one just wants to work with the group.
Even beginners working with small groups will deal with such large permutations and matrices -- think of regular actions.

Let us compare the situation with that in GAP, where we had similar problems.

An answer was to distinguish between View (short output, not nec. GAP-readable) and Print (longer output, preferably GAP-readable); the main idea was that in the case of long output, full information shall be given only if the user asks for it, by calling Print.
And View tries to abbreviate permutations of large degree by showing only the first cycles and then ( [...] ); of course this does not help if the permutation consists only of one cycle.

The current situation in GAP may still be regarded as not convincing.
I remember of a discussion in which a user argued that in the case of View (that is, one has not explicitly asked for more output, presumably one just forgot to type the double semicolon that suppresses the output) the output should always be restricted to the first n lines and the last n lines, with ... in the middle, where n should be about 5.

[thofma]

If one does not care for the output in the first place, one can just use a ;.

[ThomasBreuer]

@thofma

If one does not care for the output in the first place, one can just use a ;.

This was one of the points in the abovementioned discussion in the GAP Forum: The user in question did not agree with the argument that typing one more semicolon would save him from many pages of annoying output. He wrote that this argument is the same as a statement somewhere in the fineprint that all one has to do in order to prevent the computer from blowing up is to push the "Dont't blow up" button before switching the machine on.

I understand this comparison as the verdict that a system should not only allow one to avoid obviously useless output but that avoiding such output should be the default.

[thofma]

A system has a default way of printing and there is an easy way to suppress it. Doesn't sound so complicated to me. A system should not try to decide what "useless" is. Why not just print "group"? Obviously in my application, this is all I need to know.

[ThomasBreuer]

@thofma
What about Julia's default to show vectors by restricting them to one screen?
For example, gens(sylow_subgroup(symmetric_group(100), 2)[1] is by default printed like this, the first entries followed by ⋮ followed by the last entries. This is still more than the mentioned GAP user wanted to see, but addresses his complaint to some extent.

[lgoettgens]

In my opinion, any reasonable "default" of printing should print at most one screen full of stuff. So in this sense, I really like the julia way of printing vectors.

[thofma]

The problem with ⋮ is that it is almost impossible to get the full information. Assume my group has too many generators (say 10) to fit into my terminal. With the ⋮ idea, we would only print 5 of them. How do I see all of them? If I do gens(G), it is a julia vector and again I have the ⋮ and not the full information. And now? I can do print, which is even less readable. Now what? I just want to see what all the elements are without writing a loop that prints everything. How hard can this be?

This ⋮ is all cute and nice and fancy, but too much magic which makes it frustrating to use.

[ThomasBreuer]

@thofma

The problem with ⋮ is that it is almost impossible to get the full information.

Good point.
However, I would say that this shows a missing functionality concerning (among others) vectors in Julia.
When I want to show a group G then usually I do not want to see all generators, but when I want to show gens(G) then this is in general the case.
Thus there should be a function that really shows the whole vector.

[simonbrandhorst]

I am in favor of the changes. For matrix groups of large degree (say >= 10) I would not print the matrices.

[fingolfin]

Note to self: also add suitable code to prevent lower casing for SL etc., as in this example:

julia> G = SL(2,5)
SL(2,5)

julia> T
Character table of sL(2,5)
...

Note the sL instead of SL