Skip to content

Conversation

@SoongNoonien
Copy link
Collaborator

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.

@SoongNoonien
Copy link
Collaborator Author

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 Int .

@codecov
Copy link

codecov bot commented Nov 17, 2025

Codecov Report

❌ Patch coverage is 94.59459% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.08%. Comparing base (fe402c9) to head (644150f).

Files with missing lines Patch % Lines
src/generic/UnivPoly.jl 86.66% 2 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@SoongNoonien
Copy link
Collaborator Author

The doctest failures with julia 1.10 seem to be unrelated.

@lgoettgens
Copy link
Member

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 Int .

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?
In the case of Int this works, as Int does not have a parent concept.

@SoongNoonien
Copy link
Collaborator Author

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?
In the case of Int this works, as Int does not have a parent concept.

Yesterday, I came to this conclusion as well. But I'm still a bit confused why things like this work in that way:

julia> R,_=polynomial_ring(ZZ, Symbol[])
(Multivariate polynomial ring in 0 variables over integers, AbstractAlgebra.Generic.MPoly{BigInt}[])

julia> M=matrix_ring(ZZ,2)
Matrix ring of degree 2
  over integers

julia> evaluate(R(2), typeof(M(1))[])
2

While this works as expected:

julia> R,(x,)=polynomial_ring(ZZ, [:x])
(Multivariate polynomial ring in 1 variable over integers, AbstractAlgebra.Generic.MPoly{BigInt}[x])

julia> evaluate(R(2), [M(1)])
[2   0]
[0   2]

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.

@fingolfin
Copy link
Member

I think it is fine to error on empty vectors.

@thofma
Copy link
Member

thofma commented Nov 19, 2025

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 init for sum.)

@fingolfin
Copy link
Member

Perhaps we should add tests for the new edge cases.

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.

function (a::Union{MPolyRingElem, UniversalPolyRingElem})(;kwargs...)
ss = symbols(parent(a))
vars = Array{Int}(undef, length(kwargs))
vals = Array{RingElement}(undef, length(kwargs))
Copy link
Collaborator Author

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.

@fingolfin
Copy link
Member

This has conflicts now, and the tests failed

@SoongNoonien
Copy link
Collaborator Author

Yes, I left a comment last week on why the tests fail. I'll rebase and fix this on Wednesday.

@SoongNoonien
Copy link
Collaborator Author

I accidentally remove the new tests... I'll add them back.

@SoongNoonien
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants