What is a polynomial in x?
We have some doubts on the handling of polynomials under GiNaC. The question we need to be answered is: what is, for GiNaC, a polynomial in a variable x? That is, for which class of expressions are the functions degree, ldegree, coeff, lcoeff, tcoeff... guaranteed to work? If this class is not the class of all expressions, it would be nice to have a function or method recognizing it so that one can do things like if (is_a_polynomial(e, x)) { // Here it is safe to use degree(e, x), ... } While we are trying to write code that depends only on the guarantees GiNaC offer, we would like to take the occasion of improving GiNaC's documentation (that is, if you answer nicely we will contribute a couple of paragraph for the section of the manual dealing with polynomials ;-) All the best Tatiana Zolo Roberto Bagnara -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
Hi! On Thu, Mar 07, 2002 at 12:58:59PM +0100, Roberto Bagnara wrote:
if (is_a_polynomial(e, x)) {
if (e.info(info_flags::polynomial)) { (there's also info_flags::integer_polynomial and a couple of others; the complete list is in the GiNaC tutorial)
While we are trying to write code that depends only on the guarantees GiNaC offer, we would like to take the occasion of improving GiNaC's documentation
That's always appreciated. :-) Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/
Christian Bauer wrote:
Hi!
On Thu, Mar 07, 2002 at 12:58:59PM +0100, Roberto Bagnara wrote:
if (is_a_polynomial(e, x)) {
if (e.info(info_flags::polynomial)) {
(there's also info_flags::integer_polynomial and a couple of others; the complete list is in the GiNaC tutorial)
Hmmm... the notion of polynomial in x that is implemented by degree, ldegree, and so forth, is more general (and rightly so, we believe). For instance, 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. I see two possibilities (but I may be wrong, of course): 1) it is illegal to say degree(sqrt(2)*x) and the fact that now this evaluates to the sensible value 1 is just an accident: it may stop working at any time. In other words, degree() and friends would be granted to work only for expressions e such that e.info(info_flags::polynomial) is true. 2) It is legal to say degree(sqrt(2)*x). But then it would be useful to precisely characterize the class of expressions e and x such that degree(e, x) is well defined. Am I missing something? Thanks a lot Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
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/
Christian Bauer wrote:
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.
I perfectly agree. In fact, what we are looking for is a _syntactic_ characterization of those GiNaC expressions for which degree, ldegree, coeff, tcoeff and lcoeff are guaranteed to give the right result.
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.
This is one possible syntactic characterization. Is this the one that the authors of GiNaC would like to adopt as _the_ definition of the syntactic domain where degree() and friends return a sensible result? Moreover, when degree() is called on something outside this domain, wouldn't it be better to throw an exception instead of returning with a value obtained in an undocumented way? Providing a function checking whether a given expression is inside the syntactic domain would also be useful (yes, we have been bitten by this kind of problem ;-) What do you think? Roberto -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it
On Thu, 7 Mar 2002, Christian Bauer wrote:
On Thu, Mar 07, 2002 at 12:58:59PM +0100, Roberto Bagnara wrote:
if (is_a_polynomial(e, x)) {
if (e.info(info_flags::polynomial)) {
(there's also info_flags::integer_polynomial and a couple of others; the complete list is in the GiNaC tutorial) [...]
Just one point: The precondition (e.info(info_flags::polynomial)==true) does not make it safe to call .degree(x) in the sense that the result is precise -- it might still be an upper limit. The reason is the same as always considering that even an unexpanded polynomial is a polynomial. Regards -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>
participants (3)
-
Christian Bauer
-
Richard B. Kreckel
-
Roberto Bagnara