-
-
Notifications
You must be signed in to change notification settings - Fork 482
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
Add ABCs CommutativePolynomial, MPolynomial_libsingular, InfinitePolynomial; deprecate is_Polynomial, is_MPolynomial #32709
Comments
Author: Matthias Koeppe |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Commit: |
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:14
Merge failure. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:17
Thank you for doing this. This is something that I have been thinking about having for a while. The only other thing I would like would be a common ABC for both univariate and multivariate polynomials. |
comment:18
Currently we have:
but
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
comment:85
I'm moving the modularization boundary into The new module |
This comment has been minimized.
This comment has been minimized.
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
This comment has been minimized.
This comment has been minimized.
comment:92
Thank you. Last two things, both for the infinite polynomials:
|
comment:94
Thank you. LGTM. |
Reviewer: Travis Scrimshaw |
comment:95
Thanks! |
Merge conflict, please create a corresponding github PR to fix. |
Removed branch from description; superseded by PR #35076. |
…finitePolynomial; deprecate is_Polynomial, is_MPolynomial <!-- ^^^^^ 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 #1234" use "Introduce new method to calculate 1+1" --> ### 📚 Description <!-- Describe your changes here in detail --> <!-- Why is this change required? What problem does it solve? --> <!-- If it resolves an open issue, please link to the issue here. For example "Closes #1337" --> Closes #32709 ### 📝 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! --> - [ ] I have made sure that the title is self-explanatory and the description concisely explains the PR. - [x] I have linked an issue or discussion. - [x] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies <!-- List all open pull requests that this PR logically depends on --> <!-- - #xyz: short description why this is a dependency - #abc: ... --> URL: #35076 Reported by: Matthias Köppe Reviewer(s): Travis Scrimshaw
isinstance(x, [M]Polynomial)
replaces the use ofis_Polynomial
,is_MPolynomial
(deprecated here).The new class
CommutativePolynomial
is an ABC that is a common base ofPolynomial
,MPolynomial
, andInfinitePolynomial
. We introduce it here although there is currently no use forisinstance(x, CommutativePolynomial)
in the library.The new class
InfinitePolynomial
is a common base class ofInfinitePolynomial_sparse
andInfinitePolynomial_dense
. Methods shared between both classes are moved to the new class.The new class
MPolynomial_libsingular
is an ABCDEFIT (ABC defined exclusively forisinstance
tests) with a unique direct subclass (see Meta-ticket #32414 and https://doc.sagemath.org/html/en/developer/packaging_sage_library.html#module-level-runtime-dependencies for this design pattern). Its purpose is to replace uses ofisinstance(x, MPolynomial_libsingular)
throughout the library. This eliminates hard run-time dependencies on Singular.We also make
sage.rings.polynomial
a namespace package; this is needed because element implementations depend on various libraries.CC: @dimpase @mezzarobba @videlec @tscrim
Component: refactoring
Author: Matthias Koeppe
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/32709
The text was updated successfully, but these errors were encountered: