some == issues for group elements and related objects

[ThomasBreuer]

The change proposed in Nemocas/AbstractAlgebra.jl/pull/1853 has raised some questions about perhaps missing == methods in Oscar's code for groups.

• We have == methods for two BasisGAPGroupElems and for two MatrixGroupElems. Other cases were handled up to now by a generic method that returns false, but with Add generic == error Nemocas/AbstractAlgebra.jl#1853 we will have to deal with more cases. One addition can be a == method for two GAPGroupElems that returns false.
• A more subtle question (which is interesting independent of Add generic == error Nemocas/AbstractAlgebra.jl#1853) is about the relation between elements of automorphism groups and the corresponding group homomorphisms.
  • It is likely that users want to compare an automorphism group element and a group homomorphism via == --our tests contain already such cases. We want to return false (this happens now) or throw an exception (but then with a meaningful error message). Thus we need special methods for this situation.
  • It is documented that h in A shall return false for a group homomorphism h and a group A of automorphisms, also if there is an element of A that is equal to h as a map on A.
    If we want to keep this definition then what is a good way to decide if A(h) will throw an exception or return the corresponding element of A?
    (In the related situation g in H where H is a subgroup of the parent of g, we had decided that g in H should return true if H(g) would be successful, i.e., that g in H is the natural way to ask this question.)
  • A related question about elements of automorphism groups:
    They can be used as maps in the sense that they have a domain, and one can ask for images and preimages. But they aren't Maps (and they do not have a codomain) -- is there a good reason why?

[fingolfin]

One addition can be a == method for two GAPGroupElems that returns false.

But why do we need that, where do we compare group elems like that? The one legit case I can think of are PcGroupElems vs. SubPcGroupElems (and similar for fp groups) but for those we could provide dedicated methods?

[fieker]

On Thu, Oct 10, 2024 at 07:24:02AM -0700, Thomas Breuer wrote: The change proposed in Nemocas/AbstractAlgebra.jl#1853 has raised some questions about perhaps missing `==` methods in Oscar's code for groups. - We have `==` methods for two `BasisGAPGroupElem`s and for two `MatrixGroupElem`s. Other cases were handled up to now by a generic method that returns `false`, but with Nemocas/AbstractAlgebra.jl#1853 we will have to deal with more cases. One addition can be a `==` method for two `GAPGroupElem`s that returns `false`. - A more subtle question (which is interesting independent of Nemocas/AbstractAlgebra.jl#1853) is about the relation between elements of automorphism groups and the corresponding group homomorphisms. - It is likely that users want to compare an automorphism group element and a group homomorphism via `==` --our tests contain already such cases. We want to return `false` (this happens now) or throw an exception (but then with a meaningful error message). Thus we need special methods for this situation. - It is documented that `h in A` shall return `false` for a group homomorphism `h` and a group `A` of automorphisms, also if there is an element of `A` that is equal to `h` as a map on `A`. If we want to keep this definition then what is a good way to decide if `A(h)` will throw an exception or return the corresponding element of `A`? (In the related situation `g in H` where `H` is a subgroup of the parent of `g`, we had decided that `g in H` should return `true` if `H(g)` would be successful, i.e., that `g in H` is the natural way to ask this question.) - A related question about elements of automorphism groups: They can be used as maps in the sense that they have a `domain`, and one can ask for images and preimages. But they aren't `Map`s (and they do not have a `codomain`) -- is there a good reason why?

The entire design of the automorphim groups is dubious and against the "Oscar idea": the plan was to not have elements of the group act as automorphisms at all, but have the interpretation map in between, thus removing most of those questions. I think this needs revisiting

…

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

[ThomasBreuer]

But why do we need that,

For consistency reasons:

julia> g = symmetric_group(3)  # perm. group
Sym(3)

julia> h = small_group(24,12)  # pc group
Pc group of order 24

julia> m = GL(2,3)  # matrix group
GL(2,3)

julia> g[1] == h[1]  # the method for BasisGAPGroupElem
false

julia> g[1] == m[1]  # the generic method from AbstractAlgebra
ERROR: == is not implemented for the given types
[...]

Either we forbid g[1] == h[1], or we let g[1] == m[1] return false.

[fieker]

We need to forbid the spurious "false", in general they mask programming errors

[ThomasBreuer]

We need to forbid the spurious "false", in general they mask programming errors

O.k., then the breaking change from Nemocas/AbstractAlgebra.jl#1853 is the right opportunity for this change. I will create a pull request for that.