Skip to content
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.

Sign up for GitHub

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

Jump to bottom

WIP: Add test for NiceMonomorphismByDomain #38

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

WIP: Add test for NiceMonomorphismByDomain #38

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 17 additions & 0 deletions tst/misc.tst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
#
gap> START_TEST("misc.tst");

# test NiceMonomorphism for subgeometries, which uses hash tables
gap> pg := PG(1,5^4);
ProjectiveSpace(1, 625)
gap> sub := CanonicalSubgeometryOfProjectiveSpace(pg, GF(5));
Subgeometry PG(1, 5) of ProjectiveSpace(1, 625)
gap> g := CollineationGroup(sub);
The FinInG collineation group PGL(2,5) of Subgeometry PG(1, 5) of ProjectiveSpace(1, 625)
gap> Size(g);
480
gap> Number([1..10], i -> PseudoRandom(g) in g);
10
Comment on lines +5 to +14
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dug a bit and this is the problem: the test elm in g above is implemented by this method:

InstallMethod( \in,
    "by nice monomorphism",
    IsElmsColls,
    [ IsMultiplicativeElementWithInverse,
      IsGroup and IsHandledByNiceMonomorphism ],
    0,

function( elm, G )
    local   nice,  img;
 
    nice := NiceMonomorphism( G );
    img  := ImagesRepresentative( nice, elm:actioncanfail:=true );
    return img<>fail and img in NiceObject( G )
       and PreImagesRepresentative( nice, img ) = elm;
end );

Now everything works fine until the final check PreImagesRepresentative( nice, img ) = elm;. Here we observe this:

gap> elm2:=PreImagesRepresentative( nice, img );
< a collineation: <cmat 2x2 over GF(5,4)>, F^125>
gap> elm=elm2;
false
gap> NamesOfComponents(elm);
[ "mat", "fld", "frob" ]
gap> elm!.mat = elm2!.mat;
true
gap> elm!.fld = elm2!.fld;
true
gap> elm!.frob = elm2!.frob;
false
gap> elm!.frob ; elm2!.frob;
FrobeniusAutomorphism( GF(5^4) )
FrobeniusAutomorphism( GF(5^4) )^3

So, yeah: those preimages are not equal. The differ on pg -- but they are equal when restricted to the subspace sub, which is only defined over GF(5) after all. So those two induce a monomorphism there after all.

So CollineationGroup(sub); returns a group generated by collineations of the parent geometry. But two such collineations of pg, when restricted to sub, might induce identical maps (e.g. the identity on pg and the Frobenius automorphismonpgboth induce the identity onsub`).

Based on this, I think the real problem is that the Frobenius of GF(5^4) is used as a generator for the subgeometry. I'll see if I can fix that

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some discussion mentioning CollineationGroup and issues with nice monomorphisms in the package manual, but I don't understand what it says... sigh

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Upon re-reading a few times, I think I get it now: applied to our example, where the subgeometry sub of $PG(1,GF(5^4))$ is isomorphic to $PG(1,GF(5))$, it says that the collineation group of sub is defined to be a certain conjugate of the collineation group of $PG(1,GF(5))$?

I think this is meant to deal with subgeometries isomorphic to $PG(1,GF(5))$ but different from the "canonical" (with respect to the standard frame) copy of $PG(1,GF(5))$. But in the example here, this is already the group in question.

So more is going on: indeed, the collineation group here is $PGL(2,5)$, isn't it, of size 120. But the collineation group the code produces has size 480. Indeed, what we actually get is the collineation group we are looking for but extended by the Frobenius of the large field $GF(5^4)$, which has order 4.

If we just omit that generator, we actually get the "right" group. But that won't work for e.g. $PG(1,GF(5^2))$, because there we need a Frobenius of $GF(5^2)$; but that just isn't an element of the "big" group $P\Gamma(2,GF(5^4))$ -- indeed I don't think $P\Gamma(1,GF(5^2))$ is a subgroup of $P\Gamma(2,GF(5^4))$ (at least not in a "natural" way). That's because the Frobenius $f_{5^2}$ of $GF(5^2)$ has two "lifts" to $GF(5^4)$, both of order 4, namely $f_{5^4}$ and $f_{5^2}^3=f_{5^2}^{-1}$... the group generated by $f_{5^2}$ is a quotient of $f_{5^4}$ but the quotient map has no section...

OK, so maybe this is intentional, and the collineation group of the subgeometry is meant to be given "extended by the Frobenius of the parent geometry" ? But that really should be in the documentation then? (Maybe it is, but then I didn't find it, and would appreciate pointers as to where I can read more).

If the intent is to use this "extended" collineation group, then a possible fix for the issue here would be to tweak NiceMonomorphismByDomain to extend the group action to also consider the full "Frobenius" part separately (what I mean is this: right now we use the action on AsList(Points(geom)). We could add to this the orbit of a primitive element of the large field under the action of just the Frobenius part of each collineation (i.e. collineation!.frob).

Alternatively, a bigger change would be to drop the illusion that the collineation group of the subgeometry is a subgroup of the collineation group of the parent geometry. This is wrong in this example here and also wrong in general, so I am not sure why the code seemingly attempts to pretend otherwise?


#
gap> STOP_TEST("misc.tst", 10000 );
1 change: 1 addition & 0 deletions tst/testall.g
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,6 +6,7 @@ pkgdir := DirectoriesPackageLibrary( pkgname, "tst" );
# Arrange chapters as required
testfiles := [
"bugfix.tst",
"misc.tst",
"tst_regular13system.tst",
"tst_segrevariety.tst",
"tst_hermitianspreads.tst",
Expand Down
Loading