[erlang-questions] floating point exception when accuracy exceeds limit

[Richard A. O'Keefe]

On 20/01/2015, at 11:26 pm, Johan Montelius <johanmon@REDACTED> wrote:

> 
> This might be no news to anyone who is doing a lot of floating point arithmetics but it made me scratch my head.

It’s something we teach in second year: IEEE double precision floating point
numbers have DBL_MIN = 2.22...E-308 and DBL_MAX = 1.79...E+308.  This means
that the number 3.6E309 that you are trying to compute cannot be represented.
This has nothing to do with accuracy.

In most programming languages, you would get +Infinity as the answer.
f% gsi                 # Scheme
> (expt 6.0e154 2)
+inf.0
f% irb                 # Rugy
irb(main):001:0> x = 6.0e154
6.0e+154
irb(main):002:0> print x*x
Infinity
nil
f% gst                # GNU Smalltalk
st> 6.0e154 squared
Inf

Erlang reports an error instead of returning ±Infinity.
It would be a little more helpful if it *said* that it was an
overflow error.

Now some machines DO have floating point formats with wider ranges.
For example, the SPARC architecture includes 128-bit floats
(LDBL_MIN = 3.36...E-4392, LDBL_MAX = 1.18…E+4932)
and the x86 architecture has 80-bit floats (with nearly the same
range but less accuracy).
But this is not portable.  64-bit floats are the most you can
*rely* on getting.

There is a handful of things *every* programmer has to worry about when
using floating point arithmetic:
 - domain errors like divide by zero or square root of a negative number
   or acos(x) where |x| > 1
 - underflow (commonly reported as 0, but this can cause division by 0
   problems in expressions that are mathematically non-zero)
 - overflow
 - catastrophic cancellation (subtracting two numbers that are close,
   so that the result has very few meaningful bits)
 - adding numbers that are very different in magnitude, so that all
   or most of the information from the smaller one is lost
 - roundoff (if *all* you have to worry about is roundoff, you are
   either a lucky programmer or a good one ^_^)

If you have to take the product of a lot of numbers, one common approach
that avoids overflow is to take the product of the signs and
exp(the sum of the logarithms).  Would that be any use in your case?