On Wednesday 16 February 2011, 01:06:08 Benjamin Kaplan wrote: > On Tue, Feb 15, 2011 at 6:49 PM, Hans-Peter Jansen <h...@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 -- http://mail.python.org/mailman/listinfo/python-list