oscar-system / Oscar.jl

A comprehensive open source computer algebra system for computations in algebra, geometry, and number theory.
https://www.oscar-system.org
Other
344 stars 126 forks source link

provide automorphism groups that do not consist of automorphisms #4237

Open ThomasBreuer opened 3 days ago

ThomasBreuer commented 3 days ago

@fieker had mentioned in the discussion of #4191 that he would like to get an implementation of "abstract" automorphism groups in the sense that their elements are not "concrete" automorphisms of the given object; instead one should ask for the corresponding map of an element if one wants to compute images and preimages under this map.

For that, we could for example define that for a group G, automorphism_group(G; abstract = false) returns A, mp where A is some group isomorphic with the full automorphism group of G, and mp is a map that takes an element of A and returns the group isomorphism on G that corresponds to this element.

For finite groups with underlying GAP group, this can be implemented via GAP's NiceMonomorphism mechanism that delegates computations with the automorphism maps on the GAP side to another (isomorphic) group, typically (always?) a permutation group. We can choose A as this permutation group, and implement mp via the data that are already used by GAP.

Once the questions about the syntax have been decided, I will provide a pull request for the implementation.

thofma commented 3 days ago

I touched upon these points 3 years ago in https://github.com/oscar-system/Oscar.jl/issues/920 and back then we seemed to be happy with AutomorphismGroup etc. What has changed?

As far as I understand, our design for the automorphism groups means that one should do A = automorphism_group(G); mp = isomorphism(PermGroup, A)?

Having different behavior for automorphism_group(PermGroup, G) and automorphism_group(G) seems undesirable from a user point of view.

fieker commented 3 days ago

On Wed, Oct 23, 2024 at 07:05:17AM -0700, Tommy Hofmann wrote:

I touched upon these points 3 years ago in https://github.com/oscar-system/Oscar.jl/issues/920 and back then we seemed to be happy with AutomorphismGroup etc. What has changed?

As far as I understand, our design for the automorphism groups means that one should do A = automorphism_group(G); mp = isomorphism(PermGroup, A)?

Nothing was changed, but a couple of automorphism groups were added by people without reading...

The "Plan" always was, and still is, to provide a useful group (perm, fp, pc) and an "interpretation map" uniformly.

Some things are "just" copied over from Gap

-- Reply to this email directly or view it on GitHub: https://github.com/oscar-system/Oscar.jl/issues/4237#issuecomment-2432321269 You are receiving this because you were mentioned.

Message ID: @.***>

ThomasBreuer commented 1 day ago

@fieker Concerning the plan you mention, one solution would be an interface like the following.

function Hecke.automorphism_group(::Type{PermGroup}, G::Oscar.GAPGroup)
    A = GAP.Globals.AutomorphismGroup(GapObj(G))
    nice = GAP.Globals.NiceMonomorphism(A)
    img = GAP.Globals.ImagesSource(nice)  # this gets computed here!
    res = Oscar._oscar_group(img)
    Oscar.set_attribute!(res, :interpret_as_automorphism => (G, nice))
    return res
end

function interpretation_map(P::PermGroup)
    att = Oscar.get_attribute(P, :interpret_as_automorphism)
    @req att !== nothing "the group was not created with `automorphism_group`"
    (G, nice) = att
    range = GAP.Globals.Range(nice)

    f = function(x::PermGroupElem)
      xx = GapObj(x)
      xx in range || error("x has no preimage")  
      pre = GAP.Globals.PreImagesRepresentative(nice, xx)
      pre === GAP.Globals.fail && error("x has no preimage")
      return GAPGroupHomomorphism(G, G, pre)
    end

    g = function(x::GAPGroupHomomorphism)
      img = GAP.Globals.ImagesRepresentative(nice, GapObj(x))
      return Oscar.group_element(P, img)
    end

#   return MapFromFunc(P, ?, f, g)
    return (f, g)
end

(It would be more elegant to return a Map object, but what should be its codomain?)

Then the following would work.

julia> G = symmetric_group(6)
Sym(6)

julia> P = automorphism_group(PermGroup, G)
Permutation group of degree 30

julia> f, g = interpretation_map(P);

julia> x = gens(P)[1]
(1,27,11,7,4,2)(3,23,10,15,8,5)(6,19,9)(12,28)(13,24,26,18,16,29)(14,20,30)(17,25,22)

julia> y = f(x)
Group homomorphism
  from Sym(6)
  to Sym(6)

julia> x == g(y)
true

This would even be compatible with the current automorphism_group.

thofma commented 1 day ago

The codomain could just be some artificial object "Set of automorphisms of blabla" without mathematical structure. This is done for example for number fields:

julia> K, a = cyclotomic_field(7, :a);

julia> A, m = automorphism_group(PermGroup, K);

julia> codomain(m)
Set of automorphisms of Cyclotomic field of order 7

julia> m(one(A))
Map
  from cyclotomic field of order 7
  to cyclotomic field of order 7

julia> parent(ans)
Set of automorphisms of Cyclotomic field of order 7

It could be the same object we would use to make the following work:

julia> id_hom(A)
Group homomorphism
  from permutation group of degree 6
  to permutation group of degree 6

julia> parent(ans)
ERROR: MethodError: no method matching parent(::GAPGroupHomomorphism{PermGroup, PermGroup})

I am skeptical about the interpretation_map approach.

fieker commented 1 day ago

On Fri, Oct 25, 2024 at 06:27:54AM -0700, Tommy Hofmann wrote:

The codomain could just be some artificial object "Set of automorphisms of blabla" without mathematical structure. This is done for example for number fields:

julia> K, a = cyclotomic_field(7, :a);

julia> A, m = automorphism_group(PermGroup, K);

julia> codomain(m)
Set of automorphisms of Cyclotomic field of order 7

julia> m(one(A))
Map
  from cyclotomic field of order 7
  to cyclotomic field of order 7

julia> parent(ans)
Set of automorphisms of Cyclotomic field of order 7

It could be the same object we would use to make the following work:

julia> id_hom(A)
Group homomorphism
  from permutation group of degree 6
  to permutation group of degree 6

julia> parent(ans)
ERROR: MethodError: no method matching parent(::GAPGroupHomomorphism{PermGroup, PermGroup})

Hecke.MapParent(dom, codom, "typ")

I am skeptical about the interpretation_map approach. So am I - in particular, as it is a second step. I'd really like the map to be automatically returned as a 2nd return value - unless s.o. has a compelling argument against it

-- Reply to this email directly or view it on GitHub: https://github.com/oscar-system/Oscar.jl/issues/4237#issuecomment-2437780657 You are receiving this because you were mentioned.

Message ID: @.***>