on floating-point numbers

[Christian Gollwitzer]

Am 02.09.21 um 15:51 schrieb Hope Rouselle:
> Just sharing a case of floating-point numbers.  Nothing needed to be
> solved or to be figured out.  Just bringing up conversation.
> 
> (*) An introduction to me
> 
> I don't understand floating-point numbers from the inside out, but I do
> know how to work with base 2 and scientific notation.  So the idea of
> expressing a number as
> 
>    mantissa * base^{power}
> 
> is not foreign to me. (If that helps you to perhaps instruct me on
> what's going on here.)
> 
> (*) A presentation of the behavior
> 
>>>> import sys
>>>> sys.version
> '3.8.10 (tags/v3.8.10:3d8993a, May  3 2021, 11:48:03) [MSC v.1928 64 bit (AMD64)]'
> 
>>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>>> sum(ls)
> 39.599999999999994
> 
>>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>>> sum(ls)
> 39.60000000000001
> 
> All I did was to take the first number, 7.23, and move it to the last
> position in the list.  (So we have a violation of the commutativity of
> addition.)

I believe it is not commutativity, but associativity, that is violated. 
Even for floating point, a+b=b+a except for maybe some extreme cases 
like denormliazed numbers etc.

But in general (a+b)+c != a+ (b+c)

Consider decimal floating point with 2 digits.
a=1
b=c=0.04

Then you get LHS;
  (1 + 0.04) + 0.04 = 1 + 0.04 = 1

RHS:

1 + (0.04 + 0.04) = 1 + 0.08 = 1.1


Your sum is evaluated like (((a + b) + c) + ....) and hence, if you 
permute the numbers, it can be unequal. If you need better accuracy, 
there is the Kahan summation algorithm and other alternatives: 
https://en.wikipedia.org/wiki/Kahan_summation_algorithm


	Christian