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
Just taking a quick look at anther programming language I have with MPFR functionality
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?)
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.
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.
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
Most helpful comment
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:which would throw an error if any underflows occur inside.