Underflow should occur when evaluating exp for very small numbers

[younisshah]

When using exp function for very small numbers, instead of just returning 0, an underflow should occur. Consider the following snippet:

set_bigfloat_precision(100)
C = 5
m = BigFloat(9.10938356e-31)
ℏ = BigFloat(1.054571800e-34)
t = exp(-(sqrt(C * m) / ℏ))

In the last line, t evalutes to 0.

The reason for this behavior was explained to me very elegantly here on Stack Overflow by Oxinabox

[oxinabox]

Just taking a quick look at anther programming language I have with MPFR functionality

gAwk

awk -M '{ print exp(-1e8); print exp(-1e9);  };'  /dev/stdin #Press enter a few times
6.45171e-43429449
0

and unlike julia awk, does normally throw an exception on a underflow

awk '{print exp(-1e8);};'  /dev/stdin #Press enter a few times

awk: cmd. line:1: (FILENAME=/dev/stdin FNR=1) warning: exp: argument -1e+08 is out of range

So perhaps this suggests that it is accept-able to not raise exception on MFPR underflow.

(Cos gAwk is a well known numerical programming language, right?)

[oxinabox]

gmpy2, which I believe is the main python binding for mpfr (and GMP), does present an configurable option to throw an UnderflowError.

Which seem like generally a good idea.

[simonbyrne]

There is a longstanding open issue for accessing floating point exceptions (#2976), but in the general case that is going to require work on LLVM itself. However we could expose some of the MPFR functionality; we probably don't want to throw an error by default (as silent underflow is the default behaviour for most floating point numbers), but we could enable a switch (similar to gmpy2), or have something like:

check_exception(BigFloat, Underflow) do
    t = exp(-(sqrt(C * m) / ℏ))
end

which would throw an error if any underflows occur inside.

[oxinabox]

This can probably be closed as a being a subset of #2976

Since one of its points is:

Expose similar flag-handling behavior from MPFR