# What is a polynomial in x?

Christian Bauer cbauer at thep.physik.uni-mainz.de
Thu Mar 7 15:55:02 CET 2002

```Hi!

On Thu, Mar 07, 2002 at 01:51:07PM +0100, Roberto Bagnara wrote:
>      sqrt(2)*x
>
> is a polynomial in x of degree 1 accordind to degree(), whereas the info()
> methods would simply classify is as a non-polynomial.

It seems that info() needs to be fixed. But then, even

sqrt(2).info(info_flags::real)

returns false while one might expect it to be true. One might also expect
info_flags::positive to return true here. However, fixing this could get
involved and highly non-trivial, considering expressions like

sqrt(4-zeta(3)).info(info_flags::real)

Because zeta(3) remains unevaluated there's no easy way of knowing the sign
of the root's argument. Handling this would probably require some property
reasoning (note to self: or would it be sufficient to call evalf() on the
expression, see whether this returns a numeric, and delegate to
numeric::info()?).

Also, consider the expression

sqrt(y)*x

which is a polynomial in x, but not in y. degree(e, x) is guaranteed to work
here, but degree(e, y) is not. But info_flags::polynomial will of course
return false.

> 2) It is legal to say degree(sqrt(2)*x).

Yes.

> But then it would be useful to precisely characterize the class of
> expressions e and x such that degree(e, x) is well defined.

Is this possible? There might be terms sqrt(x) in e that cancel each other
after some transformations, so while the input expression might logically
be a polynomial, it is syntactically not.

But this is the intended behavior:
If e is of the form e = sum(i=n1..n2, a_i * x^i) with n1, n2 integer and
expressions a_i that satisfy has(a_i, x) == false, then degree(e, x) and
ldegree(e, x) are well defined and accurate.

I think this should even cover cases like

degree(sin(y)^3-sin(y),sin(y))

which is guaranteed to return 3.

Bye,
Christian

--
/ Coding on PowerPC and proud of it
\/ http://www.uni-mainz.de/~bauec002/

```