floating point woes
Hans-Peter Jansen
hpj at urpla.net
Tue Feb 15 20:02:49 EST 2011
More information about the Python-list mailing list
Tue Feb 15 20:02:49 EST 2011
- Previous message (by thread): floating point woes
- Next message (by thread): floating point woes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Wednesday 16 February 2011, 01:06:08 Benjamin Kaplan wrote: > On Tue, Feb 15, 2011 at 6:49 PM, Hans-Peter Jansen <hpj at urpla.net> wrote: > > Hi, > > > > while I usually cope with the woes of floating point issues, this > > is > > > > one, that I didn't expect: > >>>> round(2.385, 2) > > > > 2.3799999999999999 > > > > Doesn't the docs say, it's rounded up for this case? > > > > <quote> > > Values are rounded to the closest multiple of 10 to the power minus > > n; if two multiples are equally close, rounding is done away from 0 > > </quote> > > > > Well, that one is clearly rounding down. > > > > What's up, eh, down here? > > > > Pete > > The number you are rounding is not 2.385. It is not possible to > represent that number in binary, just like you cannot represent the > value 1/3 in decimal. So instead, you're using the nearest > approximation that an IEEE 754 Double-Precision Floating Point number > can get you, which happens to be about 2.3849999999999998. And that > rounds down to 2.38. Which also cannot be precisely represented in > binary, so you get 2.3799999999999999 instead. Thanks for the explanation, Benjamin. Not that I like it, but anyway. If I hadn't quitted smoking a long time ago, I would go and ask, what these engineers smoked during the course of inventing this sh*t. Even more probably, they took way too much of a special form of lysergic acid. OTOH, cdecimals, as in Stefan Krah's package are long overdue to get into the core. Pete
- Previous message (by thread): floating point woes
- Next message (by thread): floating point woes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list