[Python-Dev] Expert floats

[Ka-Ping Yee]

On Tue, 30 Mar 2004, Tim Peters wrote:
> [Aahz]
> >> >>> 1.1
> >> 1.1000000000000001
> >>
> >> Just a fact of life.  :-/
>
> [Ping]
> > I regret that this "feature" was ever introduced or "fixed" or what
> > have you.  Things were much better when repr(1.1) was "1.1" a few
> > versions ago.
>
> Naturally, I disagree.  The immediate motivation at the time was that
> marshal uses repr(float) to store floats in code objects, so people who use
> floats seriously found that results differed between running a module
> directly and importing the same module via a .pyc/.pyo file.  That's flatly
> intolerable for serious work.

That doesn't make sense to me.  If the .py file says "1.1" and the
.pyc file says "1.1", you're going to get the same results.

In fact, you've just given a stronger reason for keeping "1.1".
Currently, compiling a .py file containing "1.1" produces a .pyc file
containing "1.1000000000000001".  .pyc files are supposed to be
platform-independent.  If these files are then run on a platform with
different floating-point precision, the .py and the .pyc will produce
different results.

> But since we made the change anyway, it had a
> wonderful consequence:  fp newbies gripe about an example very much like the
> above right away, and we have a tutorial appendix now that gives them
> crucial education about the issues involved early in their Python career.

This is terrible, not wonderful.  The purpose of floating-point is to
provide an abstraction that does the expected thing in most cases.
To throw the IEEE book at beginners only distracts them from the main
challenge of learning a new programming language.

> A display hook was added to sys so that people who give a rip (not naming
> Ping specifically <wink>) could write and share code to format interactive
> responses following whatever rules they can tolerate.  It's still a surprise
> to me that virtually nobody seems to have cared enough to bother.

That's because custom display isn't the issue here.  It's the *default*
behaviour that's causing all the trouble.

Out of the box, Python should show that numbers evaluate to themselves.


-- ?!ng