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

NotImplementedError when pow() called with modulus #38717

Merged

Conversation

kylehofmann
Copy link
Contributor

Many polynomial types silently ignore the modulus (third) argument of pow(). For example,

sage: R.<x> = PolynomialRing(ZZ)
sage: pow(x, 2, x)
x^2

This is true of LaurentPolynomial, LaurentPolynomial_mpair, MPolynomial_libsingular, Polynomial_integer_dense_flint, Polynomial_rational_flint, and NCPolynomial_plural. Ideally these classes would implement this argument, but at the very least they should raise NotImplementedError instead of giving an incorrect result.

Copy link

github-actions bot commented Sep 28, 2024

Documentation preview for this PR (built with commit 188f93f; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@user202729
Copy link
Contributor

Sounds like a good idea but there's a significant code duplication going on… is there a way to eliminate that? (for example with function decoration, or if it's too slow, at least a utility function that can be called?)

@kylehofmann
Copy link
Contributor Author

I also generally don't like duplicating code, but in this case, most of the duplication is in the unit tests. Those need to be near what they're testing, and they have minor differences because they test different classes. Except for those, the only duplicated code is two statements long (an if and a raise). You could reduce it to two lines if you allowed wider lines (or used a shorter, more obscure error message) or one line with an auxiliary function (I don't think a decorator is a good idea here), but there is also the risk that using such a function would make the code less clear (particularly for whoever eventually implements pow with a modulus). I think this version is acceptable, but I'd be happy to listen to other opinions.

@vincentmacri
Copy link
Contributor

One way to reduce the code duplication could be something like a __check_pow_parameters method that raises an error if mod is not None in whatever base class all these polynomial types inherit from, and call it in the __pow__ method for each polynomial type. But I think that what was submitted here is fine as-is.

@kylehofmann What's going on with the test failure in plural.pyx?

@kylehofmann
Copy link
Contributor Author

I don't know why that file's tests fail, but I believe it's not an issue with my code. You can find other MRs where the test process has failed, like #38748. When I test that file myself, or even when I run all tests, I don't get any errors.

@vincentmacri
Copy link
Contributor

I don't know why that file's tests fail, but I believe it's not an issue with my code. You can find other MRs where the test process has failed, like #38748. When I test that file myself, or even when I run all tests, I don't get any errors.

Yeah, I see a similar test failure in the PR you linked. I was concerned since the test failure was in a file you changed, but it seems to be a coincidence that you just happened to change a file where the CI is having issues.

Copy link
Contributor

@vincentmacri vincentmacri left a comment

Choose a reason for hiding this comment

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

LGTM

vbraun pushed a commit to vbraun/sage that referenced this pull request Oct 5, 2024
    
<!-- ^ Please provide a concise and informative title. -->
<!-- ^ Don't put issue numbers in the title, do this in the PR
description below. -->
<!-- ^ For example, instead of "Fixes sagemath#12345" use "Introduce new method
to calculate 1 + 2". -->
<!-- v Describe your changes below in detail. -->
<!-- v Why is this change required? What problem does it solve? -->
<!-- v If this PR resolves an open issue, please link to it here. For
example, "Fixes sagemath#12345". -->

Many polynomial types silently ignore the modulus (third) argument of
`pow()`.  For example,
```python
sage: R.<x> = PolynomialRing(ZZ)
sage: pow(x, 2, x)
x^2
```
This is true of `LaurentPolynomial`, `LaurentPolynomial_mpair`,
`MPolynomial_libsingular`, `Polynomial_integer_dense_flint`,
`Polynomial_rational_flint`, and `NCPolynomial_plural`.  Ideally these
classes would implement this argument, but at the very least they should
raise `NotImplementedError` instead of giving an incorrect result.
    
URL: sagemath#38717
Reported by: Kyle Hofmann
Reviewer(s): Vincent Macri
vbraun pushed a commit to vbraun/sage that referenced this pull request Oct 9, 2024
    
<!-- ^ Please provide a concise and informative title. -->
<!-- ^ Don't put issue numbers in the title, do this in the PR
description below. -->
<!-- ^ For example, instead of "Fixes sagemath#12345" use "Introduce new method
to calculate 1 + 2". -->
<!-- v Describe your changes below in detail. -->
<!-- v Why is this change required? What problem does it solve? -->
<!-- v If this PR resolves an open issue, please link to it here. For
example, "Fixes sagemath#12345". -->

Many polynomial types silently ignore the modulus (third) argument of
`pow()`.  For example,
```python
sage: R.<x> = PolynomialRing(ZZ)
sage: pow(x, 2, x)
x^2
```
This is true of `LaurentPolynomial`, `LaurentPolynomial_mpair`,
`MPolynomial_libsingular`, `Polynomial_integer_dense_flint`,
`Polynomial_rational_flint`, and `NCPolynomial_plural`.  Ideally these
classes would implement this argument, but at the very least they should
raise `NotImplementedError` instead of giving an incorrect result.
    
URL: sagemath#38717
Reported by: Kyle Hofmann
Reviewer(s): Vincent Macri
@vbraun vbraun merged commit bf06172 into sagemath:develop Oct 12, 2024
13 of 15 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants