[docs] possible dox bug in floating point tutorial

Daniel Lichtblau danl at wolfram.com
Fri Jan 31 19:49:08 CET 2014


On 01/31/2014 12:27 PM, Zachary Ware wrote:
> Hi Daniel,
>
> On Mon, Jan 13, 2014 at 11:00 AM, Daniel Lichtblau <danl at wolfram.com> wrote:
>> (I'm not sure if this is a bug but it seems mysterious.)
>>
>> http://docs.python.org/2.6/tutorial/floatingpoint.html
>>
>> Mentions that 0.1, under the hood, is a fairly long decimal.
>> Specifically:
>> "On most machines, if Python were to print the true
>> decimal value of the binary approximation stored for 0.1, it would have to
>> display
>>
>>>>> 0.1
>> 0.1000000000000000055511151231257827021181583404541015625
>>
>> instead!"
>>
>> This seems to be too long for any hardware floating point representation,
>> even quad. Also the length of that decimal string is 54. While that's not
>> quite as suspicious as 53, it still makes one wonder if that should be
>> the length of the corresponding display for a binary representation.
> To understate it slightly, I'm not extremely familiar with the
> intricacies of binary floating point.  However, I can tell you that
> '0.1000000000000000055511151231257827021181583404541015625' was most
> likely obtained like so:
>
>     >>> from decimal import Decimal as d
>     >>> str(d(0.1))
>     '0.1000000000000000055511151231257827021181583404541015625'
>
> Hopefully that takes some of the mystery out of it!  If you believe
> this representation to be incorrect, do please open an issue on the
> bug tracker.
>
> Regards,
>

Dear Zachary,

Thank you for showing this. Searching on "from decimal import Decimal"
I then located the link below.

http://docs.python.org/3/library/decimal.html

Documentation there now makes me fairly confident that what I saw
is not a bug. It simply indicates that Python is using extended
precision behind the scenes in some automated manner. Now this is
slightly mysterious in that it shows up in the context of discussion
of Python (hardware) floats, but that does not make it a bug.

The fact that the length was approximately the same as the mantissa
for almost all machine doubles in current hardware is incidental.
Though I suspect not coincidental-- I think this length is needed
in order to one can represent every binary mantissa uniquely in
decimal form.

Thanks again for responding with this explanation for how that
number likely arose.

Best,
Daniel




More information about the docs mailing list