The following arbitrary-precision computations, in which arbitrary precision is applied early (to the inputs), both work as expected:

Exp[-I*Pi*x]*BesselK[-1, 2.43`20 I*x] /. x -> I*290

$-1.9774702657848900\times 10^{88}-2.4563516704146749\times 10^{700} I$


Exp[-I*Pi*x]*BesselK[-1, 243/100 I*x] /. x -> I*290.`20

$-1.9774702657848900\times 10^{88}-2.4563516704146749\times 10^{700} I$


But if I instead use only exact numbers, and convert to 20 digits of arbitrary precision at the end, I get an incorrect result for the real portion, along with an error message for the real portion, saying "no significant digits are available to display". At the same time, it erroneously reports that the result has a Precision of 20 (for complex numbers, MMA's standard behavior is to report a precision equal to that of whichever component has the lower precision):

N[Exp[-I*Pi*x]*BesselK[-1, 243/100*I*x] /. x -> I*290, 20]

$0.\times 10^{88}-2.4563516704146748709\times 10^{700} I$


The same thing happens up to N[...., 99]. Only by increasing to N[....,100] do I get a proper result:

N[Exp[-I*Pi*x]*BesselK[-1, 243/100*I*x] /. x -> I*290, 100];
NumberForm[%, 17]

$-1.9774702657848900\times 10^{88}-\left(2.4563516704146749\times 10^{700}\right) i$


Why is this?

I ask because this is the opposite of the behavior I generally see—namely that, to achieve a certain final precision, one needs to apply higher arbitrary precision conversions to exact inputs than to exact results, because of precision losses during calculations. Compare, for instance,





N[Sin[10^30], 20]



Here, the latter result is correct. In the former case, one needs to increase the input precision to 34 to avoid an error. In both of the above cases, Precision@% is reporting the correct value.

  • 2
    $\begingroup$ Use FunctionExpand to get a more numerically stable form: Exp[-I*Pi*x]*BesselK[-1, 243/100*I*x] /. x -> I*290 // FunctionExpand // N[#, 20] & $\endgroup$
    – Bob Hanlon
    Aug 21, 2018 at 2:23
  • $\begingroup$ @Bob Hanlon. Why does the expression's numerical instability create more problems when I apply arbitrary precision at the end? And, when dealing with forms that have such numerical instability, is it generally the case that it is "safer" to apply the arbitrary precision early (i.e., to the input), or is this merely specific to this particular expression? $\endgroup$
    – theorist
    Aug 21, 2018 at 2:28
  • $\begingroup$ I don't know. If I encounter a problem I experiment to find a workaround. This one worked in this case. $\endgroup$
    – Bob Hanlon
    Aug 21, 2018 at 2:35

2 Answers 2


Computing from input of given precision is different from asking for output of given precision. The former case is more straightforward: perform the computations and propagate estimated error. Since computer arithmetic on complex numbers breaks down into operations on the components, Mathematica may (and apparently does) keep track of the precision of the components separately.

The latter is more complicated, especially in the complex plane. A backward estimate of precision required for subexpression calculation is required. Mathematica's notion of precision is based on the estimated error in the absolute value. For a complex number, an insignificant component might as well be zero. If, in the backward precision estimate, bounds on the components show that a component is insignificant, it is reasonable for the machinery to set that component to zero, with an accuracy reflecting its insignificance but the possibility that it's not precisely zero. The machinery may thus avoid wasting time computing an insignificant component.

Mathematica does not appear to check complex results to see if they contain insignificant components. A correct but insignificant component with nonzero precision may thus appear in the result. Mathematica's error propagation machinery is conservative: the actual precision of a result is often higher that what Precision yields. An insignificant component thus violates no principle. On the other hand, setting such a component to a suitably inaccurate zero also violates no principle.

Therefore, there are no errors in your results. In principle, to force Mathematica to report significant values for both components of a complex number where those components differ in magnitude by 10^612, you should ask for more than 612 digits of precision. If you ask for less, you may or may not get what you want.

A further note:

If what you want is a 20 digit result for the real part, you can get it with a "pretty please":

Block[{$MaxExtraPrecision = 700}, 
  N[Re[E^(-I \[Pi] x) BesselK[1, (243 I x)/100] /. x -> I*290], 20]]
(* -1.9774702657848899755*10^88 *)
% // Precision
(* 20.1505 *)

The reason of the incorrect result is because of the cancellations in the polynomial form: If you use integers in some of the arguments, there may be cancellations in the interior of the code which leads to incorrect results for insufficient precision.

Therefore you should either put the arguments without infinite precision (as you did in your first example), or increase the precision if you use exact numbers in the special functions (as there can always be cancellations). This is actually discussed in Possible Issues section of JacobiP command.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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