evaluation of polynomials in several variables

[chris wuthrich]

Let f be a polynomial in two variables x and y over a ring R.
Consider the following three commands

i) f(2,3)
ii) f(x=2,y=3)
iii) f.subs(x=2,y=3)

They give the same results but not the same type. i) gives an element
in R while ii) and iii) are constant polynomials in two variables.
Follinwg the documentation, i) and ii) should give an element in R
while iii) is a polynomial.

So something should be changed. The question is what. I would expect
all three to give back elements of R. This is maybe a slightly non-
canonical choice given that f(x=3) does not (and should not) give back
a polynomial in one variable or an element in the quotient ring R[x,y]/
(x-3). But still I think that is what a naive user like me would
expect when evaluating all variables.

Note that for a polynomial in one variable all three are elements in
R.

The changes for i) in a __call__ of
sage.rings.polynomial.multi_polynomial_libsingular.pyx were introduced
in ticket #8502. I came across this issue in #10888. I propose to
change at least so that ii), which is the __call__ method, does the
same as i) - see attached patch. But the question is if one wants to
change subs().

I figured that some people in this list may have an opinion on this.
Chris.

[Volker Braun]

Substitution should always try to return the same type (i.e. same parent) if possible. Anything else will just be a constant source of bugs where your code works with generic polynomial input, but not for constants.

[Simon King]

Yes, but the fact that f(2,3) has a different parent than f(x=2,y=3)
has a high probability of being troublesome.

[Volker Braun]

I agree that thats the only valid question here: is f(x=2,y=3) substitution or evaluation? The call syntax suggests evaluation, but keywords allow you to only substitute some variables. I'm tempted to say that since its not obvious we shouldn't have the function at all, that is, don't allow keyword arguments in _call_. 

[chris wuthrich]

I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.

[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a discussion on this and I missed it. E.g.
f(x) = sin(x)
f(1.).floor()
does not work.]

No I am against changing this. For two reasons, when working with
polynomials in variable names liks "k", "p". It is not always easy to
remember which was the first and which was the second variable. Then
it is very handy to pass keywords for evaluation - but still to expect
a base_ring element.

Instead I think we should check that all variables are evaluated. This
would be consistent with the call f(2,3) which screams when the number
of variables is not correct. Even better, we could check if the result
is really a ring element after substitution, which is easy to do. E.g.
I would allow
f = x*(x+y)
f(x=0)
but not
f(x=1)

Chris.

[chris wuthrich]

I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.

[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a discussion on this and I missed it. E.g.
f(x) = sin(x)
f(1.).floor()
does not work.]

[Robert Bradshaw]

Given f in R[x,y], I think f(x=a, y=b) should do exactly the same
thing as f(a,b). The parent should be the same as R.base_ring()(0) + a
+ b.

The difficult case is what to do for f(x=5). Should that be the same
as f(x=5, y=y) or a univariate polynomial?

- Robert

[chris wuthrich]

I hope we agree that evaluation (meaning evaluation of all variables
by some elements in a ring) should yield an element of the ring. I
don't mind if subs should give back a polynomial in all cases.

[Aside: Strangely this is not the case for symbolic expressions. I am
sure there must have been a discussion on this and I missed it. E.g.
f(x) = sin(x)
f(1.).floor()
does not work.]

[Simon King]

Hi Robert,

On 14 Mrz., 23:29, Robert Bradshaw <rober...@math.washington.edu>
wrote:

> > Yes, but the fact that f(2,3) has a different parent than f(x=2,y=3)
> > has a high probability of being troublesome.
>
> Given f in R[x,y], I think f(x=a, y=b) should do exactly the same
> thing as f(a,b). The parent should be the same as R.base_ring()(0) + a
> + b.

+1. I think that f.__call__(*args,**kwds) of a polynomial f in
variables x,y,z should behave like a Python function of signature
f(x,y,z,**kwds). In particular, f(1,2,z=3, foo='bar') should do
exactly the same as f(1,2,3,foo='bar').

Note that currently the situation is not very consistent.

On the one hand, we already have the behaviour that you wish:
sage: R.<x,y> = ZZ[]
sage: P.<a,b> = QQ[]
sage: f = x+y
sage: parent(f(a,b))
Multivariate Polynomial Ring in a, b over Rational Field
sage: parent(f(x=a,y=b))
Multivariate Polynomial Ring in a, b over Rational Field
sage: parent(f(1,b))
Multivariate Polynomial Ring in a, b over Rational Field

