-
Notifications
You must be signed in to change notification settings - Fork 161
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inconsistent generating sets #1239
Comments
I don't know where the function I don't think the first issue is a bug per-se. If you call The point being that with a subgroup of a group we can still deduce what kind of generators this subgroup has none of. |
These kinds of "groups with no generators" also come out all the time in intersection problems:
I do find them annoying, because |
We could certainly change diff --git a/grp/basicprm.gi b/grp/basicprm.gi
index ffe1790d7..c9a075a86 100644
--- a/grp/basicprm.gi
+++ b/grp/basicprm.gi
@@ -18,7 +18,7 @@ InstallMethod( TrivialGroupCons,
"perm group",
[ IsPermGroup and IsFinite ],
function( filter )
- filter:= Group( () );
+ filter:= GroupByGenerators( [], () );
SetIsTrivial( filter, true );
return filter;
end ); Note that dealing with groups with zero generators indeed has caused troubles several times in the past, because code as not expecting it -- but despite that, I think it's fine to return an empty generating set for trivial groups: In virtually all cases, adding support for trivial group was easy (and the empty set often lead to runtime errors, which I prefer over code silently failing, which easily happens when there is a single trivial generator)... |
@ChrisJefferson |
@markuspf sorry, please read "GeneratorsOfGroup". @fingolfin I think indeed that the code should be written in such a way that it always accepts 0-generated objects, and it's more consistent that trivial groups always have 0 generators. I believe @ChrisJefferson's argument about intersections is actually in favour of making sure that 0-generated groups are properly handled everywhere, better to fix the other places than to artificially add the trivial element as generator of the intersection. (John Conway calls wanting to avoid this "zerophobia"). |
With PR #1247, one gets
|
Great!
Though, wouldn't it be even better to also change the printing routines to
show Group() and Group([],()) respectively?
|
|
Definitely! I meant Group() for ViewString and Group ([],()) for String and
DisplayString, so as to recreate at object with 0 generators.
|
Of course it could still happen in other calculations to end up with a trivial group that has (possibly multiple) generators, so any code needs to be more careful. |
The original "issue" (?) reported here was resolved some time ago. This leaves the suggestion for printing, which I now put into a fresh issue, so that it is not forgotten, see #2036 |
This was reported by @laurentbartholdi in #1238
There's another bug, or at least annoyance, in that trivial permutation groups sometimes have 0 generators and sometimes 1:
Note that ViewString always prints the identity () as a generator, but String does not.
The text was updated successfully, but these errors were encountered: