Rational simplification bug ("Quotient by a polynomial of higher degree" error message)

On 2012-11-28 12:54-0800 Alan W. Irwin wrote:

> Of course, what I am interested in a lot more is to confirm the
> simplfied Residual[0] result for nbody=3, 4, etc.  Since you have had
> success with that, I would like to replicate your sage-5.4.1 platform
> as closely as possible.  Can you describe that platform in more
> detail?  For example, did you build it yourself from vanilla
> sage-5.4.1 was that a patched version, or was that a binary download?
> And just in case it makes a difference, what hardware are you using,
> how many cpu's, etc.
>
> In my case I built (on a Debian Wheezy platform with Intel AMD64
> hardware) sage with everything default for the build other than
> setting export MAKE="make -j4" to take advantage of the two cpus for
> my hardware.  This (3-hour!) build automatically included a build of
> maxima-5.26.0. My understanding is such builds try to take advantage
> of all characteristics of your hardware to be as efficient as possible
> while the binary downloaded version of sage is more generic.
>
> It's possible the latter may be less prone to issues so my next step
> is to try a binary download of sage-5.4.1 to see if I can replicate
> the good result you got from my script for nbody=3. However, if your
> reply identifies some other sage-5.4.1 alternative you were using
> (such as a patched build), I would be happy to try that too.

I tried two different precompiled versions of sage, and neither
worked (because of library version incompatibilities).  So I
went back to the maxima (and sage) version I compiled myself and decided to
be smarter about how I demonstrated the expression (which I
have already attached to this thread) was actually zero.
It turns out if you append the following to the expression file,

expand(%);
fullratsimp(%);

then all is well, i.e., under sage -maxima the
batch method shows the following result:
... (list many terms still remaining from the expand)....
(%i11)                          fullratsimp(%)
(%o11)                                 0

So that is the result I wanted.  Furthermore,
the expand method even works
better under sage; it returns a zero result within a few seconds with no
simplification steps required afterward for nbody from 3 all the
way through 10.  (For nbody=10, the Residual[0] result goes
on for something like 5 pages).

In retrospect, I should have thought of expand a lot sooner since it
should be especially effective when you expect a zero result. Anyhow,
these good expand results for any value of nbody <= 10 finish off the
problem from my perspective.

However, for the maxima developers the following important issue
remains, and I wish you guys all the best in fixing it.  If you don't
expand the ncd=3 expression first that was attached earlier in this
thread, then the batch method errors out for every different kind of
gcd, even though it is easy to prove (please check this for yourself
by using expand) that the expression reduces to zero.

Remember, this is not actually that large an expression. 
For example,

irwin at raven> grep -o '\*' /tmp/test_irwin |wc -l

shows there are ~300 multiplications involved in the original
expression and there are similar numbers for addition operators and
subtraction operators.  Also, there are some exponentiations but those
are sqrt, squares, or the cube of sqrt, but not exponentiations of
large degree. So simplification of this expression is a lot more than
you would like to do by hand, but at least there are not millions of
operators involved.  Therefore, I fully expect gcd:spmod to handle it
cleanly and quickly with no errors once you have figured out the bug
that generated the error message that started this thread.

I plan to keep monitoring this list for a while out of curiosity to
see whether anybody is able to come up with a quick fix.  Meanwhile,
my thanks to several here who gave me quick help in giving me enough
maxima pointers so I could demonstrate the maxima simplification issue
I found indirectly with sage directly using maxima alone with
the batch method.

Also, I absolutely agree with Karl-Dieter that it is important to take
care of the paste-limit issue for maxima just to make testing easier
and more flexible.  Of course, the batch method is also viable for
handling large expressions, but it is not as convenient/flexible as
using cut and paste directly.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________