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/