-
-
Notifications
You must be signed in to change notification settings - Fork 405
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
allow algorithm=pari in LLL #37207
allow algorithm=pari in LLL #37207
Conversation
sage: M.rank() | ||
2 | ||
|
||
sage: M = matrix(4,3,[1,2,3,2,4,6,7,0,1,-1,-2,-3]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This repeat the line above: remove.
sage: M.rank() | ||
2 | ||
|
||
sage: M = matrix(4,3,[1,2,3,2,4,6,7,0,1,-1,-2,-3]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This repeat the line above: remove
sage: M.LLL()[0:2] | ||
[0 0 0] | ||
[0 0 0] | ||
sage: M.rank() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would remove the M.rank()
line from this example.
sage: M.LLL(algorithm="NTL:LLL")[0:2] | ||
[0 0 0] | ||
[0 0 0] | ||
sage: M.rank() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to add a doctest block in the TESTS::
part which test that the rank is computed correctly by each algo with proper M._clear_cache()
calls in between.
elif algorithm == 'pari': | ||
# call pari with flag=4: kernel+image | ||
# pari uses column convention: need to transpose the matrices | ||
from sage.libs.pari import pari |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we use self._gp_().mattranspose()
below, then, we don't need to import pari on this line
Also we would need to use K.sage().augment(T.sage())
or something like this.
I don't have a strong opinion on this. We may keep it as it is if it is better overall.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this one. Maybe someone else has an opinion?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never use _gp_
, which is going through the old and slow interface ; use __pari__
sage: m=matrix(ZZ,4,4,range(16))
sage: type(m)
<class 'sage.matrix.matrix_integer_dense.Matrix_integer_dense'>
sage: m._gp_()
[0, 1, 2, 3; 4, 5, 6, 7; 8, 9, 10, 11; 12, 13, 14, 15]
sage: type(_)
<class 'sage.interfaces.gp.GpElement'>
sage: m.__pari__()
[0, 1, 2, 3; 4, 5, 6, 7; 8, 9, 10, 11; 12, 13, 14, 15]
sage: type(_)
<class 'cypari2.gen.Gen'>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, thanks! Would it be better to use pari to avoid the import statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't really see a reason to avoid the import statement: It's essentially free since the library has already been loaded anyway.
sage: %timeit from sage.libs.pari import pari
182 ns ± 1.79 ns per loop (mean ± std. dev. of 7 runs, 10,000,000 loops each)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be using
cypari2
, notpari
?
What do you mean?
>>> from sage.libs.pari import pari
>>> type(pari)
<class 'cypari2.pari_instance.Pari'>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops, never mind, sorry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Though, for the conversion, it is probably faster to go through M.__pari__()
or even the more direct
cdef Gen pari_matrix = integer_matrix(self._matrix, 0)
(which is the one-line code of M.__pari__()
). The second argument of integer_matrix
allows you to transpose which might be useful here!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To convert back from pari the most direct at the moment is to call gen_to_sage_matrix
from sage.libs.pari.convert_sage_matrix
. Though this function does not take into account the fact that the entries are integral and there is a bunch of irrelevant python objects built for each entry. For huge matrices it could matter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will propose a commit.
K, T = A.qflll(4) | ||
U = pari.matconcat([K, T]).mattranspose().sage() | ||
R = U * self | ||
r = ZZ(T.length()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a pari method call done after lines where the sage language is performed. Maybe keep pari computations all together is more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
Hmm... caching in LLL is not very smart sage: m = matrix(ZZ, 2, 2, [-1,1,1,1])
sage: m.LLL(algorithm="NTL:LLL")
[-1 1]
[ 1 1]
sage: m.det()
2
sage: m = matrix(ZZ, 2, 2, [-1,1,1,1])
sage: m.det()
-2 Now #37236 |
@AurelPage |
@videlec Thanks! I am trying your commit. Git made decentralised collaboration easy, and then github ruined it. |
@videlec I've included your commit. |
Documentation preview for this PR (built with commit c89b30a; changes) is ready! 🎉 |
I think this "cannot push to your branch" only happens if the PR's author disallowed such pushes while creating the PR (not sure if this can be changed later), or if the contributor who wants add commits is not a member of Sagemath Triage team. In any event it should always be possible to make a PR against the fork of this PR on the PR's author repo (and then PR's author can use GitHub's interface to deal with it). I agree that's confusing, and could be documented better. |
@dimpase I allowed edits by maintainers, if that's what you mean. And it can be changed after the PR has been created. |
perhaps @videlec is not a member of Triage team? (I can't check this myself) |
Indeed, push are allowed for "maintainers" but not anybody (like me :-) |
pushes are not allowed for just anybody, for a good reason - to prevent vandalism from persons unaffiliated with the project. In this case "maintainer" means being on an appropriate Sagemath (a GitHub organisation) team, with appropriate push access. I thought that members of Triage have such rights - to push to the branches related to the PRs (not to protected branches) - but I might be wrong here. Maybe @vbraun knows better. In any case, asking the author of the PR to manually merge a commit looks like a suboptimal thing, going via a PR to the fork looks more natural. |
<!-- ^^^^^ Please provide a concise, informative and self-explanatory title. Don't put issue numbers in there, do this in the PR body below. For example, instead of "Fixes sagemath#1234" use "Introduce new method to calculate 1+1" --> <!-- Describe your changes here in detail --> We allow to call the pari implementation of LLL reduction. The next release of pari will contain an implementation of the FLATTER algorithm for LLL reduction, which has better asymptotic complexity. <!-- Why is this change required? What problem does it solve? --> <!-- If this PR resolves an open issue, please link to it here. For example "Fixes sagemath#12345". --> <!-- If your change requires a documentation PR, please link it appropriately. --> ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> <!-- If your change requires a documentation PR, please link it appropriately --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <!-- Feel free to remove irrelevant items. --> - [x] The title is concise, informative, and self-explanatory. - [x] The description explains in detail what this PR is about. - [ ] I have linked a relevant issue or discussion. - [x] I have created tests covering the changes. - [x] I have updated the documentation accordingly. <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#37207 Reported by: AurelPage Reviewer(s): AurelPage, Dima Pasechnik, Frédéric Chapoton, Lorenz Panny, Sébastien Labbé, Vincent Delecroix
We allow to call the pari implementation of LLL reduction. The next release of pari will contain an implementation of the FLATTER algorithm for LLL reduction, which has better asymptotic complexity.
📝 Checklist