Rational simplification bug ("Quotient by a polynomial of higher degree" error message)
Subject: Rational simplification bug ("Quotient by a polynomial of higher degree" error message)
From: Alan W. Irwin
Date: Wed, 28 Nov 2012 16:28:13 -0800 (PST)
On 2012-11-28 13:16-0800 Richard Fateman wrote:
> I haven't studied all this, but if you can paste the expression into a file
> FOO.txt
>
> then you can start maxima and do
>
> batch("FOO.txt")
>
> and it will be there... you could do fullratsimp(%);
>
> for example.
That method doesn't work because "fullratsimp(%);" simply operates on
the name of the batch file rather than the expression in that batch
file. However, a slight extension of the method
does work. Take the expression I attached previously in this thread,
store it in a file, edit that file to append a semicolon and an
additional line which consists of "fullratsimp(%);" after the
expression.
Then
batch("/tmp/test_irwin");
just "works".
That method "worked" for me here (using sage -maxima) which I presume
is very close if not identical with vanilla maxima. The batch file
dumped out the expression in a pretty-printed way, but then it had a
really interesting bit at the end (where I have left the last few
lines of the pretty-printed expression for context):
+ -----------------------------------------------
2 2 2 3/2
((z_0 - z_1) + (y_0 - y_1) + (x_0 - x_1) )
(%i4) fullratsimp(%)
Quotient by a polynomial of higher degree
-- an error. To debug this try: debugmode(true);
(%o4) /tmp/test_irwin
In sum, this is a method for maxima developers to confirm the pure
maxima conditions under which the error message is generated that
started this thread. So hopefully this will lead to a solution
for this issue.
I also tried other workarounds to simplify the expression that
were mentioned so far in this thread (and off-list to me).
Each of these tests was for a fresh invocation
of maxima (sage -maxima) since there was some early evidence that
could be interpreted that multiple batch or gcd commands were
interfering with each other.
I.
gcd : spmod$
batch("/tmp/test_irwin");
==>
(%i4) fullratsimp(%)
Quotient by a polynomial of higher degree
-- an error. To debug this try: debugmode(true);
(%o4) /tmp/test_irwin
This is the same error message (generated in a few seconds) as in the
default case so I assume gcd:spmod is the default. Furthermore,
this is the same error message that started this thread.
II.
gcd : ez$
batch("/tmp/test_irwin");
==>
(%i4) fullratsimp(%)
Maxima encountered a Lisp error:
The variable SUBVAL is unbound.
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%o5) /tmp/test_irwin
The above issue is obviously different from the
issue that was encountered with gcd:spmod. This error message
was encountered within a few seconds.
III.
gcd : subres$
batch("/tmp/test_irwin");
....
(%i4) fullratsimp(%)
Maxima encountered a Lisp error:
Memory limit reached. Please jump to an outer pointer, quit program and enlarge the
memory limits before executing the program again.
Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
(%o5) /tmp/test_irwin
It took ~35 minutes of cpu to get to this error message, and this
memory error occurred when maxima was grabbing something like 1GB of
my 2GBytes of real memory.
I also get this identical long and bad result with sage
when I set
sage: maxima_calculus('gcd:subres')
before attempting to simplify. So I am getting consistent results
(even if they are extremely slow and ultimately bad) with gcd:subres
for sage and maxima which implies I at least have the syntax right for
setting gcd correctly for both sage and maxima.
To summarize these results, regardless of what method I use to set the
gcd algorithm, maxima seems unable to simplify this expression with
various error messages being generated for each method that I try.
Note that previously in this thread I did attach the expression
so maxima developers here should be able to confirm all these
(bad) simplification results for themselves. Of course, if
the maxima developers here cannot confirm these issues, then it
may just be that I am stuck with a bad maxima version.
Also, from my experience and subject to the caveat that I might have a
bad maxima version, gcd:subres is a method to be avoided unless you
have access to a lot of physical memory for a long time. However, if
someone with access to those assets will give it a try, it might
provide confirming evidence that the expression should reduce to zero
which will provide a firm goal for what should be achievable by both
gcd:spmod and gcd:ez once they are debugged for this case.
I am now going to try a downloaded binary version of sage (and maxima)
to see if that version provides better simplification of preliminary
results (as suggested by someone else's results earlier in this
thread) so that these final simplification issues discussed here are
bypassed. But note this is just a bypass, and ultimately
both gcd:spmod and gcd:ez should be fixed so the expression
attached earlier in this thread can be simplified to zero.
N.B. Regardless of the results for whether the the preliminary
simplification is any better for the binary version, I will also try
the above fixed tests in the binary maxima for simplification of the
more complex expression to see if that version change for maxima makes
any difference.
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
__________________________