integrate 'quotient by zero' error message



On Oct. 29, Raymond Toy wrote:
---------------------------------------
    > 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
----------------------
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