Discussion:
integrate 'quotient by zero' error message
Edwin Woollett
2011-10-29 21:42:40 UTC
Permalink
I'm guessing the integrate code finds divide by
zero here?

The "quotient by zero" error message seems
unclear English.
----------------------

(%i25) integrate(sin(x+sqrt(x))/(1+x),x,0,inf);

`quotient' by `zero'

-- an error. To debug this try: debugmode(true);

(%i26) integrate(sin(x+sqrt(x))/(1+x),x,0,10);

`quotient' by `zero'

-- an error. To debug this try: debugmode(true);

(%i27) integrate(sin(x+sqrt(x))/(1+x),x);

`quotient' by `zero'

-- an error. To debug this try: debugmode(true);
-----------------------------------
Ted Woollett
Panagiotis Papasotiriou
2011-10-29 23:07:00 UTC
Permalink
Post by Edwin Woollett
I'm guessing the integrate code finds divide by
zero here?
The "quotient by zero" error message seems
unclear English.
----------------------
Integrand's denominator is obviously nonzero for any x within the
integration interval. If I were to guess, I'd say that Maxima tries to
compute the indefinite integral first, doing a transformation maybe.
Somewhere there the error message is generated, no idea why.
Post by Edwin Woollett
(%i25) integrate(sin(x+sqrt(x))/(1+x)**,x,0,inf);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
Integral is probably divergent; It seems that Integral value is oscillating
around ~0.458 and never converges. This doesn't explain the error message
though.
Post by Edwin Woollett
(%i26) integrate(sin(x+sqrt(x))/(1+x)**,x,0,10);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
I wouldn't even try integrate() with such an integrand, to be honest.
Integral for x in [0,10] can be easily computed by quad_quags and it is
~0.3911.
Post by Edwin Woollett
(%i27) integrate(sin(x+sqrt(x))/(1+x)**,x);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
Indefinite integral cannot be computed analytically, but that doesn't
explain why Maxima gives that error message. However, it seems the error
message is generated before any try to compute the integral numerically, as
I guessed.
Raymond Toy
2011-10-29 23:41:35 UTC
Permalink
Post by Edwin Woollett
I'm guessing the integrate code finds divide by
zero here?
The "quotient by zero" error message seems
unclear English.
----------------------
Integrand's denominator is obviously nonzero for any x within the
integration interval. If I were to guess, I'd say that Maxima tries to
compute the indefinite integral first, doing a transformation maybe.
Somewhere there the error message is generated, no idea why.
To know what it's doing, you'll have to dig through the code, putting
breakpoints or prints in appropriate places. To find out where the
message is generated, I usually do what it says. When the error is
generated, you're left in the maxima debugger. I press C-c to interrupt
and look at the stack trace (> 20 levels) to see where the message was
generated.

It is a giant pain to debug problems in integration. The 'quotient by
zero' bug is a well-known issue that is usually caused by the gcd
algorithm. Sometimes changing the gcd algorithm fixes things, but
sometimes not. It's probably a bug in the algorithm but no one has been
able to figure it out, mostly because no one has found a simple enough
problem to illustrate the error.
Post by Edwin Woollett
Indefinite integral cannot be computed analytically, but that doesn't
explain why Maxima gives that error message. However, it seems the
error message is generated before any try to compute the integral
numerically, as I guessed.
integrate never computes the integral numerically. It's all symbolic,
but the symbolic answer might be a number. Perhaps you had a different
meaning for "numerically"?

Ray
Dieter Kaiser
2011-10-29 23:59:25 UTC
Permalink
Post by Edwin Woollett
I'm guessing the integrate code finds divide by
zero here?
The "quotient by zero" error message seems
unclear English.
----------------------
(%i25) integrate(sin(x+sqrt(x))/(1+x),x,0,inf);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
(%i26) integrate(sin(x+sqrt(x))/(1+x),x,0,10);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
(%i27) integrate(sin(x+sqrt(x))/(1+x),x);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
-----------------------------------
I do not have this problem with the current version of Maxima from git.
I get noun forms for the integrals.

Maxima 5.25post http://maxima.sourceforge.net
using Lisp SBCL 1.0.45
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.

(%i2) integrate(sin(x+sqrt(x))/(1+x),x);
(%o2) 'integrate(sin(x+sqrt(x))/(x+1),x)
(%i3) integrate(sin(x+sqrt(x))/(1+x),x,0,inf);
(%o3) 'integrate(sin(x+sqrt(x))/(x+1),x,0,inf)
(%i4) integrate(sin(x+sqrt(x))/(1+x),x,0,10);
(%o4) 'integrate(sin(x+sqrt(x))/(x+1),x,0,10)

Dieter Kaiser
Edwin Woollett
2011-10-30 19:02:39 UTC
Permalink
On Oct. 29, Raymond Toy wrote:
---------------------------------------
Post by Raymond Toy
To know what it's doing, you'll have to dig through the code, putting
breakpoints or prints in appropriate places. To find out where the
message is generated, I usually do what it says. When the error is
generated, you're left in the maxima debugger. I press C-c to
interrupt
Post by Raymond Toy
and look at the stack trace (> 20 levels) to see where the message was
generated.
It is a giant pain to debug problems in integration. The 'quotient by
zero' bug is a well-known issue that is usually caused by the gcd
algorithm. Sometimes changing the gcd algorithm fixes things, but
sometimes not. It's probably a bug in the algorithm but no one has
been
Post by Raymond Toy
able to figure it out, mostly because no one has found a simple enough
----------------------
The message is generated in rat3b.lisp, lines 150 or 172.
Using search_mfiles from ch. 2 software mfiles.mac, with
copy of source in c:/maxsource.
-----------------------------------------
(%i1) display2d:false$
(%i2) integrate(sin(x+sqrt(x))/(1+x),x);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);

(%i3) load(mfiles);
(%o3) "c:/work2/mfiles.mac"
(%i4) search_mfiles("c:/maxsource/","quotient");

ignore quotient by itself, only look for error messages:

c:/maxsource/combin.lisp
864 (cond ((zerop q) (maxima-error "find-cf: quotient by zero"))

c:/maxsource/float.lisp
738 (merror (intl:gettext "pquotient: attempted quotient by zero.")))

c:/maxsource/rat3a.lisp
45 (t (errrjf "quotient is not exact"))))
392 when (minusp k) do (errrjf "Polynomial quotient is not exact")

c:/maxsource/rat3b.lisp
150 (cond ((pzerop (car y)) (errrjf "`quotient' by `zero'"))
172 (cond ((pzerop y) (errrjf "`quotient' by `zero'"))
-----------------------------------------

Evidently, all code writers like the phrase "quotient by zero" in an
error message. Wouldn't "divide by zero" be more appropriate?
Or even "Code fails to accomodate this case".
And the message only seems appropriate as a debug message
for code writers, not an informative message for the general user.

Ted
Dieter Kaiser
2011-10-30 19:21:32 UTC
Permalink
Post by Edwin Woollett
---------------------------------------
Post by Raymond Toy
To know what it's doing, you'll have to dig through the code, putting
breakpoints or prints in appropriate places. To find out where the
message is generated, I usually do what it says. When the error is
generated, you're left in the maxima debugger. I press C-c to
interrupt
Post by Raymond Toy
and look at the stack trace (> 20 levels) to see where the message was
generated.
It is a giant pain to debug problems in integration. The 'quotient by
zero' bug is a well-known issue that is usually caused by the gcd
algorithm. Sometimes changing the gcd algorithm fixes things, but
sometimes not. It's probably a bug in the algorithm but no one has
been
Post by Raymond Toy
able to figure it out, mostly because no one has found a simple enough
----------------------
The message is generated in rat3b.lisp, lines 150 or 172.
Using search_mfiles from ch. 2 software mfiles.mac, with
copy of source in c:/maxsource.
-----------------------------------------
(%i1) display2d:false$
(%i2) integrate(sin(x+sqrt(x))/(1+x),x);
`quotient' by `zero'
-- an error. To debug this try: debugmode(true);
(%i3) load(mfiles);
(%o3) "c:/work2/mfiles.mac"
(%i4) search_mfiles("c:/maxsource/","quotient");
c:/maxsource/combin.lisp
864 (cond ((zerop q) (maxima-error "find-cf: quotient by zero"))
c:/maxsource/float.lisp
738 (merror (intl:gettext "pquotient: attempted quotient by zero.")))
c:/maxsource/rat3a.lisp
45 (t (errrjf "quotient is not exact"))))
392 when (minusp k) do (errrjf "Polynomial quotient is not exact")
c:/maxsource/rat3b.lisp
150 (cond ((pzerop (car y)) (errrjf "`quotient' by `zero'"))
172 (cond ((pzerop y) (errrjf "`quotient' by `zero'"))
-----------------------------------------
Evidently, all code writers like the phrase "quotient by zero" in an
error message. Wouldn't "divide by zero" be more appropriate?
Or even "Code fails to accomodate this case".
And the message only seems appropriate as a debug message
for code writers, not an informative message for the general user.
What is the version of Maxima you are using. I dot not see the problem
with the current version 5.25post. I get a noun form for the integral.

Maxima 5.25post http://maxima.sourceforge.net
using Lisp SBCL 1.0.45
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.

(%i2) integrate(sin(x+sqrt(x))/(1+x),x);
(%o2) 'integrate(sin(x+sqrt(x))/(x+1),x)

Dieter Kaiser
Edwin Woollett
2011-10-30 19:26:59 UTC
Permalink
On Oct. 30, 2011, Dieter Kaiser wrote:
-------------------
Post by Dieter Kaiser
What is the version of Maxima you are using. I dot not see the problem
with the current version 5.25post. I get a noun form for the integral.
I am using the Windows binary installation for
version 5.25.1GCL

Maxima 5.25.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.8 (a.k.a. GCL)

Ted
Richard Fateman
2011-10-30 22:27:40 UTC
Permalink
Post by Edwin Woollett
Evidently, all code writers like the phrase "quotient by zero" in an
error message. Wouldn't "divide by zero" be more appropriate?
Not really much better, but see below..
Post by Edwin Woollett
Or even "Code fails to accomodate this case".
That's terrible.
Post by Edwin Woollett
And the message only seems appropriate as a debug message
for code writers, not an informative message for the general user.
That's probably true.

I think the reason that this occurs is not that the polynomial gcd
programs have
a bug in them, but in how they are used. Let us say you have an expression
involving sqrt(x). For purposes of the rational function package let us
rename it:

z1 is now sqrt(x).

Next, say that the integration program in its various manipulations
generates an expression exp(log(x)/2), and that rational function package
renames it as z2.

Let us also say that some expression is developed like (z1^2-z2^2)/
(z1-z2).
The rational function package correctly computes the gcd of numerator
and denominator,
as z1-z2, and divides through by it.

Unfortunately, a closer look at that suggests that z1-z2 (or maybe
z1+z2) s equal to zero.

Now different versions of the polynomial gcd program are in some cases
more aware of
the possibilities of algebraic dependencies of the "variables" it makes
up, like z1, z2, ... and
so may avoid some of these situations.

in this particular example, there is a z83125 representing
%e^(%i*%e^(log(x)/2)) generated
as well as a z83126 representing %e^(%i*%e^(log(x)).

so we have a situation where z1=z2^2 or some such thing. Bad news.
whose bug is it though? Unlikely to be in rat3b.lisp whose programs
expects to
deal with canonical rational expressions in algebraically independent
variables, and
is merely reporting something incorrect that was handed to ratreduce.


maybe in ratrep or newvar which attempts to collect algebraically
independent components, but
sometimes doesn't do a careful enough job.
maybe in integrate, which neglects to simplify exp(log(x)/2) somewhere.


Incidentally, the wording of that message seems peculiar "`quotient' by
`zero'". Why not just
"quotient by zero" or "An internal program error: quotient by zero
in rational function; probably
caused by unexpected algebraic dependence of internal variables".

The program that is used to "throw" the errror to the top level is
errrjf. My attempt to keep other people
from catching that error somewhere else. The program name is err+rjf,
my initials... and has been in there
since 1969 or so.

RJF




RJF
Post by Edwin Woollett
Ted
_______________________________________________
Maxima mailing list
http://www.math.utexas.edu/mailman/listinfo/maxima
Stavros Macrakis
2011-10-30 22:39:08 UTC
Permalink
Post by Edwin Woollett
...
Evidently, all code writers like the phrase "quotient by zero" in an
error message. Wouldn't "divide by zero" be more appropriate?
Or even "Code fails to accomodate this case".
And the message only seems appropriate as a debug message
for code writers, not an informative message for the general user.
I don't know why there are quotation marks around 'quotient' and 'zero' --
I think that is new (and ugly).

The reason it is "quotient by zero" and not "divide by zero" is presumably
that a symbolic expression of the form EXPR/0 has been generated as an
intermediate result somewhere. That is a quotient whose denominator is
zero, a meaningless construction. Maxima is not actually trying to divide
a number by zero, but to handle a division-expression (a quotient) which is
malformed.

I agree that "quotient by zero" in itself is not a useful error message for
the end user. Maybe something like "Internal inconsistency detected,
calculation aborted: quotient by zero" would be better. Even better if
every instance of every error had a unique ID, so that when users report
errors, we can be sure we're seeing the same error they're seeing,
e.g. "Internal inconsistency detected, calculation aborted: quotient by
zero at PQ1234".

-s
Richard Fateman
2011-10-30 23:01:41 UTC
Permalink
. Even better if every instance of every error had a unique ID, so
that when users report errors, we can be sure we're seeing the same
error they're seeing, e.g. "Internal inconsistency detected,
calculation aborted: quotient by zero at PQ1234".
well, a reference to the code will not be terribly informative. I think
the message originates in one of 2 places.
ratinvert which computes 1/q and
ratquotient which computes p/q.

a reference to the program counter won't be of much help.
a reference to the denominator won't help. It is zero!
For detecting the cause of the error, a programmer might get some info..

a reference to the numerator might supply some info.
a backtrace might help.


RJF

Edwin Woollett
2011-10-30 19:21:42 UTC
Permalink
Post by Dieter Kaiser
I do not have this problem with the current version of Maxima from git.
I get noun forms for the integrals.
Maxima 5.25post http://maxima.sourceforge.net
using Lisp SBCL 1.0.45
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i2) integrate(sin(x+sqrt(x))/(1+x),x);
(%o2) 'integrate(sin(x+sqrt(x))/(x+1),x)
(%i3) integrate(sin(x+sqrt(x))/(1+x),x,0,inf);
(%o3) 'integrate(sin(x+sqrt(x))/(x+1),x,0,inf)
(%i4) integrate(sin(x+sqrt(x))/(1+x),x,0,10);
(%o4) 'integrate(sin(x+sqrt(x))/(x+1),x,0,10)
Thanks for the update, which is good news.
I can delay writing an interface to integrate
which catches bad news events and shields
users of nint.mac from such.

Ted
Loading...