-------- Original Message -------- Subject: Re: Now seriously: what is a polynomial? Date: Wed, 9 Oct 2002 19:17:28 +0200 From: Christian Bauer <cbauer@zino.physik.uni-mainz.de> Reply-To: ginac-list@zino.physik.uni-mainz.de To: ginac-list@zino.physik.uni-mainz.de References: <3DA4424F.3020805@cs.unipr.it> Hi! On Wed, Oct 09, 2002 at 04:50:55PM +0200, Roberto Bagnara wrote:

As a general remark, several concepts are defined only through examples whereas formal definitions would help greatly.

Agreed.

2) The method `info(info_flags::polynomial)' should constitute, we used to believe, the very formal specification of the notion of "being a polynomial".

Yes, that's what info_flags::polynomial was intended for.

3) The message by Christian Bauer (March 7th, 2002, see http://www.ginac.de/lists/ginac-list/msg00232.html): [...] degree(sin(y)^3-sin(y),sin(y)) which is guaranteed to return 3."

The problem is that, while 1 is inconclusive, 2 and 3 (with the correction replacing "integer" by "nonnegative integer") conflict with each other.

3) wasn't intended to define "polynomial". degree() works on a class of expressions that is a superset of the class of polynomials.

e = sqrt(2)*x e.info(info_flags::polynomial) == false

That's a case where the GiNaC definition of a polynomial clashes with the "intuitive" one. info() should probably return 'true' here, because sqrt(2) is clearly a number. But so is zeta(3), and I'm not sure how to handle this in a way that is general enough.

The point here is to decide _exactly_ for which class of expressions are the functions degree(), ldegree(), coeff(), lcoeff(), tcoeff(), expand(), collect(), quo(), rem(), prem(), gcd(), lcm(), sqrfree() and so forth guaranteed to work.

An exact specification of the maximal classes of expressions that these functions can operate on and the exact results they produce would require more work than I'm willing to invest (that's partly because GiNaC was designed for a bunch of physicists to "get some work done", not as a collection of rigorously defined functions). I'd be more comfortable if you could propose a set of specifications for these functions (for the cases you need), where I can say "Yes, this will work in all future versions of GiNaC", even if these are not the 'maximal' specifications. Bye, Christian -- / Coding on PowerPC and proud of it \/ http://www.uni-mainz.de/~bauec002/ -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:bagnara@cs.unipr.it