Make div-alg examples independent of character ordering

[olexandr-konovalov]

Repaired the examples in the div-alg.xml file for the manual. The examples should now be free of character numbering issues. In the examples now the characters used are the unique ones up to Galois conjugacy with kernels of a given size, so I added some lines that will determine this character. So the output should be consistent for the Schur index functions on all systems now.

[codecov[bot]]

Codecov Report

Merging #38 into master will decrease coverage by 0.1%. The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #38      +/-   ##
==========================================
- Coverage   74.84%   74.73%   -0.11%     
==========================================
  Files           8        8              
  Lines        3729     3729              
==========================================
- Hits         2791     2787       -4     
- Misses        938      942       +4

Impacted Files	Coverage Δ
lib/div-alg.gi	84.98% <0%> (-0.38%)	:arrow_down:

[olexandr-konovalov]

So, we have now two diffs left in tests with the master branch of GAP:

1) wedderga/doc/div-alg.xml:440-453

gap> G:=SmallGroup(480,600);
<pc group of size 480 with 7 generators>
gap> W:=WedderburnDecompositionInfo(GroupRing(Rationals,G));;
gap> Size(W); 
27
gap> W[27]; 
[ 1, NF(5,[ 1, 4 ]), 60, [ [ 2, 11, 0 ], [ 2, 19, 30 ], [ 2, 31, 30 ] ], 
  [ [ 0, 15 ], [ 45 ] ] ]

produces

[ 1, NF(5,[ 1, 4 ]), 60, [ [ 2, 11, 0 ], [ 2, 19, 30 ], [ 2, 31, 30 ] ], 
  [ [ 0, 45 ], [ 15 ] ] ]

instead - that seems fine, but

2) wedderga/doc/div-alg.xml:29-48

gap> G:=SmallGroup(48,15);
<pc group of size 48 with 5 generators>
gap> R:=GroupRing(Rationals,G);       
<algebra-with-one over Rationals, with 5 generators>
gap> WedderburnDecompositionInfo(R);
[ [ 1, Rationals ], [ 1, Rationals ], [ 1, Rationals ], [ 1, Rationals ], 
  [ 2, Rationals ], [ 1, Rationals, 3, [ 2, 2, 0 ] ], [ 2, CF(3) ], 
  [ 1, Rationals, 6, [ 2, 5, 0 ] ], [ 1, NF(8,[ 1, 7 ]), 8, [ 2, 7, 0 ] ], 
  [ 1, Rationals, 12, [ [ 2, 5, 3 ], [ 2, 7, 0 ] ], [ [ 3 ] ] ] ]

produces

[ [ 1, Rationals ], [ 1, Rationals ], [ 1, Rationals ], [ 1, Rationals ], 
  [ 1, Rationals, 3, [ 2, 2, 0 ] ], [ 1, Rationals, 4, [ 2, 3, 0 ] ], 
  [ 1, Rationals, 6, [ 2, 5, 0 ] ], [ 1, NF(8,[ 1, 7 ]), 8, [ 2, 7, 0 ] ], 
  [ 2, CF(3) ], [ 1, Rationals, 12, [ [ 2, 5, 3 ], [ 2, 7, 0 ] ], [ [ 3 ] ] ] 
 ]

which has different dimensions of components - ??? This example has been modified by Allen - are you sure that this is for the right group?

These two diffs are reproducible in GAP 4.8.10 as well.

[olexandr-konovalov]

As Allen explained by email:

The first diff is a typical randomization error. Hard to avoid all of these. We can just adjust the expected outcome to this.

The second diff likely results from Suganda's algorithms and the different ordering of characters. The [2,Rationals] in position 5 is isomorphic to the [1,Rationals, 4,[2,3,0]] component appearing in position 6, and the [2,CF(3)] component has moved from position 7 to position 9. So her algorithm gave a crossed product result instead of a matrix ring for one character - this can just result from different random ordering of elements within the group itself. And the character ordering can also change, all of these are coming from characters of degree 2. The new GAP version moved the ER(2) valued characters ahead of the ER(-3) valued ones.

[olexandr-konovalov]

I've now updated test output to match the actual one, and replaced loops in examples by

i:=First([1..Length(Irr(G))],i->Size(KernelOfCharacter(Irr(G)[i]))=1);;

and will merge this if the tests will pass.