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

bug in the table of marks with name "2.(A4xA4).2.2" #27

Closed
ThomasBreuer opened this issue Aug 8, 2019 · 1 comment · Fixed by #28
Closed

bug in the table of marks with name "2.(A4xA4).2.2" #27

ThomasBreuer opened this issue Aug 8, 2019 · 1 comment · Fixed by #28
Assignees
Labels
bug Something isn't working

Comments

@ThomasBreuer
Copy link

ThomasBreuer commented Aug 8, 2019

RepresentativeTom does not return the correct representatives, as two of them are conjugate:

gap> t:= TableOfMarks( "2.(A4xA4).2.2" );;
gap> g:= UnderlyingGroup( t );;
gap> IsConjugate( g, RepresentativeTom( t, 39 ), RepresentativeTom( t, 43 ) );
true

See my comment in gap-system/gap#3595,
apparently the stored representatives of the table of marks in question are not correct.

@olexandr-konovalov olexandr-konovalov added the bug Something isn't working label Aug 13, 2019
@fingolfin
Copy link
Member

@gpfeiffer @LiamNaughton I used the following stupid program to figure out which entry is wrong:

t:= TableOfMarks( "2.(A4xA4).2.2" );;
g:= UnderlyingGroup( t );;

# find subgroups of order 6
pos6:=Positions(OrdersTom(t), 6);
reps:=List([1..Maximum(pos6)], i -> RepresentativeTom(t,i));;
reps_cc:=List(reps, x -> ConjugacyClassSubgroups(g,x));;
subs:=SubsTom(t);
# verify table of marks for subgroups of order 6
for j in pos6 do 
    #
    real := Filtered([1..j], i -> ForAny(reps_cc[i], x->IsSubgroup(reps[j],x)));
    Print(j, ": ", subs[j], "  versus  ", real, "\n");
    if real <> subs[j] then
        Print("  MISMATCH!\n");
    fi;
od;

which prints

35: [ 1, 6, 9, 35 ]  versus  [ 1, 6, 9, 35 ]
36: [ 1, 3, 10, 36 ]  versus  [ 1, 3, 10, 36 ]
37: [ 1, 3, 9, 37 ]  versus  [ 1, 3, 9, 37 ]
38: [ 1, 2, 9, 38 ]  versus  [ 1, 2, 9, 38 ]
39: [ 1, 5, 10, 39 ]  versus  [ 1, 5, 10, 39 ]
40: [ 1, 2, 11, 40 ]  versus  [ 1, 2, 11, 40 ]
41: [ 1, 5, 9, 41 ]  versus  [ 1, 5, 9, 41 ]
42: [ 1, 7, 10, 42 ]  versus  [ 1, 7, 10, 42 ]
43: [ 1, 6, 10, 43 ]  versus  [ 1, 5, 10, 39, 43 ]
  MISMATCH!
44: [ 1, 8, 9, 44 ]  versus  [ 1, 8, 9, 44 ]
45: [ 1, 3, 11, 45 ]  versus  [ 1, 3, 11, 45 ]
46: [ 1, 8, 10, 46 ]  versus  [ 1, 8, 10, 46 ]
47: [ 1, 3, 9, 47 ]  versus  [ 1, 3, 9, 47 ]
48: [ 1, 2, 10, 48 ]  versus  [ 1, 2, 10, 48 ]
49: [ 1, 3, 10, 49 ]  versus  [ 1, 3, 10, 49 ]
50: [ 1, 7, 9, 50 ]  versus  [ 1, 7, 9, 50 ]

So the representative for class 43 is wrong. The following patch fixes it (I'll submit it as a PR, too):

diff --git a/data/tmunitam.tom b/data/tmunitam.tom
index af2bef6..5a6f944 100644
--- a/data/tmunitam.tom
+++ b/data/tmunitam.tom
@@ -1715,7 +1715,7 @@ LIBTOM( "2.(A4xA4).2.2",
 1]],[[1,-1,2,-1,1,1,2,1]]],[[[2,-1,1,1,2,-1,1,-1]]],[[[3,-1,1,-1,2,-1]]],[[[3,
 1],[4,1,1,1,4,-1,1,1]]],[[[1,1,2,1],[2,1,4,2]],[[1,-1,2,-1,1,1,2,1]]],[[[2,
 1],[3,1],[4,1,5,3,4,1,5,-1,4,1,5,-1]],[[2,1,1,-1,2,1,1,1,2,1,1,-1]]],[[[1,1,3,
-1],[4,2,2,1]]],[[[2,1,1,1]]],[[[3,1],[1,1,4,1,1,-1,4,-2]],[[1,-2,3,1]]],[[[2,
+-1,2,1]]],[[[2,1,1,1]]],[[[3,1],[1,1,4,1,1,-1,4,-2]],[[1,-2,3,1]]],[[[2,
 1],[3,1],[4,1,5,-1,4,-1,5,1,4,-1,5,-1]],[[1,1,2,1,1,1,2,1,1,-1,2,1]]],[[[3,
 1],[4,1,2,1],[5,2,4,-1]],[[1,-1,2,-1,1,1,2,1]]],[[[1,1,3,1],[4,1,2,-1,4,1,2,
 1]]],[[[3,1],[4,1,1,1,4,2,1,-1]],[[2,1,1,-1,2,-1,1,-2]]],[[[1,1,2,-1]]],[[[2,

Note that I did the naive thing for finding this:

b:=reps[10];
real_u43:=ClosureGroup(First(reps_cc[6], x -> Size(ClosureGroup(x,b))=6), b);
cc43 := ConjugacyClassSubgroups(g, real_u43);
# now take all possible generators...
cands:=Union(List(cc43, x -> Filtered(x, y -> Order(y)=6)));;
# try to factorize
for i in cands do Display(Factorization(g,i)); od;

Then I choose a short word that minimized the diff in the fix. In particular, I did not take heed of any other properties of the representative: as far as I could determined, tomlib makes no promise nor assumptions about the particular representatives which are used, correct?

In any case, a new release with this fixed should be made, no?

Also, perhaps an improved version of my test program above should be run on all the TOM data, to verify no similar bugs exist?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants