Allow inducing G-sets along group homomorphisms#4921
Allow inducing G-sets along group homomorphisms#4921lgoettgens merged 5 commits intooscar-system:masterfrom
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #4921 +/- ##
==========================================
- Coverage 84.93% 84.92% -0.01%
==========================================
Files 686 686
Lines 92260 92277 +17
==========================================
+ Hits 78361 78370 +9
- Misses 13899 13907 +8
🚀 New features to boost your workflow:
|
|
In the example my interpretation of the documentation is that We could "unpack" (If we are instead interested in an |
Indeed, good catch. I opted to use
I am not quite sure which of the two scenarios is the correct one for my use-case (in the cases of non-surjective homs). But just to make sure: With the now updated code, I could compute the |
|
Concerning the idea to document The manual is not good enough in this respect: The section "Group homomorphisms" talks only about |
Yes. However, if one is interested just in one particular H-orbit, it might be cheaper to compute this directly, without creating the perhaps much too large H-set |
Indeed. My idea for that would be to add a function |
Yes. |
|
I now added |
ThomasBreuer
left a comment
There was a problem hiding this comment.
Good.
(I am a bit surprised that comparing the two functions with == works.)
As discussed earlier today with @ThomasBreuer. I tried to align the name and argument order with the methods for
GAPClassFunctionandGModule.Due to not all group types having usable morphism types, I added an undocumented method for general maps between groups, which should get adapted once we have proper group homes.
@jamesnohilly this allows for a similar cleanup of
action_homomorphismin #4609 as forFinGenAbGroups in this PR. Depending on the order these two PRs get merged, the later one should perform the cleanup.