Hi! On Wed, Aug 06, 2008 at 01:42:19AM -0700, Jonathan Cross wrote:
I thought that if R is any ring,
As of now GiNaC can operate only on polynomials over (real) rational numbers. Extending GiNaC to handle polynomials over (reasonably) arbitrary ring would be nice, but this requires a lot of effort. On the over hand, there are a number of good (free) polynomial-oriented libraries/programs (Pari/GP, Singular, CoCoA, you name it), so it sounds like re-inventing the wheel.
then you could define the polynomial ring R[s], where the elements are "polynomials" in the variable s with coefficients in the ring R. Within this framework, the examples in my code are in the ring R[s], where R = the ring of continuous functions in the real variable x s = the polynomial variable.
This makes perfect sense, so here is the patch which gives the semantics you want: diff --git a/ginac/power.cpp b/ginac/power.cpp index f92233c..ed2d2c0 100644 --- a/ginac/power.cpp +++ b/ginac/power.cpp @@ -285,6 +285,8 @@ ex power::map(map_function & f) const bool power::is_polynomial(const ex & var) const { + if (!(basis.has(var) || exponent.has(var))) + return true; if (exponent.has(var)) return false; if (!exponent.info(info_flags::nonnegint)) It leads to a small problem, though. AFAIR several GiNaC functions (i.e. gcd(), normal()) use is_polynomial() to check if the argument is a polynomial over rationals. So these functions might be confused and give incorrect results. On the other hand, current implementation is broken anyway, so (hopefully) making it a little bit more broken won't hurt.
In which case, there's an inconsistency, as GiNaC reports sin(x) + 2*s is a polynomial in s, but pow(2,x) + 2*s is not a polynomial in s.
Sure, this is a bug.
I would think that (for GiNaC) these should either both be or neither be polynomials in s. Clearly neither is a polynomial in x.
I intend to fix it (the patch above is merely a work around), but I'm not quite sure how to proceed. I'd like to support the semantics you ask for. On the other hand, gcd() and friends need more strict variant. There are (at least) two ways to solve this collision: 1. Add the method is_real_polynomial(). 2. Add and optional argument to is_polynomial(), which tells if the coefficients are allowed to be arbitrary expressions (which don't depend on the main variable, of course) and defaults to off (so gcd() and friends need no modifications). N.B. Unfortunately, both variants break binary compatibility.
IMHO, calling such expressions polynomials in s makes more sense mathematically, and seems consistent with the examples in the GiNaC tutorial, section 5.7.1.
I haven't noticed any polynomial with non-rational coefficients in that section. Could you please be more specific? (Maybe you've found some bug in the tutorial itself?) Best regards, Alexei -- All science is either physics or stamp collecting.