-
-
Notifications
You must be signed in to change notification settings - Fork 452
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
Implement algebra_containment from Singular (issue #34502) #36030
Conversation
301dfad
to
729316e
Compare
INPUT: | ||
|
||
- ``J`` -- iterable of elements of the parent polynomial ring | ||
|
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.
"iterable of elememts of ..." is precise, but I think just "elements of ..." is simple and easy. Just a suggestion.
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'll change it to "list of elements ..."
https://www.singular.uni-kl.de/Manual/4-2-1/sing_1247.htm#SEC1328. The | ||
Singular documentation suggests that this is frequently faster than the | ||
next option. | ||
|
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.
Actually the documentation says inSubring
is sometimes faster. No?
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.
Also I don't like "algebra_containment" as the default algorithm, since it outputs cluttering logs.
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.
Actually the documentation says
inSubring
is sometimes faster. No?
The documentation for inSubring
says, "the proc algebra_containment tests the same using a different algorithm, which is often faster". The documentation for algebra_containment
says, "The proc inSubring uses a different algorithm which is sometimes faster." I interpret "often faster" for algebra_containment
as better than "sometimes faster" for inSubring
, so I think we should prefer algebra_containment
.
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.
Also I don't like "algebra_containment" as the default algorithm, since it outputs cluttering logs.
By copying some code from function_field/function_field_polymod.py
, I think I have managed to silence the logs.
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.
Actually the documentation says
inSubring
is sometimes faster. No?The documentation for
inSubring
says, "the proc algebra_containment tests the same using a different algorithm, which is often faster". The documentation foralgebra_containment
says, "The proc inSubring uses a different algorithm which is sometimes faster." I interpret "often faster" foralgebra_containment
as better than "sometimes faster" forinSubring
, so I think we should preferalgebra_containment
.
OK.
Also I don't like "algebra_containment" as the default algorithm, since it outputs cluttering logs.
By copying some code from
function_field/function_field_polymod.py
, I think I have managed to silence the logs.
Nice! I was thinking of that too. Thanks.
- ``None`` (the default): use "algebra_containment". | ||
|
||
- "algebra_containment": use Singular's ``algebra_containment`` function, | ||
https://www.singular.uni-kl.de/Manual/4-2-1/sing_1247.htm#SEC1328. The |
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.
Why not just
- ``'algebra_containment'``: (default) uses Singular's ``algebra_containment`` function ...
Then you can get rid of `None``, which is really not an option.
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.
Good idea, I'll do that.
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.
Thanks.
|
||
- ``algorithm`` -- can be ``None`` (the default), "algebra_containment", | ||
"inSubring", or "groebner". | ||
|
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.
Now that you removed None
from the code below, this docstring should be updated, like
- ``algorithm`` -- one of "algebra_containment" (default),
"inSubring", or "groebner".
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.
Or see the comment below.
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.
Now that you removed
None
from the code below, this docstring should be updated, like- ``algorithm`` -- one of "algebra_containment" (default), "inSubring", or "groebner".
Fixed.
@@ -5757,6 +5757,83 @@ cdef class MPolynomial_libsingular(MPolynomial_libsingular_base): | |||
else: | |||
return self * self.denominator() | |||
|
|||
def in_subalgebra(self, J, algorithm="algebra_containment"): | |||
""" |
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.
The usual idiom is actually to write
def in_subalgebra(self, J, algorithm=None):
...
if algorithm is None:
algorithm = "algebra_containment"
else:
algorithm = algorithm.lower()
This is just a suggestion. You may keep your current code. In this case, see the comment above.
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.
The issue with this (to me) is that the signature shows None
as the default value, in which case I feel like I should explain it in the docstring. It may be the convention to ignore this, but I worry that it will confuse some user.
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.
ideal. The polynomial is contained in the subalgebra if | ||
and only if the remainder involves only the new variables | ||
`z_i`. | ||
|
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.
Matthias is massively correcting string literals as in this:
def set_random_number_generator(self, rng='default'):
"""
- Set the gsl random number generator to be one of ``default``,
- ``luxury``, or ``taus``.
+ Set the gsl random number generator to be one of ``'default'``,
+ ``'luxury'``, or ``'taus'``.
EXAMPLES::
So how about changing "groebner"
(and others) to
``'groebner'``
? This would save him from some work.
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.
Done. The built documentation looks okay to me.
Documentation preview for this PR (built with commit 851126b; changes) is ready! 🎉 |
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.
Thanks. LGTM.
Thanks for reviewing and for all of your feedback! |
…agemath#34502) <!-- ^^^^^ 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" --> This implements subalgebra containment for polynomials: whether a polynomial is contained in the subalgebra determined by given generators. <!-- Describe your changes here in detail --> <!-- 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. --> This fixes sagemath#34502. It provides several algorithms for the calculution, using Singular's algebra_containment, Singular's inSubring, or Sage's Groebner basis tools. ### 📝 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. - [X] I have linked a relevant issue or discussion. - [X] I have created tests covering the changes. - [X] I have updated the documentation accordingly. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on - sagemath#12345: short description why this is a dependency - sagemath#34567: ... --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#36030 Reported by: John H. Palmieri Reviewer(s): John H. Palmieri, Kwankyu Lee
This implements subalgebra containment for polynomials: whether a polynomial is contained in the subalgebra determined by given generators.
This fixes #34502. It provides several algorithms for the calculution, using Singular's algebra_containment, Singular's inSubring, or Sage's Groebner basis tools.
📝 Checklist
⌛ Dependencies