Examples of Vector objects and Matrix objects#6339
Conversation
| and a matrix in these new forms. | ||
| The elements should all belong to a semiring <M>R</M> | ||
| (the <C>BaseDomain</C>). | ||
| It is also necessary to specify their <E>type</E>, or <E>filter</E>. |
There was a problem hiding this comment.
Actually these can be omitted if one uses Matrix and Vector instead of NewMatrix and NewVector -- in that case default are chosen, based on the base domain.
My feeling is that we should generally advocate the use of the function variants without the New; the ones with New are constructors, and are the ones that people implementing MatrixObj ought to implement. Though I might be missing some nuance here, @ThomasBreuer ? I really should read up on what we wrote in the docs ...
But in any case, this is exactly the kind of thing that must be made clear in the manual, of course
There was a problem hiding this comment.
My point of view is that the starting point is the semiring R, in the sense that we want to do many computations with vectors and matrices over a given R.
Once we have fixed R, the functions Vector( R, list ) and Matrix( R, list ) (or Matrix( R, list, ncols )) give us vector and matrix objects in some representation that fits to R.
And once we have such a vector v or matrix M, new vectors and matrices that fit to them can be created with Vector( list, v ) and Matrix( list, M ).
This is the easy case.
If we do not want to rely on the default representation for R, we can look at some list of available representations (filters), and specify explicitly which one we choose.
Where is this useful or even necessary?
For example, suppose we need the matrix group GL( 4, GF(2) ), but we know already that later on this will be regarded as a subgroup of GL( 4, GF(2^10) ).
It may happen that the default representations for matrix objects over GF(2) and GF(2^10) differ.
In this situation, we should create GL( 4, GF(2) ) in such a way that the generators are written in a representation that is suitable also for matrices over GF(2^10).
Currently I see no easier way to achieve this than to create a matrix object over GF(2^10), to ask for its ConstructingFilter, and to specify this filter in the construction of the group GL( 4, GF(2) ).
ThomasBreuer
left a comment
There was a problem hiding this comment.
Two suggestions, which should fix the test failure (one more instance of the annoying setup described in #6274).
And one general remark, I agree with @fingolfin that Matrix and Vector are more important for users than NewMatrix and NewVector.
Co-authored-by: Thomas Breuer <sam@math.rwth-aachen.de>
Co-authored-by: Thomas Breuer <sam@math.rwth-aachen.de>
Bumps [actions/upload-pages-artifact](https://github.com/actions/upload-pages-artifact) from 4 to 5. - [Release notes](https://github.com/actions/upload-pages-artifact/releases) - [Commits](actions/upload-pages-artifact@v4...v5) --- updated-dependencies: - dependency-name: actions/upload-pages-artifact dependency-version: '5' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Bumps [julia-actions/setup-julia](https://github.com/julia-actions/setup-julia) from 2 to 3. - [Release notes](https://github.com/julia-actions/setup-julia/releases) - [Commits](julia-actions/setup-julia@v2...v3) --- updated-dependencies: - dependency-name: julia-actions/setup-julia dependency-version: '3' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Codex wrote most of this and I edited it. Co-authored-by: Codex <codex@openai.com>
So far adding an integer to a range produced a plain list. Add a kernel method to ensure this again produces a range, if possible. If not, fall back to the current behavior. AI-assisted with Codex for the kernel change and tests. Co-authored-by: Codex <codex@openai.com>
Switch Codecov to manual notifications and send them once after the coverage-uploading test matrix finishes. This avoids noisy intermediate PR comments and temporary dropped-coverage reports while uploads are still in flight. Co-authored-by: Codex <codex@openai.com>
…6329) ... by avoiding some method dispatch, providing optimized methods using `{...}` syntax, and turning ExtractSubVector, CopySubVector, ExtractSubMatrix, and CopySubMatrix into kernel ops. Then run some benchmarks via `benchmark/matobj/bench-submat.g` and the new `benchmark/matobj/bench-subvec.g`. Before: +----------------------------------------------------------------+ | Testing submatrix extraction for integer matrix: list of lists | +----------------------------------------------------------------+ Testing m{}{}: 129 µs per iteration; 7749 iterations per second; (200 iterations) Testing ExtractSubMatrix: 720 µs per iteration; 1388 iterations per second; (200 iterations) ...now testing submatrix copying... Testing m{}{}:=n{}{}: 342 µs per iteration; 2921 iterations per second; (200 iterations) Testing CopySubMatrix: 1032 µs per iteration; 969 iterations per second; (200 iterations) +------------------------------------------------+ | Testing submatrix extraction for GF(2) rowlist | +------------------------------------------------+ Testing m{}{}: 167 µs per iteration; 5999 iterations per second; (200 iterations) Testing ExtractSubMatrix: 3288 µs per iteration; 304 iterations per second; (92 iterations) ...now testing submatrix copying... Testing m{}{}:=n{}{}: 1992 µs per iteration; 502 iterations per second; (151 iterations) Testing CopySubMatrix: 2606 µs per iteration; 384 iterations per second; (116 iterations) +-------------------------------------------------------------+ | Testing subvector extraction for integer vector: plain list | +-------------------------------------------------------------+ Testing x{}:=v{}: 393 µs per iteration; 2542 iterations per second; (200 iterations) Testing CopySubVector: 2324 µs per iteration; 430 iterations per second; (130 iterations) +---------------------------------------------------+ | Testing subvector extraction for GF(2) row vector | +---------------------------------------------------+ Testing x{}:=v{}: 441 µs per iteration; 2266 iterations per second; (200 iterations) Testing CopySubVector: 2458 µs per iteration; 407 iterations per second; (123 iterations) After: +----------------------------------------------------------------+ | Testing submatrix extraction for integer matrix: list of lists | +----------------------------------------------------------------+ Testing m{}{}: 136 µs per iteration; 7355 iterations per second; (200 iterations) Testing ExtractSubMatrix: 140 µs per iteration; 7135 iterations per second; (200 iterations) ...now testing submatrix copying... Testing m{}{}:=n{}{}: 301 µs per iteration; 3319 iterations per second; (200 iterations) Testing CopySubMatrix: 299 µs per iteration; 3347 iterations per second; (200 iterations) +------------------------------------------------+ | Testing submatrix extraction for GF(2) rowlist | +------------------------------------------------+ Testing m{}{}: 154 µs per iteration; 6490 iterations per second; (200 iterations) Testing ExtractSubMatrix: 146 µs per iteration; 6854 iterations per second; (200 iterations) ...now testing submatrix copying... Testing m{}{}:=n{}{}: 1895 µs per iteration; 528 iterations per second; (159 iterations) Testing CopySubMatrix: 1935 µs per iteration; 517 iterations per second; (156 iterations) +-------------------------------------------------------------+ | Testing subvector extraction for integer vector: plain list | +-------------------------------------------------------------+ Testing x{}:=v{}: 428 µs per iteration; 2336 iterations per second; (200 iterations) Testing CopySubVector: 453 µs per iteration; 2209 iterations per second; (200 iterations) +---------------------------------------------------+ | Testing subvector extraction for GF(2) row vector | +---------------------------------------------------+ Testing x{}:=v{}: 427 µs per iteration; 2344 iterations per second; (200 iterations) Testing CopySubVector: 460 µs per iteration; 2172 iterations per second; (200 iterations) So overall the Copy/Extract methods are now more or less on par with the code using `{...}` syntax. But actually this `ExtractSubMatrix` for a GF(2) rowlist is now *faster* than the optimized one for a compressed GF(2) matrix: +----------------------------------------------------------+ | Testing submatrix extraction for GF(2) compressed matrix | +----------------------------------------------------------+ Testing m{}{}: 1057 µs per iteration; 946 iterations per second; (200 iterations) Testing ExtractSubMatrix: 1618 µs per iteration; 618 iterations per second; (186 iterations) A substantial part of that is due to the the `ExtractSubMatrix` method for `IsGF2MatrixRep` calling `ConvertToMatrixRepNC(mm,2)`; after removing that, it went down from 1618 to 392 µs (which is still worse). --- AI assistance: Codex implemented the kernel plumbing, method cleanup, and test updates. It also created `benchmark/matobj/bench-subvec.g`. Co-authored-by: Codex <codex@openai.com>
|
I have started to follow the suggestions of @fingolfin and @ThomasBreuer, but using GitHub in collaboration like this, and with GAPdev, is getting me in rather a tangle, so advice needed. |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #6339 +/- ##
=======================================
Coverage 78.69% 78.69%
=======================================
Files 684 684
Lines 292892 292900 +8
Branches 8660 8661 +1
=======================================
+ Hits 230497 230506 +9
Misses 60581 60581
+ Partials 1814 1813 -1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
NewMatrix(filt, R, ncols, list) & Matrix(filt, R, list, ncols) .... this confusing change of order will not do! |
The GAPDoc description for IrreducibleModules claimed the second entry was 'a list of all irreducible modules of G over the field F in dimension dim'. The actual behaviour is to return all irreducible constituents of dimension at most dim, matching: Updated the description to match this, and also added a one-line note that passing 0 imposes no bound (already the implementation behavior, previously only discoverable by reading the code). Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com> Co-authored-by: Claude (Anthropic AI) <noreply@anthropic.com>
Return the empty partition from PartitionsGreatestLE(0, m) for every nonnegative m. Also clarify the documentation. Co-authored-by: Codex <codex@openai.com>
Useful for debugging, and future work on alternative GC integration.
* kernel: fix typo in src/gasman.c * CREATE_PTY_IOSTREAM: require args as plist * ExecuteProcess: require args as plist * kernel: change AUTO to require plain list
* kernel: drop unused return value of UseTmpPerm * kernel: use BOOL in more places * kernel: init buffer with memset * kernel: use size_t in some places * kernel: explain certain uses of 'extern inline' * kernel: update some comments
* kernel: remove ErrorReturnObj, C_NEW_STRING We don't use them nor any distributed package. * remove stuff which is now also dead
... and in general make its phrasing more consistent. Also update some several outdated sections of the documentation about break loops and error handling. Co-authored-by: Codex <codex@openai.com>
Move part of the code from the kernel to the library. This will make future improvements easier. Co-authored-by: Codex <codex@openai.com>
* Adjust when 'Stack trace:' message is printed * Update one more error message * Add two missing 'Stack trace:'
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 6 to 7. - [Release notes](https://github.com/codecov/codecov-action/releases) - [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md) - [Commits](codecov/codecov-action@v6...v7) --- updated-dependencies: - dependency-name: codecov/codecov-action dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
The 'return to continue' is redundant and potentially confusing.
Also remove some now redundant methods.
Before:
gap> m:=RandomMat(256, 256, GF(1000000007));;
gap> mat:=Matrix(IsZmodnZMatrixRep, GF(1000000007), m);;
gap> RankMat(mat)=256; time;
true
170
gap> DeterminantMat(mat); time;
ZmodpZObj( 873487643, 1000000007 )
23982
After:
gap> m:=RandomMat(256, 256, GF(1000000007));;
gap> mat:=Matrix(IsZmodnZMatrixRep, GF(1000000007), m);;
gap> RankMat(mat)=256; time;
true
161
gap> DeterminantMat(mat); time;
ZmodpZObj( 873487643, 1000000007 )
1949
* Align and clarify break loop instructions further * Adjust <Log> blocks to new late error msg * Regenerate tst/testspecial
They are not referenced anywhere and nowadays at most of historical interest.
It does not seem to serve any purpose (anymore?)
There was an incorrect comment claiming that SyGAPCRC only ever returns 0 in case of an error. There was also code that looked as if it ensured that (by checking if `crc` is 0 and if so replacing it by 1). But this code in fact was a no-op, and has been one since 1997, when the code was changed to return `crc >> 4` instead of `crc` -- yet both `0 >> 4` and `1 >> 4` are equal to 0. Regarding the other changes: - `(crc >> 8) & 0x00FFFFFFL` is the same as `crc >> 8` since `crc` is an unsigned 32 bit value - removed a comment from the 1990ies suggesting that `SyGAPCRC` should ignore whitespace and comment changes; but we will never do that (as it would be very difficult, break backwards compatibility, and have little practical use) - align right shift in SyGAPCRC and FuncCrcString: one was "emulating" a signed shift, the other didn't. This didn't cause a problem in practice because essentially every compiler in active uses nowadays implements signed right shifts; but the C standard does not require this. Now both use the same branchless emulation code which e.g. clang compiles down into a single instruction (GCC, MSVC, ICC do not, but that's fine, this code is not a bottleneck for anything)
Bumps [actions/checkout](https://github.com/actions/checkout) from 6 to 7. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v6...v7) --- updated-dependencies: - dependency-name: actions/checkout dependency-version: '7' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Also treat readline headers as system includes. This avoids Homebrew readline header warnings under --enable-Werror. Co-authored-by: Max Horn <max@quendi.de> Co-authored-by: Codex <codex@openai.com>
In case someone uses '%g' in a format string but fails to provide a matching argument. Moreover, make sure we don't use `arg2` more then once.
…a new feature for matrix groups (#6232) - add a description of the cache `FULLGLNICOCACHE` in the code; it is used only by `NicomorphismFFMatGroupOnFullSpace` - change the keys of `FULLGLNICOCACHE`: take the field of the matrix entries into account (not only its size), take the `ConstructingFilter` of the matrices into account - in `NicomorphismFFMatGroupOnFullSpace`, deal with special cases of matrices in `IsBlockMatrixRep` (which have no `ConstructingFilter`) and in `Is8BitMatrixRep` in the situation that the group itself lives over `GF(2)` - in order to admit the action of `IsMatrixObj` matrices on vectors supported by GAP's `Enumerator`s of vector spaces, add a `\^` method that `Unpack`s the matrix object (Eventually we want to avoid this overhead, but then we need `Enumerator`s consisting of vector objects corresponding to the matrix objects.) - add `Matrix` calls in the function that computes preimages under an action homomorphism with `Source` a matrix group, in order to support matrix group elements of prescribed kinds of `IsMatrixObj`. - add tests for the new supported situations (most of the changes were actually forced by already available tests) * add `\in` methods for matrix object and (`GL` or `SL`) * avoid some `Unpack` hacks - introduce `NormedRowVectors_internal( F, base )`, and `AsListOfFreeLeftModule_internal( F, base, zero )`, in order to admit `IsVectorObj`s in `base` without supporting the whole vector space machinery for these objects - introduce `ExternalSet( G )` for matrix groups `G`, meaning the natural `G`-set (an undocumented method for permutation groups `G` was already available) - change `NicomorphismFFMatGroupOnFullSpace` such that we can act with the `IsMatrixObj` matrices on their `IsVectorObj` vectors, without unpacking the matrices - support `IsMatrixObj` matrices in the `Random` methods for GL and SL * adjust also `IsProjectiveActionHomomorphism` methods * add `RandomMatrix`, `RandomInvertibleMatrix` and fix the `RankMat` method for `IsPlistMatrixRep`
It was agreed by @fingolfin in PR#6320 that Chapter 26, Vector and Matrix Objects, needs lots of usage examples.
This is just an attempt to get this process started.
Newcomers to vector and matrix objects who start by reading this manual chapter (as opposed to those accessing a section by asking a question during a GAP session) need some examples early on, so this first commit adds a new section 26.2 doing just that.
Comments by one and all will be most welcome as further examples are added.
It was interesting to find that IsPlist{Vector/Matrix}Rep allow lists of type IsRangeRep as well as IsPlistRep.