Recog An/Sn unknown degree: conder, holt#265
Conversation
5ae5367 to
d40a988
Compare
|
Rebased the last commit onto the current version of #176. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #265 +/- ##
==========================================
+ Coverage 69.12% 70.48% +1.35%
==========================================
Files 43 43
Lines 18321 18637 +316
==========================================
+ Hits 12665 13136 +471
+ Misses 5656 5501 -155
🚀 New features to boost your workflow:
|
d40a988 to
dc4a895
Compare
dc4a895 to
f162f36
Compare
cca25fd to
35a39de
Compare
|
Link to our Hackmd |
96f9a25 to
705504c
Compare
e63f4a8 to
956884d
Compare
|
We should be almost done. We think there are two TODOs left: clean up the tests and figure out what to do with small classical groups like: And get the tests to pass again. :) And in Make CallMethods directly write into the RecogNode update the docs of And, @FriedrichRober is writing a short text, how all the parts fit together, that is how our implementation differs from a "vanilla" implementation of the JLNP algorithm according to the paper. |
3b12114 to
daceec3
Compare
|
Awesome, thank you! |
|
@FriedrichRober do you think you can finish this on your own, now that @ssiccha is gone? Perhaps I can help a bit? |
|
Yes, I think I can finish this on my own. The code is finished (except for handling small classical groups). What is missing now is to finish the documentation (comments) and looking at the runtime of the test suite. |
d45adbb to
7ba5ec6
Compare
85ca56f to
deb2974
Compare
|
@fingolfin, ich habe nun die Änderungen implementiert, wie wir es besprochen haben. Wir geben früher auf, und speichern uns die Iteratoren im recog node ab, um sie später weiter zu verwenden. Trotzdem dauert die Test-Suite auf meinem Rechner 3-4 Minuten länger als auf dem master. Meiner Meinung nach ist dieser Zustand inakzeptabel, um das einfach so zu mergen :( Ich muss dann nochmal genau schauen, an welchen Stellen wir zu viel Zeit verschwenden, und ob sich da was machen lässt. |
|
I am finished with my review. Everything looks good, so I think we can merge as seen as all comments above are resolved. I think this PR will resolve #348, but correct me if I am wrong. |
| # - slpToStdGens: an SLP from the generators of G to stdGens. | ||
| RECOG.ConstructSnAnIsomorphism := function(ri, n, stdGensAnWithMemory) | ||
| local stdGensAn, xis, gImage, foundOddPermutation, slp, eval, | ||
| local stdGensAn, filter, filterPart, gImage, foundOddPermutation, slp, eval, |
There was a problem hiding this comment.
Why is this called filter? It is neither a filter in GAP's sense, nor in the mathematical sense (think "ultrafilter") nor do any of the sources use this term. I find it rather confusing.
There was a problem hiding this comment.
If I remember correctly, we used the word "filter" because the xis act like a sieve or filtering mechanism on the search space for finding the image points. But any renaming would be fine here :)
| # Construct filter. In <Cite Key="C12"/> filter is called E. | ||
| # In <Cite Key="JLNP13"/> filter is called `xi`. |
There was a problem hiding this comment.
It would be better if we had more concrete refs (so to specific definitions/lemmas); as it is we could not quite tell which "xi" or "Xi" or "X_i" or "x_i" are meant exactly.
I also note that RECOG.ConstructXiAn comes from the older code written for the paper by Beals et all (BLN+03 here?), so perhaps that is also a reference?
(Of course the fact that RECOG.ConstructXiAn in turn is undocumented doesn't help either...)
There was a problem hiding this comment.
Yes, this is indeed from BLN+03. It is introduced in prose, so has no reference, and then is used for the first time in Lemma 5.3. If n>=11, then this filter can be used to find the image under the homomorphism. For degree <11, we had to use Conder's algorithm for the image computation, which works for degree>=5.
Co-authored-by: Torben Wiedemann <7226617+TWiedemann@users.noreply.github.com> Co-authored-by: Max Horn <max@quendi.de>
| ## ---------------- | ||
| ## | ||
| ## Here we describe the general strategy that is used to recognise if a group | ||
| ## is ismorphic to `An` or `Sn` for `n >= 7`. |
There was a problem hiding this comment.
But below when defining SnAnUnknownDegree (around line 1355ff), it is stated that this method is for
And then there is the code in RECOG.SnAnUpperBoundForDegree which kinda seems to suggest we might have to assume
There was a problem hiding this comment.
Let me check this quickly so you don’t end up on a wild goose chase.
There was a problem hiding this comment.
I think we can recognise groups with degree n>=7, and that groups with degree 5 or 6 cannot be recognised.
Details:
- Lower Bounds need n >= 9:
This is just to satisfy the error-probabilities, and has no impact on the correctness of the algorithm. - Bolstering Elements are only defined for n >= 7:
This is the crucial point, which I think would lead to the algorithm returning fail for smaller degrees. - In SnAnUpperBoundForDegree:
- For the projective groups, the relevant bounds are only defined for n≥9. To handle all cases, we set N:=max(8,d+2). When the actual degree is at least 9, we use the corresponding bound; otherwise, we assume the worst case, namely degree at most 8. Hence, the argument remains valid for all degrees.
- Same holds for non-projective matrix groups with n>=10.
| ## | ||
| ## We have to be careful what we do for small degrees. | ||
| ## If we pass an `A5`, `S5`, `A6`, `S6` into `SnAnUnknownDegree`, then it will not recognize it. | ||
| ## If the input acts on a space with a large dimension, then this can take forever. |
There was a problem hiding this comment.
Is that last bit still the case? If so, a concrete example would be good so we can better guard against it (i.e., an example could be used in a test that verifies that whatever "guards" we use are effective)
There was a problem hiding this comment.
I think it will not anymore run forever, since I adjusted the code to return fail more quickly. But I agree that a test case would be nice to confirm this, see my comment about bolstering elements only being defined for n>=7.
There was a problem hiding this comment.
Anyway, I also think that the SnAnUnknownDegree code assumes that the input is irreducible (because it runs after FindHomMethodsProjective.NotAbsolutelyIrred in the recog framework, etc.), so these examples that Sergio and I thought of as problematic should not be passed as input to SnAnUnknownDegree at this stage.
| ## If we pass an `A5`, `S5`, `A6`, `S6` into `SnAnUnknownDegree`, then it will not recognize it. | ||
| ## If the input acts on a space with a large dimension, then this can take forever. | ||
| ## | ||
| ## - We assume that our input group `G` is a projective irreducible matrix group. |
There was a problem hiding this comment.
Ah, OK. That might partially address my concern from above about RECOG.SnAnUpperBoundForDegree requiring
| # FindHomMethodsGeneric.SnAnUnknownDegree | ||
| # Sn | ||
| gap> for d in [11 .. 30] do | ||
| > sets := Combinations([1 .. d], 2);; | ||
| > SdOn2Sets := Action(SymmetricGroup(d), sets, OnSets);; | ||
| > ri := RecogNode(SdOn2Sets);; | ||
| > success := FindHomMethodsGeneric.SnAnUnknownDegree(ri); | ||
| > if not success or not Size(ri) = Factorial(d) then | ||
| > Print("wrong result! degree ", d, "\n"); | ||
| > fi; | ||
| > od; | ||
|
|
||
| # An | ||
| gap> for d in [11 .. 30] do | ||
| > sets := Combinations([1 .. d], 2);; | ||
| > SdOn2Sets := Action(AlternatingGroup(d), sets, OnSets);; | ||
| > ri := RecogNode(SdOn2Sets);; | ||
| > success := FindHomMethodsGeneric.SnAnUnknownDegree(ri); | ||
| > if not success or not Size(ri) = Factorial(d)/2 then | ||
| > Print("wrong result! degree ", d, "\n"); | ||
| > fi; | ||
| > od; |
There was a problem hiding this comment.
Removing this will result in quite a loss of coverage. Why do we do it?
Co-authored-by: Torben Wiedemann <7226617+TWiedemann@users.noreply.github.com>
Co-authored-by: Torben Wiedemann <7226617+TWiedemann@users.noreply.github.com> Co-authored-by: Martin Wagner <martin.wagner.dev@gmail.com>
A PR based on #176.
We are going to implement the extensions by Conder and Derek Holt's
GuessAltSymDegree.