-------- Original Message --------
Subject: Re: Now seriously: what is a polynomial?
Date: Wed, 9 Oct 2002 19:17:28 +0200
From: Christian Bauer <cbauer(a)zino.physik.uni-mainz.de>
Reply-To: ginac-list(a)zino.physik.uni-mainz.de
To: ginac-list(a)zino.physik.uni-mainz.de
References: <3DA4424F.3020805(a)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
