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
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
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
CVSROOT: /cvs/purrs
Module name: purrs
Changes by: zolo(a)cs.unipr.it 2002-03-07 08:57:38
Modified files:
src : rr_solver.cc
Log message:
Fixed two errors:
1.When function 'solve' see if all the occurrences of `x(e)' are such that
`e' is numeric.
2.In the binary case when we have double root.
Patches:
http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/rr_solver.cc.diff?cvsro…
CVSROOT: /cvs/purrs
Module name: purrs
Changes by: zolo(a)cs.unipr.it 2002-03-06 12:39:42
Modified files:
src : rr_solver.cc
Log message:
Fixed an error: the exponential's coefficient must be expanded when
passed to the function sum_poly_times_exponentials().
Patches:
http://www.cs.unipr.it/cgi-bin/cvsweb.cgi/purrs/src/rr_solver.cc.diff?cvsro…
