Bug in Elliptic Integral, Maple V to Maple 8 (25.7.01)

Tim McLarnan

I’m not a big expert on special functions, but it appears to me that Maple has been incorrectly calculating the values of incomplete elliptic integrals at least since Maple V. The problem I’ll describe here exists on my Intel box under both Maple 6 and Maple 7. The values computed by Maple V release 5 on a Mac are slightly different from Maple 7’s answers, but also wrong.

The errors are not small - in one example, Maple computes a value of 1.80+0.62i when the correct answer is 0.27+0.97i.

Here’s an example with the EllipticE function. Maple reports the value

On the other hand, the EllipticE function is defined by an integral which Maple can evaluate explicitly,

(This second calculation takes Maple close to 10 minutes on my computer; MuPAD confirms the result in a couple of seconds.)

I think the results of these calculations should be equal, and they are not.

Similarly, with the EllipticF function, Maple gives the value

Working out numerically the defining integral for this function yields (again confirmed by MuPAD)

Again, I think these two calculations should have given the same result, and they do not.

Now, it would be easy to dismiss these observations as

(1) Of no consequence, because when was the last time anybody used an incomplete elliptic integral, and

(2) Probably a misunderstanding on the part of someone who doesn’t know that much about special functions. (Guilty.)

Let me argue that instead, this is a problem that could bite any user, and that my values for these functions are right (and Maple’s wrong).

Consider the function sqrt((x^2+1)/(x+2)). This is a positive real function for \(x > -2\). A plot suggests that int(sqrt((x^2+1)/(x+2)), x=-1..5) should be about 8.

Maple computes this integral using incomplete elliptic integrals, including the two discussed above.

Maple then asserts that the numerical value of the integral is

an obviously absurd answer. A correct answer can be obtained by replacing a limit of integration by a float:

The first explanation that would occur to one here is that Maple’s integral is wrong, but I think this is not so. One can differentiate Maple’s value for the integral int(sqrt((t^2+1)/(t+2)), t=-1..x) by hand, and one seems to get sqrt((x^2+1)/(x+2)) back, just as one ought. The real clincher, though, is that if one takes Maple’s expression for the definite integral and plugs in the values I computed above for the EllipticE and EllipticF functions, the result is 7.277500984, which agrees exactly with the result of computing the definite integral numerically. (There are 4 elliptic integrals in Maple’s definite integral; Maple seems to compute 2 of them right, and 2 of them wrong.)

A Maple worksheet showing a bit more detail on all this is at


I’ve checked the calculations here with Maple 6 under Windows and Linux, Maple 7 under Linux, and Maple V release 5 under MacOS. The exact wrong answers differ slightly between Maple V and Maple 7, but all these versions show the same problem.

I hope I’m just doing something wrong here, but if not, it’s extremely alarming to me that one seems not to be able to rely on Maple correctly to compute the values of fundamental functions, and that bugs of this sort can persist for so many years.

Frederic PASCAL (14.9.01)

for computing the numerical value of the integral

Int(sqrt((x^2+1)/(x+2)), x=-1..5)

you first compute an algebraic expression of the integral then you ask for a numerical evaluation of the later expression.

You are increasing all the chances to get a wrong result and it is the case. Indeed it is a problem of rounding errors.

Let’s take a more simple integral :

Int(x^n/(x+a),x=0..1) with n=10 and a=10

The integral should be less than 1.

The algebraic expression is the following :

Now when Maple (MapleV5) computes

Maple first computes the algebraic expression, then evaluates the floating expression with Digits:=10. During this step, it is doing a rounding error since you are computing a small value as the difference of large numbers.

The computation of ln is correct (well the 10 first digits, the next ones 0 are not) but you don’t have enough digits to compute an exact difference.

Here the exact value is (now Maple doesn’t compute an algebraic expression)

Remarks with Digits:=25 you get an almost correct value

In your case, the problem is of the same order (i also don’t know much about special functions) :

I could not reproduce the first two results (U. Klein)

Using numerics with Maple must be done with precaution.

James R. FitzSimons (24.9.01)

Maple has a bug.

Maple is giving the wrong answer using elliptic integrals.

This is the numeric result using DERIVE.