Make evaluate for universal polynomials more universal

[SoongNoonien]

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]

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]

Codecov Report

❌ Patch coverage is 77.77778% with 4 lines in your changes missing coverage. Please review.
✅ Project coverage is 88.06%. Comparing base (61b6d9d) to head (cdaa8a5).

Files with missing lines	Patch %	Lines
src/generic/UnivPoly.jl	77.77%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #2214      +/-   ##
==========================================
+ Coverage   88.00%   88.06%   +0.05%     
==========================================
  Files         127      127              
  Lines       31801    31759      -42     
==========================================
- Hits        27986    27967      -19     
+ Misses       3815     3792      -23     

☔ 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]

The doctest failures with julia 1.10 seem to be unrelated.

[lgoettgens]

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]

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]

I think it is fine to error on empty vectors.

[thofma]

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