But on the other hand, we have the inconsistency that started this
thread:
sage: parent(f(x=1,y=2))
Multivariate Polynomial Ring in x, y over Integer Ring
sage: parent(f(1,2))
Integer Ring

> The difficult case is what to do for f(x=5). Should that be the same
> as f(x=5, y=y) or a univariate polynomial?

I tend to believe that if you evaluate k variables of a polynomial
with n variables then the result should be a polynomial with n-k
variables. That having said, I wonder whether one should really make a
special case for k==n: Should the result be an element of the base
ring, or should it actually be a polynomial in zero variables?

Cheers,
Simon

[Simon King]

Hi Chris,

On 14 Mrz., 23:31, chris wuthrich <christian.wuthr...@gmail.com>
wrote:

> I hope we agree that evaluation (meaning evaluation of all variables
> by some elements in a ring) should yield an element of the ring. I
> don't mind if subs should give back a polynomial in all cases.
>
> [Aside: Strangely this is not the case for symbolic expressions. I am
> sure there must have been a discussion on this and I missed it. E.g.
> f(x) = sin(x)
> f(1.).floor()
> does not work.]

Well, f(1.) is in fact contained in the base ring of the parent of f,
so everything is formally fine:
sage: f.parent()
Callable function ring with arguments (x,)
sage: f.parent().base_ring()
Symbolic Ring
sage: f(1.).parent()
Symbolic Ring

> No I am against changing this. For two reasons, when working with
> polynomials in variable names liks "k", "p". It is not always easy to
> remember which was the first and which was the second variable. Then
> it is very handy to pass keywords for evaluation - but still to expect
> a base_ring element.

+1 (but where is the second reason?)

> Instead I think we should check that all variables are evaluated. This
> would be consistent with the call f(2,3) which screams when the number
> of variables is not correct. Even better, we could check if the result
> is really a ring element after substitution, which is easy to do. E.g.
> I would allow
> f = x*(x+y)
> f(x=0)
> but not
> f(x=1)

I don't like this approach. I would allow both f(x=0) and f(x=1), in
both cases returning a univariate polynomial.

Cheers,
Simon

[chris wuthrich]

> > No I am against changing this. For two reasons, when working with
> > polynomials in variable names liks "k", "p". It is not always easy to
> > remember which was the first and which was the second variable. Then
> > it is very handy to pass keywords for evaluation - but still to expect
> > a base_ring element.
>
> +1 (but where is the second reason?)

Well, given that my message got posted three times, there are 3
reasons already :)
The other (which I forgot to include in the end) is that it would
probably imply a lot of changes throughout the full sage code and many
people might be used to the syntax.

> > Instead I think we should check that all variables are evaluated. This
> > would be consistent with the call f(2,3) which screams when the number
> > of variables is not correct. Even better, we could check if the result
> > is really a ring element after substitution, which is easy to do. E.g.
> > I would allow
> > f = x*(x+y)
> > f(x=0)
> > but not
> > f(x=1)
>
> I don't like this approach. I would allow both f(x=0) and f(x=1), in
> both cases returning a univariate polynomial.

Mathematically I fully agreee with you. I would expect an element of
R[x,y]/(x) = R[x,y]/(x-1) = R[y] in both cases.

But if we want to stick to the principle that the type should be the
same for all returned answers, we would have to do
f.subs() gives back an element of the parent of f
and f(..) gives back an element of the base-ring of f and hence it
would only be allowed to be used in case the evaluation really yields
an element in there.

My suggestion above is based on the fact that it is very easy to check
if the result is in the base_ring. Maybe it is just as easy to check
if the length of the keywords is equal to the number of variables.

Chris.

[Moritz Minzlaff]

> Given f in R[x,y], I think f(x=a, y=b) should do exactly the same
> thing as f(a,b). The parent should be the same as R.base_ring()(0) + a
> + b.

+1

> The difficult case is what to do for f(x=5). Should that be the same
> as f(x=5, y=y) or a univariate polynomial?

I would certainly read f(x=5) as short for f(x=5,y=y). Hence (by the
same reasoning as above) I would expect a bivariate polynomial as
answer.

[chris wuthrich]

I opened a separate ticket #10946 for this issue.

Hopefully someone with better knowledge of keywords, evaluations,
polynomials, singulars and such will find a way to solve it.
Thanks for the comments.

Chris.