Bug introduced in 7.0 and persisting through 11.0.1 or later

NIntegrate returns an error complaining that ComplexInfinity is an invalid limit of integration when passed exact input but not when passed approximate input.

eps = 1*^-8;
s1 = InverseJacobiCN[eps, 7/10];
s2 = InverseJacobiCN[-eps, 7/10];

 Log[Abs[s - EllipticK[7/10]]], {s, s1, EllipticK[7/10], s2}, 
 PrecisionGoal -> 10, WorkingPrecision -> 20]

NIntegrate::nlim: s = ComplexInfinity is not a valid limit of integration. >>

The limits are not infinite:

N[{s1, EllipticK[7/10], s2}, 20]

I get no error if I approximate the input to a precision of at least the WorkingPrecision. (I get an expected NIntegrate::precw precision warning if the precision is set less than WorkingPrecision, but the result is still computed.)

NIntegrate @@ 
 N[{Log[Abs[s - EllipticK[7/10]]], {s, s1, EllipticK[7/10], s2}, 
   PrecisionGoal -> 10, WorkingPrecision -> 20}, 20]
(*  -6.8716155958584042728*10^-7  *)

I suppose this is probably a bug. Anyone have another explanation?

  • 1
    $\begingroup$ Note that Integrate can evaluate the integral and after converting to numerical value gives -6.8716155958619248034*10^-7 $\endgroup$ – Bob Hanlon Aug 5 '15 at 3:54
  • 3
    $\begingroup$ NIntegrate is effectively doing Block[{$MinPrecision = $MaxPrecision = 20}, N[EllipticK[7/10], 20]] which doesn't go so well. $\endgroup$ – ilian Aug 5 '15 at 5:01
  • $\begingroup$ Thanks @ilian, that sounds like the answer. It also sounds like a bug I should report, yes? Do you know how far back this behavior goes? $\endgroup$ – Michael E2 Aug 5 '15 at 10:06
  • $\begingroup$ Just for completeness: what happens if you replace EllipticK[7/10] with π/(2 ArithmeticGeometricMean[1, Sqrt[3/10]])? $\endgroup$ – J. M. will be back soon Aug 6 '15 at 16:10
  • $\begingroup$ @J.M. It works with no problem; the problem seems to be evaluating EllipticK[7/10] with the constraints on precision. $\endgroup$ – Michael E2 Aug 6 '15 at 16:59

The reason for this error is that NIntegrate uses fixed precision when computing the integration ranges, while EllipticK needs to raise the precision internally to obtain a good result.

N[EllipticK[7/10], 20]

(* 2.0753631352924691439 *)

Block[{$MinPrecision = $MaxPrecision = 20}, N[EllipticK[7/10], 20]]

(* Divide::infy: Infinite expression 1.0000000000000000000/0 encountered. >> *)
(* ComplexInfinity *)

I have submitted a bug report for this issue, thank you for bringing it up. One possible workaround, as mentioned in the question, is to numericize EllipticK[7/10] in advance (only needed in the range, the numerical evaluation of the integrand is fine).

As suggested by Guess who it is. ♦ in the comments, we can also obtain a result by expressing EllipticK in terms of ArithmeticGeometricMean:

eps = 1*^-8;
s1 = InverseJacobiCN[eps, 7/10];
s2 = InverseJacobiCN[-eps, 7/10];
elk = Pi/(2 ArithmeticGeometricMean[1, Sqrt[3/10]]);
NIntegrate[Log[Abs[s - EllipticK[7/10]]], {s, s1, elk, s2}, 
 PrecisionGoal -> 10, WorkingPrecision -> 20]

(* -6.8716155958619248037*10^-7 *)
  • $\begingroup$ How very odd. I had assumed EllipticK[] was using AGM under the hood, so I was expecting that the same error should pop up. Very curious indeed… $\endgroup$ – J. M. will be back soon Aug 6 '15 at 16:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.