-
Notifications
You must be signed in to change notification settings - Fork 14
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
Membership test fails if element is not in group #22
Comments
This is not just here, but in general -- the recognition trees do not test well for membership, if the element is outside the group. |
I'll just make a small list here:
|
Yes, this is a general problem, but also one that can be fixed in a relatively uniform manner. I have a pretty good idea what needs to be changed where. Let's see. |
BTW, you can also get it into a hissy fit if you look for a permutation in a matrix group, or vice versa. |
This resolves a few examples from issue #22
This resolves a few examples from issue #22
I think I was wrong, and instead of a "uniform" solution, what we have to do is to add lots of input validations to homomorphism methods. This then serves triple purpose:
I added some more of these checks in my recent commits. This takes care of your examples, I think. |
@fingolfin To expand on this: Every homomorphism Not sure whether this works always: If |
I am not sure what your example is meant to say, but I also don't see any serious issues here: One could indeed use two functions: one to perform general sanity checks, the other to compute the actual image under the morphism. The first function would e.g. filter out permutations or matrices over the wrong field; it might also filter out matrices which are unsuitable for other reasons (e.g. no diagonal, when the morphism expects diagonal matrices). Things that pass through still may be outside of the group we expect -- but the morphism should be applicable to them, and produce a valid result. So to stay with the diagonal subgroup example: If we so far only recognized a proper subgroup of the full diagonal subgroup, then applying the morphism to a diagonal matrix outside that proper subgroup may "work", but we'll later (e.g. when computing preimages) notice that something is amiss, and increase the generator set. This is fine, and essentially what happens right now anyway. The problems I fixed so far were really all of the kind were the matrix considered was not even diagonal; or it was diagonal, but over the wrong field; etc. -- i.e. all things which are cheap to check. It remains to be determined if having this functionality split across two functions is useful -- so far, I added all those checks to the homomorphisms and/or to functions which select the homomorphisms. If we split those checks off into separate / additional functions, then there should be a reason for that. I can't think of any right now, can you? Anyway, if we later come up with one, we can still do this then. |
I agree that this is something we can do down the road if we find it useful. My feeling is, that there are three steps involved in applying a homomorphism. The second step in your example would be to check that the given matrix is diagonal and this is what ensures that applying the homomorphism will be correct. All other checks would fall under "implementation details".
In contrast, what's to say that some of the more complicated recognition methods don't rely implicitly on other methods having been executed first, i.e. on the current ranking of the methods? That problem is somehow related to applying homomorphisms since the groups in the tree can grow. What do you think? About the sanity checks: it may make sense to define a |
An S_n acting on k-sets is recognised correctly:
But if I try to check membership of an element that is not in the group via
I get the following error:
I think the problem is that FindImageJellyfish does not check for its 'applicability'. I will have a look into that.
The text was updated successfully, but these errors were encountered: