12
$\begingroup$

I would like to understand why evaluation of the expression

1 - Exp[-10.0^12]

causes an out-of-memory error and how can I prevent such errors when calculating numeric integrals with decaying exponents.

For example an attempt to evaluate the following numeric integral:

f[x_Real, y_Real] := (1 - Exp[-x^2]) E^(-x Sqrt[1 + 1/2 (1 - y^2)]);
NIntegrate[f[x, y], {x, 0, Infinity}, {y, -1, 1}]

causes the following error message on Windows:

Throw::sysexc: Uncaught SystemException returned to top level. Can be caught with Catch[…, _SystemException]. >>

SystemException["MemoryAllocationFailure"]

while on OSX it causes a kernel restart.

Update: From the discussion in comments it became clear that when Mathematica encounters an exponent of a very large negative number (i.e. when the result cannot be represented as machine precision number) it automatically converts the number to arbitrary precision (see this question). One can prevent this conversion from happening using the command:

SetSystemOptions["CatchMachineUnderflow" -> False];

This trick makes evaluation of the above expressions possible.

What is still interesting to understand is why the evaluation of difference of arbitrary precision numbers causes a memory error.

$\endgroup$
9

1 Answer 1

17
$\begingroup$

Actually this is not a duplicate. The prior question is about underflows that require massive bignums to represent at machine precision, and that much is present here as well. So what @J.M notes is certainly a part of the issue. But it is not entirely a matter of cancellation error and a need to represent a very small number.

The problem is a combination of the below.

(1) A bignum is required for representing Exp[-10.0^4] even at $MachinePrecision digits.

(2) That number has low precision but high accuracy.

(3) The subtraction now involves a bignum of high accuracy and an exact number.

Were it a machine 1.0 it would be a different matter, and coercion would kick in and deliver a machine 1.0. But we have an exact and a bignum, of high accuracy, so the subtraction delivers a high accuracy result that requires the many digits.

$\endgroup$
3
  • $\begingroup$ Is it a bug? A workaround seems to set SetSystemOptions["CatchMachineUnderflow" -> False]. Does this setting has undesirable side-effects? $\endgroup$ Mar 19, 2017 at 16:18
  • 3
    $\begingroup$ It's not a bug, it's how significance arithmetic works. What the SystemOption does is to disable the transformation of what would be a machine underflow into a bignum, which in turn allows the arithmetic to remain in the realm of machine numbers. $\endgroup$ Mar 19, 2017 at 16:23
  • $\begingroup$ Thank you, got it. Another example of this behavior is 1 - SetAccuracy[0, 10^12]. $\endgroup$ Mar 19, 2017 at 16:38

Your Answer

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

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