[Pythonmac-SIG] Re: Number format in IDE

Louis M. Pecora pecora@anvil.nrl.navy.mil
Mon, 27 Aug 2001 13:53:58 -0400


Jon Bradley wrote:

>Even when using float, the actual representation should be followed by a
>bunch of zeros - no matter what number represetation is being used.  so, 5.1
>+ 2 = 7.1000000000000000000000.  It should not equal anything else, that
>would be a direct result of incorrect calculation of the number on the
>languages part.
>
>Maybe Jack can take a look at this and get it fixed - or I can make an
>effort.  :)  I don't mind the multiple places, since I end up using a custom
>function to round off to a certain digit anyhow.
>
>But, showing the following:
>
>>>>> 5.1+2
>> 7.0999999999999996
>
>or...
>
>>>>> print `5.1+2`
>> 7.0999999999999996
>
>That's just plain inaccurate.  For scientific purposes this is really bad -
>and should be addressed.  Out of curiousity, are these numbers being
>calculated through the use of NumPy or the default python implementation (I
>think Numerics are now included in part with the distribution, but I may be
>wrong).
>
>Anyone?  Maybe it's possible that, if the default is float, and you type
>something like x=5.1, the language should automatically convert it to
>5.1000000000000.  When adding 2 to that, it should then be x + 2 (user
>types), language sees it as 5.1000000000000 + 2.0000000000000 = blah blah.
>Then write a function that strips it to a certain amount of digits, hoping
>that all you're losing in the conversion is a bunch of zeros.
>
>Don't know.  I'm a farily new user to Python in general, but this does seem
>very odd to me.
>
>Jon Bradley

I'm not so sure that there's a mathematics problem in the sense you say.  Yes, the result is inaccruate, but remember base 10 and binary fractions do not translate back and forth easily since a simple finite decimal (maybe like 0.1) might have an infinite, repeating representation in binary "decimal" form.  The computer can only store a finite string of 1's and 0's.  How can it guess the remaining (infintely many) unstored values?  The real question is what algorithm do you use to deal with that problem.  I, personally, don't know, but I do see the problem.  I suspect it's a well-known floating-point problem.

I think your solution is similar to what is done on some calculators.  More decimals are calculated than will be displayed, then some algorithm checks out the extra ones and decides how to round off.




Cheers,

Lou Pecora