gap-system
Some fixes concerning matrices and polynomials over large prime fields (related to issue #4901)
Do not merge, consider and review #4983 (we do not close this yet because of the discussion)
I stumbled over more problems with matrices and polynomials over Integers mod p for large p. Some problems were already reported in "Algebraic extensions in large characteristic broken #4901".
I could now trace back some of the problems to calls of ImmutableMatrix in the library, which internally calls Matrix and DefaultMatrixRepForBaseDomain. This lead to some places where objects (algebraic extensions, groups, ...) suddenly have stored attributes in IsMatrixObj which do not interact properly (e.g., with "classical" vectors and matrices, that is
lists and lists of lists).
This pull request disables for now the use of IsZmodnZMatrixObj as a default representation (see issue #4901 for some discussion).
After that the default representation became IsPlistMatrixRep and running the tests in tst/testinstall.g also showed various problems with this representation. We add a few missing methods and some other changes which fix the problems shown in the current test suite.
It is very likely that there are more bugs and missing methods in this area. It is not the aim of this pull request to resolve these problems more thoroughly. But at least is resolves the concrete bugs which I found while working on the StandardFF package.
The commit messages contain further details.
Text for release notes
none (Probably not a topic for CHANGES because this does not concern code that was in 4.11.)
\
Ok, there seems to be another test file tst/teststandard/opers/Matobjnz.tst with errors.
I have just traced one of these errors and it leads to the problem I have mentioned (and not solved) in my commit messages:
It is due to a call of ImmutableVector inside the MeatAxe code which yields a vector in IsPlistVectorRep in an environment where all other vectors and matrices are not in IsVectorObj/IsMatrixObj .
gap> p := NextPrimeInt(10^10);;
gap> F := GF(p);;
gap> mat := One(F)*[[1,2],[3,4]];
[ [ ZmodpZObj( 1, 10000000019 ), ZmodpZObj( 2, 10000000019 ) ],
[ ZmodpZObj( 3, 10000000019 ), ZmodpZObj( 4, 10000000019 ) ] ]
gap> v := mat[1];
[ ZmodpZObj( 1, 10000000019 ), ZmodpZObj( 2, 10000000019 ) ]
gap> vp := ImmutableVector(F, v);
<immutable plist vector over GF(10000000019) of length 2>
gap> v * mat;
[ ZmodpZObj( 7, 10000000019 ), ZmodpZObj( 10, 10000000019 ) ]
gap> w := vp * mat;
<immutable plist vector over GF(10000000019) of length 2>
gap> w[1];
[ [ ZmodpZObj( 1, 10000000019 ), ZmodpZObj( 2, 10000000019 ) ],
[ ZmodpZObj( 3, 10000000019 ), ZmodpZObj( 4, 10000000019 ) ] ]
gap> w[2];
[ [ ZmodpZObj( 2, 10000000019 ), ZmodpZObj( 4, 10000000019 ) ],
[ ZmodpZObj( 6, 10000000019 ), ZmodpZObj( 8, 10000000019 ) ] ]
I'm not sure about a good solution.
(A) Installing more methods for mixed arithmetic??? That probably leads to more new problems than it solves. For example, it is not clear what the type of the result should be. (This is the approach that is partially taken in lib/matobjnz.gi and which lead to problems I try to address with this pull request.)
(B) Maybe ImmutableMatrix and ImmutableVector should always return a matrix or vector in the same representation as the input? In particular when called on list of lists matrices it should not return an object in IsMatrixObj. Such objects are never useful when created within the existing code for groups, MeatAxe and so on. (Of course, these latter codes should work nicely when their input consists of object in IsVectorObj/IsMatrixObj.)
The main reason for overloading ImmutavleMatrix has been so the compact matrices get used for matrix groups over residue class rings -- this is a significant speed issue.
