# Why does 1 - Exp[-10.0^12] cause an out-of-memory error?

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.

• Why did you remove your previous question? For me, this fact alone cannot fully explain what was happening. Mar 19, 2017 at 13:55
• With your numerical definition, NIntegrate[f[x, y], {x, 0, Infinity}, {y, -1, 1}, Method -> "LocalAdaptive"] runs without problem. It seems that the problem depends on methods specified. Mar 19, 2017 at 14:00
• It uses under 200K of memory on my machine. Mar 19, 2017 at 15:43
• @MichaelE2 Could you, please, check with a higher power of ten? I.e. 1 - Exp[-10.0^12] Mar 19, 2017 at 15:49

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.

• Is it a bug? A workaround seems to set SetSystemOptions["CatchMachineUnderflow" -> False]. Does this setting has undesirable side-effects? Mar 19, 2017 at 16:18
• 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. Mar 19, 2017 at 16:23
• Thank you, got it. Another example of this behavior is 1 - SetAccuracy[0, 10^12]. Mar 19, 2017 at 16:38