My attention was recently drawn to GeneralRestrictedMapping, which is in the library but undocumented. Unfortunately it only seems to work in certain situations -- essentially when you are restricting the Range of a mapping to a set that still includes its ImagesSource, or includes at least one image of each source point or something.
I discussed this briefly with Alexander Hulpke, whose code it is. He said
"in general the functions for restricted and corestricted mappings are a mess and probably need redesign. The proper way of fixing it might be to separate the declaration of a mapping from the actual image mechanism — the latter currently sometimes implicitly assumes that it is defined for the `Source’ group.
Part of this is the dichotomy between catching illegal input and running in code with guaranteed valid input. If the homomorphism is between permutation groups and given by a stabilizer chain the validity test comes almost for free — in other situations (such as forcibly restricted maps) it has a cost. A function `ImagesRepresentativeNC’ (or so) might be the way out, but then the set or recommended operations becomes long and messy.
Even worse is the situation for e.g. matrix groups where for some homomorphisms the image is very cheap, but a membership test might be very expensive.
In short, the mechanism for homomorphisms and what are basic operations might need a rethink. I’d be happy to participate if anyone was interested."
My attention was recently drawn to GeneralRestrictedMapping, which is in the library but undocumented. Unfortunately it only seems to work in certain situations -- essentially when you are restricting the Range of a mapping to a set that still includes its ImagesSource, or includes at least one image of each source point or something.
Otherwise things like this happen:
I discussed this briefly with Alexander Hulpke, whose code it is. He said
"in general the functions for restricted and corestricted mappings are a mess and probably need redesign. The proper way of fixing it might be to separate the declaration of a mapping from the actual image mechanism — the latter currently sometimes implicitly assumes that it is defined for the `Source’ group.
Part of this is the dichotomy between catching illegal input and running in code with guaranteed valid input. If the homomorphism is between permutation groups and given by a stabilizer chain the validity test comes almost for free — in other situations (such as forcibly restricted maps) it has a cost. A function `ImagesRepresentativeNC’ (or so) might be the way out, but then the set or recommended operations becomes long and messy.
Even worse is the situation for e.g. matrix groups where for some homomorphisms the image is very cheap, but a membership test might be very expensive.
In short, the mechanism for homomorphisms and what are basic operations might need a rethink. I’d be happy to participate if anyone was interested."