7.88 bug in integration in Maple 6 and Maple 7 (17.9.01)

7.88.1 James R. FitzSimons

Maple 6 can not integrate this.

> Digits:=32; 
> evalf(3*Int(sqrt(689*t^4-1492*t^3+1076*t^2-292*t+29),t=0..1)); 
 
                             Digits := 32 
 
Error, (in evalf/int) unable to handle singularity
 

I tried int and it hung up so long I gave up.

I tried this on a demo of MuPad and it had no problem with this integral.

Does Maple 7 do better?

With Maple 7 you get no error message, but also no result (U. Klein)

It is corrected with Maple 8 (U. Klein)

7.88.2 Koch-Beuttenmueller (19.9.01)

I tried your integral in Maple7 with different Maple methods, different settings of Digits (between 25 and 35, but inside Int) and different integration boundaries (from minima to minima etc). I got a lot of confusing results when Maples will calculate it and when not. When I have a little bit more time, I think I will send it to the support.

Integration with method =_Sinc worked best.

7.88.3 Carl DeVore (19.9.01)

The function has no singularity. The polynomial is never even close to 0 (min of poly is about 1.58). I haven’t looked too deeply in the code, but I suspect that evalf/int will report a singularity simply because it cannot control the error at the high setting of Digits – some preset maximum number of function evaluations is exceeded. At the time of failure, it is trying a Newton-Cotes rule with a fixed precision of about 15 digits (see ?int,numerical), so there’s no way it will get 32 Digits (so why does it waste time trying?) Setting infolevel[all]:= 5 is quite instructive for this problem.

A very close reading of ?int,numerical leads to the following:

> evalf(3*Int(t-> sqrt(689*t^4-1492*t^3+1076*t^2-292*t+29), 0..1)); 
 
                  7.2372233683285928858266192109559
 

Very oddly, this syntax means to try the double exponential algorithm (_Dexp) without any singularity checking. How’s that for an inconsistent syntax? This leaves the question of why the _Dexp reported a singularity in the first place. I haven’t looked. It had only tried about 140 function evaluations before it gave up.

How does that compare with the MuPad answer?

7.88.4 Jim FitzSimons (19.9.01)

It was a MuPAD demo which has expired. The result using DERIVE is

refint:=7.2372233683285928858266192109560224139670679860175041633628865012154~ 
888690075741276743899218796756430656048864273883221690630787
 

This is the same value I got using MuPAD.