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

Problem with computation of maximal subgroups in an almost simple group, possible bug in MaxesAlmostSimple? #681

Closed
RamonEstebanRomero opened this issue Mar 19, 2016 · 5 comments
Labels
kind: bug: unexpected error Issues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them kind: bug Issues describing general bugs, and PRs fixing them
Milestone

Comments

@RamonEstebanRomero
Copy link
Contributor

Dear colleagues,

Sorry if I am not using this system in a proper way for bug reports, this is the first time I do it.

The following group is an almost simple group with socle isomorphic to PSL(3,4). When I try to compute the conjugacy classes of maximal subgroups with MaximalSubgroupClassReps or ConjugacyClassesMaximalSubgroups I get an error.

gap> g:=Group(
> [ (3,5,4)(7,8,9)(10,18,14)(11,20,17)(12,21,15)(13,19,16)(22,32,41)(24,36,
>     29)(25,40,33)(26,28,37)(30,42,34)(31,35,39),
>   (1,2,7,3,11,10,6)(4,15,20,21,13,18,9)(5,19,17,16,12,14,8)(22,34,39,40,29,
>     32,28)(23,27,33,37,42,35,38)(24,26,36,30,31,25,41),
>   (7,8,9)(10,14,18)(11,16,21)(12,17,19)(13,15,20)(22,28,29)(24,32,37)(25,40,
>     33)(26,36,41)(31,39,35), (1,38)(2,23)(3,42)(4,34)(5,30)(6,27)(7,33)(8,
>     40)(9,25)(10,35)(11,37)(12,36)(13,22)(14,39)(15,29)(16,32)(17,26)(18,
>     31)(19,41)(20,28)(21,24) ]);
<permutation group with 4 generators>
gap> MaximalSubgroupClassReps(g);         
Error, <G> must be simple called from
IsomorphismTypeInfoFiniteSimpleGroup( G ) at /home/estebanr/Baixades/gap4r8/grp/simple.gi:814 called from
DataAboutSimpleGroup( G ) at /home/estebanr/Baixades/gap4r8/lib/maxsub.gi:537 called from
MaxesAlmostSimple( ImagesSource( act[2] ) ) at /home/estebanr/Baixades/gap4r8/lib/maxsub.gi:831 called from
<function "DoMaxesTF">( <arguments> )
 called from read-eval loop at line 54 of *stdin*
you can 'quit;' to quit to outer loop, or
you can 'return;' to continue

It seems that the possible problem is in the function MaxesAlmostSimple.

brk> Print(MaxesAlmostSimple, "\n");
function ( G )
    local  id, m, epi;
    if IsNaturalSymmetricGroup( G ) or IsNaturalAlternatingGroup( G )  then
        Info( InfoLattice, 1, "MaxesAlmostSimple: Use S_n/A_n" );
        return MaximalSubgroupClassReps( G );
    fi;
    m := TomDataMaxesAlmostSimple( G );
    if m <> fail  then
        return m;
    fi;
    id := DataAboutSimpleGroup( G );
    if id.idSimple.series = "A"  then
        Info( InfoWarning, 1, "Alternating recognition needed!" );
    elif id.idSimple.series = "L"  then
        m := ClassicalMaximals( "L", id.idSimple.parameter[1], id.idSimple.parameter[2] );
        if m <> fail  then
            epi := EpimorphismFromClassical( G );
            if epi <> fail  then
                m := List( m, function ( x )
                        return SubgroupNC( Range( epi ), List( GeneratorsOfGroup( x ), function ( y )
                                  return ImageElm( epi, y );
                              end ) );
                    end );
                return m;
            fi;
        fi;
    fi;
    if ValueOption( "cheap" ) = true  then
        return [  ];
    fi;
    Info( InfoLattice, 1, "MaxesAlmostSimple: Fallback to lattice" );
    return MaxesByLattice( G );
end

It seems that the function is assuming that the group is simple instead of almost simple. I have been able to compute the maximal subgroups with MaxesByLattice.

Can you please check whether something is wrong? I am using GAP version 4.8.2.

All the best,

Ramon Esteban-Romero.

@markuspf
Copy link
Member

This is absolutely the correct place to file bug reports.

I suspect that the line that goes

id :=   DataAboutSimpleGroup(G);

should use the minimal normal subgroup of G. I am sure @hulpke knows how to fix this, but I can also go and find how the maximal subgroup computation should continue here.

@markuspf markuspf added kind: bug Issues describing general bugs, and PRs fixing them kind: bug: unexpected error Issues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them labels Mar 20, 2016
@markuspf markuspf added this to the GAP 4.8.4 milestone Mar 20, 2016
@markuspf
Copy link
Member

By the way, using github markdown you can format your report more nicely using the "code" environment. I have edited your post accordingly to make it more easily readable.

@RamonEstebanRomero
Copy link
Contributor Author

Thank you, @markuspf. I also think that perhaps that line should refer to the minimal normal subgroup of the almost simple group.

All the best,

Ramón.

hulpke added a commit to hulpke/gap that referenced this issue Mar 20, 2016
@hulpke
Copy link
Contributor

hulpke commented Mar 20, 2016

No, the is a case that currently (until we have proper `ClassicalMaximals') should only be called if the group is simple. I will submit a fix.

@olexandr-konovalov
Copy link
Member

Fixed in PR #682.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug: unexpected error Issues describing bugs in which computation unexpectedly encounters an error, and PRs fixing them kind: bug Issues describing general bugs, and PRs fixing them
Projects
None yet
Development

No branches or pull requests

4 participants