on floating-point numbers

Hope Rouselle hrouselle at jevedi.com
Sat Sep 4 09:04:41 EDT 2021


Chris Angelico <rosuav at gmail.com> writes:

> On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle <hrouselle at jevedi.com> wrote:
>>
>> 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.)
>
> It's not about the commutativity of any particular pair of operands -
> that's always guaranteed. 

Shall we take this seriously?  It has to be about the commutativity of
at least one particular pair because it is involved with the
commutavitity of a set of pairs.  If various pairs are involved, then at
least one is involved.  IOW, it is about the commutativity of some pair
of operands and so it could not be the case that it's not about the
commutativity of any.  (Lol.  I hope that's not too insubordinate.  I
already protested against a claim for associativity in this thread and
now I'm going for the king of the hill, for whom I have always been so
grateful!)

> What you're seeing here is the results of intermediate rounding. Try
> this:

Indeed.  Your post here is really great, as usual.  It offers a nice
tool for investigation.  Thank you so much.

>>>> def sum(stuff):
> ...     total = 0
> ...     for thing in stuff:
> ...             total += thing
> ...             print(thing, "-->", total)
> ...     return total
> ...
>>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>>> sum(ls)
> 7.23 --> 7.23
> 8.41 --> 15.64
> 6.15 --> 21.79
> 2.31 --> 24.099999999999998

Alright.  Thanks so much for this example.  Here's a new puzzle for me.
The REPL makes me think that both 21.79 and 2.31 *are* representable
exactly in Python's floating-point datatype because I see:

>>> 2.31
2.31
>>> 21.79
21.79

When I add them, the result obtained makes me think that the sum is
*not* representable exactly in Python's floating-point number:

>>> 21.79 + 2.31
24.099999999999998

However, when I type 24.10 explicitly, the REPL makes me think that
24.10 *is* representable exactly:

>>> 24.10
24.1

I suppose I cannot trust the appearance of the representation?  What's
really going on there?  (Perhaps the trouble appears while Python is
computing the sum of the numbers 21.79 and 2.31?)  Thanks so much!


More information about the Python-list mailing list