Difference in handling of non-identical parent groups in MapFromFunc and hom

[TWiedemann]

Describe the bug

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

julia> f(x) = x
f (generic function with 1 method)

julia> fmap = MapFromFunc(G, G, f)
Map defined by a julia-function
  from Sym(4)
  to Sym(4)

julia> g = cperm(G, [1,2,3,4])
(1,2,3,4)

julia> h = cperm([1,2,3,4])
(1,2,3,4)

julia> image(fmap, g)
(1,2,3,4)

julia> image(fmap, h)
ERROR: ArgumentError: Element not in the domain
Stacktrace:
 [1] macro expansion
   @ ~/.julia/packages/AbstractAlgebra/eNeG2/src/Assertions.jl:599 [inlined]
 [2] image(f::MapFromFunc{PermGroup, PermGroup}, x::PermGroupElem)
   @ Hecke ~/.julia/packages/Hecke/xmbZn/src/Map/MapType.jl:194
 [3] top-level scope
   @ REPL[10]:1

Expected behavior
I would expect image(fmap, g) to produce the same result as image(fmap, h). The documentation of cperm states that the parent of h should be set to symmetric_group(4), which is G, so there should not be a difference between g and h. Indeed:

julia> g == h
true

Further, the error message "Element not in the domain" is confusing because

julia> h in domain(fmap)
true

In contrast, hom works as I would expect:

julia> fhom = hom(G, G, f)
Group homomorphism
  from Sym(4)
  to Sym(4)

julia> image(fhom, g)
(1,2,3,4)

julia> image(fhom, h)
(1,2,3,4)

julia> image(fhom, g) == image(fhom, h)
true

System (please complete the following information):

julia> Oscar.versioninfo(full=true)
OSCAR version 1.2.2
  combining:
    AbstractAlgebra.jl   v0.43.12
    GAP.jl               v0.12.3
    Hecke.jl             v0.34.9
    Nemo.jl              v0.47.5
    Polymake.jl          v0.11.24
    Singular.jl          v0.23.10
  building on:
    FLINT_jll               v300.100.301+0
    GAP_jll                 v400.1300.102+2
    Singular_jll            v404.0.711+0
    libpolymake_julia_jll   v0.13.0+0
    libsingular_julia_jll   v0.46.1+0
    polymake_jll            v400.1300.2+0
See `]st -m` for a full list of dependencies.

Julia Version 1.11.2
Commit 5e9a32e7af2 (2024-12-01 20:02 UTC)
Build Info:
  Official https://julialang.org/ release
Platform Info:
  OS: Linux (x86_64-linux-gnu)
  CPU: 12 × 12th Gen Intel(R) Core(TM) i5-12400
  WORD_SIZE: 64
  LLVM: libLLVM-16.0.6 (ORCJIT, alderlake)
Threads: 1 default, 0 interactive, 1 GC (on 12 virtual cores)
Official https://julialang.org/ release

[joschmitt]

I think the problem is that the parent of h is equal to G but not identical:

julia> parent(h)  == G
true

julia> parent(h)  === G
false

I would say that MapFromFunc behaves as expected.

[TWiedemann]

Then, in contrast, is the behaviour of hom unexpected? I have no opinion whether G and H in

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

julia> H = symmetric_group(4)
Sym(4)

should be considered the same or as distinct copies of Sym(4) (and this is surely a design decision which has already been made long ago), but it is not clear to me why hom should work in one way and MapFromFunc the other way.

[fieker]

On Thu, Jan 09, 2025 at 03:09:13AM -0800, Torben Wiedemann wrote: Then, in contrast, is the behaviour of `hom` unexpected? I have no opinion whether `G` and `H` in ``` julia> G = symmetric_group(4) Sym(4) julia> H = symmetric_group(4) Sym(4) ``` should be considered the same or as distinct copies of Sym(4) (and this is surely a design decision which has already been made long ago), but it is not clear to me why `hom` should work in one way and `MapFromFunc` the other way.

My guess is that hom here defaults to gap. In gap Sn = Sn. MapFromFunc is pure Oscar, here Sn !== Sn (deliberately) and the 1st is to check if the element is in the domain.... I'd call this sloppyness in the hom case Also: symmetric_group possibly should have a "chached=true/false" option

…

-- Reply to this email directly or view it on GitHub: #4432 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[fingolfin]

Adding a cached=true/false option to symmetric_group would perhaps hide the problem, but not solve it?

See also #129 (from 2020...)

[fieker]

image for gap-homs is lazy/ generous/ wrong:

function image(f::MapFromFunc, x)
  @req parent(x) === domain(f) "Element not in the domain"
  y = f.f(x)
  @req parent(y) === codomain(f) "Image not in the codomain"
  return y::elem_type(codomain(f))
end

does the checks, but

function image(f::GAPGroupHomomorphism, x::GAPGroupElem)
  return group_element(codomain(f), GAPWrap.ImagesRepresentative(GapObj(f), GapObj(x)))
end

checks nothing on the input, in fact forgets the parent and just chages the parent to the correct one on exit.
There are different issues here

• ghom would succeed even when non-sensical: U = sub(G, [one(g)])[1], then hom(U, G, f)(h) works even if it clearly shouldn't, even better: hom(U, U, f)(h) gives h in U back...
• should there be different Sn's around and how to handle them?