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.

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

ImmutableMatrix creates MatrixObj for Z/nZ #4797

Merged
merged 4 commits into from
Apr 22, 2022
Merged

Conversation

hulpke
Copy link
Contributor

@hulpke hulpke commented Feb 25, 2022

and subsequent changes in group, meataxe, and polynomial code to make it work. This also provides further tests for #4773

The result is a small speedup when working with matrix groups/modules over ZmodnZ rings.

Text for release notes

N/A

@hulpke hulpke added do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes labels Feb 25, 2022
@hulpke hulpke removed the do not merge PRs which are not yet ready to be merged (e.g. submitted for discussion, or test results) label Mar 2, 2022
@hulpke hulpke force-pushed the fixes branch 3 times, most recently from a802b01 to a7ef741 Compare March 7, 2022 18:09
@hulpke hulpke force-pushed the fixes branch 4 times, most recently from 79bd931 to 871fb26 Compare March 21, 2022 13:26
@hulpke hulpke requested a review from fingolfin March 22, 2022 14:41
@hulpke hulpke force-pushed the fixes branch 2 times, most recently from cb965bd to 83d20fe Compare March 31, 2022 21:48
@hulpke hulpke force-pushed the fixes branch 3 times, most recently from 4b4aaed to 7716404 Compare April 9, 2022 14:02
lib/grpmat.gi Outdated Show resolved Hide resolved
gens,id,true);

f:=DefaultScalarDomainOfMatrixList(gens);
gens:=List(Immutable(gens),i->ImmutableMatrix(f,i));
Copy link
Member

Choose a reason for hiding this comment

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

Why do we make an immutable copy of gens before applying List to it? OK, you just copied the code (and that's fine), but I am wondering anyway, and asking in case you have an idea why this is done (if not, please simply ignore this question :-) ).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I suspect this is the result of a global insertion of ImmutableMatrix in many places without considering in each place whether the local code could be improved subsequently.

tst/teststandard/opers/Matobjnz.tst Show resolved Hide resolved
lib/vecmat.gi Outdated
Comment on lines 1598 to 1604
if IsPlistRep(matrix) and not ForAll(matrix,IsPlistRep) then
nr:=Length(matrix);
else
nr:=NrRows(matrix);
fi;

Copy link
Member

Choose a reason for hiding this comment

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

Why is this necessary? NrRows should work for "old-style" matrices, too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually...
It is needed, because the input could be a mixed format list, for which NrRows will not work.

Copy link
Member

Choose a reason for hiding this comment

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

Could you elaborate on that a bit? What is a "mixed format list" and where does it occur?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While merged already, a brief explanation for later:

The function is ImmutableMatrix. It takes somethig that could be construed as a list of vectors, and converts it into a compact format matrix (with the implicit claim that this representation will be efficient to work with).
This could be a list of vectors of different storage/mutability/base ring status (and indeed, this can happen when calling from the MeatAxe).

@hulpke hulpke force-pushed the fixes branch 5 times, most recently from 66c13e5 to d0bed2b Compare April 20, 2022 20:04
if given over large Integers mod n.
Subsequent changes in groups code and meataxe to ensure code works.
(Added methods for GeneralisedEigenvalues, TriangulizeMat, Check in
Echelonization, better field determination in DirectSumMat)
improved binary ops, if one partner is list.
Improved view if small.
Methiods for `DefaultScalarDomainOfMatrixList`, Hash key, Determinant.

Do not use vectorObj for polynomial coeffients
Needed to make groups of matrix objects feasible
New tests for MeatAxe/Group operations using zmodnz matrix objects,

Subsequent changed output in tests
Don't check for view format of matrices in HPCGAP
which for some reason keeps old format.
Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

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

Let's just merge this

@fingolfin fingolfin merged commit 6feeb8c into gap-system:master Apr 22, 2022
ThomasBreuer added a commit to ThomasBreuer/gap that referenced this pull request Jan 25, 2023
When one creates a "row space" of vector objects then the base domain
of the generators must contain the given left acting domain,
otherwise not all scalar multiples of the vectors can be created.
Thus it may be necessary to replace the given generators by vectors
whose base domain is large enough.
(Alternatively, one could signal an error.)

As far as I understand, pull request gap-system#4797 had added/changed
some code in `lib/vspcrow.gi` that makes it possible to deal with
"row vector spaces" whose elements are in `IsVectorObj` (but not lists).

A lot of functionality for that is still missing,
the current change just makes one test pass that had not failed before
because of missing consistency checks.
fingolfin pushed a commit that referenced this pull request Feb 2, 2023
When one creates a "row space" of vector objects then the base domain
of the generators must contain the given left acting domain,
otherwise not all scalar multiples of the vectors can be created.
Thus it may be necessary to replace the given generators by vectors
whose base domain is large enough.
(Alternatively, one could signal an error.)

As far as I understand, pull request #4797 had added/changed
some code in `lib/vspcrow.gi` that makes it possible to deal with
"row vector spaces" whose elements are in `IsVectorObj` (but not lists).

A lot of functionality for that is still missing,
the current change just makes one test pass that had not failed before
because of missing consistency checks.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants