[GiNaC-list] bug with is_polynomial?

[Alexei Sheplyakov]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 827 bytes
Desc: Digital signature
Url : http://www.cebix.net/pipermail/ginac-list/attachments/20080807/5754dc53/attachment.sig