Evaluating polynomials with zero variables gives error

[wegank]

using Nemo
R, () = polynomial_ring(QQ, Symbol[])
x = one(R)
evaluate(x, [])

gives the following error:

ERROR: BoundsError: attempt to access 0-element Vector{QQMPolyRingElem} at index [1]
Stacktrace:
 [1] throw_boundserror(A::Vector{QQMPolyRingElem}, I::Tuple{Int64})
   @ Base ./essentials.jl:15
 [2] getindex
   @ ./essentials.jl:919 [inlined]
 [3] evaluate(a::QQMPolyRingElem, bs::Vector{QQMPolyRingElem})
   @ Nemo ~/.julia/packages/Nemo/kdloy/src/flint/fmpq_mpoly.jl:600
 [4] evaluate(a::QQMPolyRingElem, vals::Vector{Any})
   @ AbstractAlgebra ~/.julia/packages/AbstractAlgebra/T6WZD/src/MPoly.jl:862
 [5] top-level scope
   @ REPL[5]:1

while evaluate(x, QQFieldElem[]) gives the desired result.

Indeed, in the functions below, S = parent(bs[1]) fails when bs is empty...

Nemo.jl/src/flint/fmpq_mpoly.jl

Lines 598 to 624 in f9ccb66

	function evaluate(a::QQMPolyRingElem, bs::Vector{QQMPolyRingElem})
	allequal(map(parent, bs)) || error("parents do not match")
	R = parent(a)
	S = parent(bs[1])
	length(bs) != nvars(R) &&
	error("Number of variables does not match number of values")
	c = S()
	fl = @ccall libflint.fmpq_mpoly_compose_fmpq_mpoly(c::Ref{QQMPolyRingElem}, a::Ref{QQMPolyRingElem}, bs::Ptr{Ref{QQMPolyRingElem}}, R::Ref{QQMPolyRing}, S::Ref{QQMPolyRing})::Cint
	fl == 0 && error("Something wrong in evaluation.")
	return c
	end
	function evaluate(a::QQMPolyRingElem, bs::Vector{QQPolyRingElem})
	allequal(map(parent, bs)) || error("parents do not match")
	R = parent(a)
	S = parent(bs[1])
	length(bs) != nvars(R) &&
	error("Number of variables does not match number of values")
	c = S()
	fl = @ccall libflint.fmpq_mpoly_compose_fmpq_poly(c::Ref{QQPolyRingElem}, a::Ref{QQMPolyRingElem}, bs::Ptr{Ref{QQPolyRingElem}}, R::Ref{QQMPolyRing})::Cint
	fl == 0 && error("Something wrong in evaluation.")
	return c
	end

[thofma]

In Nemocas/AbstractAlgebra.jl#2214 we came to the conclusion, that this should error, but probably with a better error message.

With the "untyped" empty vector [], it is ambiguous what the return type should be. Even evaluate(..., T[]) is in almost all cases ambiguous, except for the coefficient ring element type and T being QQFieldElem or ZZFieldElem.

So the error will not go away but it will probably be changed to evaluating at empty vector not allowed.

[SoongNoonien]

@wegank May I ask what's your usecase for this? Perhaps you just want to access the constant coefficient of x which would be possible with constant_coefficient(x).

[wegank]

I am writing a solver that takes inputs from $\mathbb{Q}(y_1,...,y_t)[x]$ and produces a semi-algebraic set in the $y$-space $\mathbb{R}^{t}$, and I'm checking whether my solver works when $t=0$ (where I should be able to decide the emptiness of the set). In this case, my code using evaluate to perform a change of basis on the variables $y_1,...,y_t$ does not work automatically for $t=0$ (where the change of basis does nothing, anyway).

[mjrodgers]

From triage: when the base ring is $\mathbb{Q}$ or $\mathbb{Z}$, we should return the constant coefficient of the polynomial in these cases; otherwise we should error (unless further specializations are requested later).

[fingolfin]

Discussed about related things with @SoongNoonien (who is working towards cleaning up these things) and wanted to record this here:

I agree we can define evaluate(f::MPolyRingElem{T}, v::Vector{T}) where T (so coefficient type agrees) even for empty v, and also evaluate(f::MPolyRingElem{T}, v::Vector{S}) where {T, S <: Union{Integer, Rational, ZZRingElem, QQFieldElem}`

However, for the "applied" notation, I'd prefer if f() just always gave an error, even if f is in a ring with zero variables. Otherwise any choice for what do there would conflict with something else: if f() returns just f it doesn't match with e.g. f(1,2,3) if f is in three variables (as that f will be a "coefficient"); if f() returns a "coefficient" it does not agree with f(x=1)` (which is a polynomial, and which is also implemented by a zero-position argument (!) method. Indeed, recall that kwarg do not participate in method dispatch... currently due to a bug in Julia, this is actually not quite true, but they are working on "fixing" this, which will probably affect us in various ways.

[SoongNoonien]

Ah, ok. Then I slightly misunderstood you. So, f() should not return f then?

[fingolfin]

Yes, f() should for now always error, IMHO (it already does if e.g. f is a QQMPolyRingElem)

[thofma]

Yes, please make f() an error for now in all cases.

[SoongNoonien]

Ok, alright.