Rounding Bug in Python 2.0! - ugh

[brucemdawson at my-deja.com]

In article <mailman.973028615.17171.python-list at python.org>,
  Thomas Wouters <thomas at xs4all.net> wrote:
> On Tue, Oct 31, 2000 at 04:10:20PM -0500, Gordon Williams wrote:
>
> > When I switched from python 1.5.2 to 2.0 final I had a surprise in
some code
> > that was working previously.
>
> > It comes down to:
> > >>> x=3.8999999999999999
> > >>> round(x,3)
> > 3.8999999999999999
> > >>>
>
> > >>> x=3.123456
> > >>> round(x,3)
> > 3.1230000000000002
>
> > Someone is going to start talking about machine round off errors,
but this
> > is a BIG UGH!!

...

> This is exactly how it behaved in 1.5.2, but you probably didn't
notice,
> because 'str()' does rounding to 'sane' numbers. The difference
between 2.0
> and 1.5.2 is that 'repr()' used to do the same rounding as 'str()',
and no
> longer does. 'repr()' is supposed to give as detailed information as
> possible, so it should show as many digits as is feasible.

One could argue that if repr() is supposed to show as many
digits as possible then it should print the exact number - instead
of just a more accurate approximation. Of course, many versions
of sprintf (well, VisualC++ at least) won't print more than
about seventeen useful digits, so we'd have to use dtoa for
that, and it's not clear that printing the exact value would
actually make people any happier :-)

And yes, while not all base 10 numbers can be perfectly
represented in base 2, all base 2 numbers can be perfectly
represented in base 10 - so the exact representation would
always be of finite length.

However it is rarely desireable to print hundreds of digits.
The most important thing is that repr() should print
enough digits to uniquely identify the number. Then, for
those rare times that we need the exact value we can
request them.

Bruce Dawson


Sent via Deja.com http://www.deja.com/
Before you buy.