premature floating-point-overflow assumption in +/*

[Jingyi Hou]

Yet another floating-point-overflow issue:

(eval `(* 1d300 1d300 1d300 0))
raises floating-point-overflow error, we probably should have exploited commutativity a little bit

The attached patch seems to do the trick.

[Stas Boukarev (stassats)]

That's what should happen, since floating point numbers aren't commutative.

[Jingyi Hou (houjingyi)]

@stassats, I'm not quite sure about this.

Wikipedia (http://en.wikipedia.org/wiki/Floating_point) says "While floating-point addition and multiplication are both commutative (a + b = b + a and a×b = b×a), they are not necessarily associative."

Although I'm not quite sure if that's right, either.

[Stas Boukarev (stassats)]

For binary operators, it is commutative. But a + b + c isn't equal to a + c + b. As evidenced by (= (* 1.1 2.1 3.1) (* 3.1 2.1 1.1))

[Christophe Rhodes (csr21-cantab)]

Jingyi Hou <email address hidden> writes:

> @stassats, I'm not quite sure about this.
>
> Wikipedia (http://en.wikipedia.org/wiki/Floating_point) says "While
> floating-point addition and multiplication are both commutative (a + b =
> b + a and a×b = b×a), they are not necessarily associative."
>
> Although I'm not quite sure if that's right, either.

It's the associativity that matters here, though. If traps are off:

(* 0 (* 1d300 1d300)) should give a NaN (the first multiply gives an
infinity; the integer 0 is coerced to double float, and 0 times Inf =
NaN.

(* (* 0 1d300) 1d300) should give 0d0; the 0 is coerced to double float;
0d0 times 1d300 is 0d0; and 0d0 times 1d300 is 0d0 again.

Christophe

[Jingyi Hou (houjingyi)]

That's right, I got it now. My bad.

Thanks, @stassats @csr21-cantab