-
Notifications
You must be signed in to change notification settings - Fork 72
Make evaluate for universal polynomials more universal
#2214
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
base: master
Are you sure you want to change the base?
Conversation
949ad8f to
107ff45
Compare
|
Some previously failing tests were caused by the evaluation of mpoly. Apparently it is not possible to evaluate an mpoly in a ring with no variables at an empty vector with element type univariate polynomial, even though this is possible if the element type is |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2214 +/- ##
==========================================
+ Coverage 88.02% 88.08% +0.06%
==========================================
Files 127 127
Lines 31815 31782 -33
==========================================
- Hits 28004 27996 -8
+ Misses 3811 3786 -25 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
The doctest failures with julia 1.10 seem to be unrelated. |
Reasoning behind this: If you evaluate at an empty vector with element type univariate polynomial, the result is a univariate polynomial. But how should the result know its parent Univariate poly ring? |
Yesterday, I came to this conclusion as well. But I'm still a bit confused why things like this work in that way: While this works as expected: I'm not so sure if evaluating at empty vectors in general is such a good idea, but perhaps I'm missing an important application. |
|
I think it is fine to error on empty vectors. |
|
Yeah, empty vector is bad and we should error for now. If someone misses it, we could add it back with some target ring for the evaluation. (Similar to |
ba9900f to
cdaa8a5
Compare
Yes definitely. As it is, this PR only removes tests. If we care about these edge cases, we definitely should add tests for them, otherwise they'll just get broken again down the road. |
0b831b8 to
8587cdc
Compare
src/generic/UnivPoly.jl
Outdated
| function (a::Union{MPolyRingElem, UniversalPolyRingElem})(;kwargs...) | ||
| ss = symbols(parent(a)) | ||
| vars = Array{Int}(undef, length(kwargs)) | ||
| vals = Array{RingElement}(undef, length(kwargs)) |
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 not correct anymore as the number of kwargs might be greater. I'll look into it.
|
This has conflicts now, and the tests failed |
|
Yes, I left a comment last week on why the tests fail. I'll rebase and fix this on Wednesday. |
8587cdc to
8fc3646
Compare
|
I accidentally remove the new tests... I'll add them back. |
4d8d364 to
644150f
Compare
|
I think in a followup PR we should add documentation about the kwargs evaluation and the difference between the method for multivariate polynomials and the method of universal polynomials. The difference being that the latter ignores variable names not present in the respective parent. |
As mentioned in #2211 I've reworked the evaluation for universal polynomials. Perhaps we should add tests for the new edge cases. Evaluating at one vector always returns an element of the coercion of the provided elements in the vector an the coefficients of the polynomial. Evaluating at two vectors (one for the variable indices and one for the values) will always return a universal polynomial. All variables which aren't present yet will be ignored.