[Python-Dev] Round Bug in Python 1.6?

[Ka-Ping Yee]

Sorry, i'm a little behind on this.  I'll try to catch up over the
next day or two.

On Sun, 9 Apr 2000, Tim Peters wrote:
>
> Note the example from another reply of a machine with 2-bit floats.  There
> the user would see:
> 
> >>> 0.75   # happens to be exactly representable on this machine
> 0.8        # because that's the shortest string needed on this machine
>            # to get back 0.75 internally
> >>
> 
> This kind of surprise is inherent in the approach, not specific to 2-bit
> machines <wink>.

Okay, okay.  But on a 2-bit machine you ought to be no more surprised
by the above than by

    >>> 0.1 + 0.1
    0.0
    >>> 0.4 + 0.4
    1.0

In fact, i suppose one could argue that 0.8 is just as honest as 0.75,
as you could get 0.8 from anything in (0.625, 0.825)... or even *more*
honest than 0.75, since "0.75" shows more significant digits than the
precision of machine would justify.

<shrug> It could be argued either way.  I don't see this as a fatal
flaw of the 'smartrepr' method, though.  After looking at the spec
for java.lang.Float.toString() and the Clinger paper you mentioned,
it appears to me that both essentially describe 'smartrepr', which
seems encouraging.

> BTW, I don't know that it will never print more digits than you type:  did
> you prove that?  It's plausible, but many plausible claims about fp turn out
> to be false.

Indeed, fp *is* tricky, but i think in this case the proof actually is
pretty evident --

The 'smartrepr' routine i suggested prints the representation with
the fewest number of digits which converts back to the actual value.
Since the thing that you originally typed converted to that value the
first time around, certainly no *more* digits than what you typed are
necessary to produce that value again.  QED.

> >     - If you type in what the interpreter displays for a
> >       float, you can be assured of getting the same value.
> 
> This isn't of value for most interactive use -- in general you want to see
> the range of a number, not enough to get 53 bits exactly (that's beyond the
> limits of human "number sense").

What do you mean by "the range of a number"?

> It also has one clearly bad aspect:  when
> printing containers full of floats, the number of digits printed for each
> will vary wildly from float to float.  Makes for an unfriendly display.

Yes, this is something you want to be able to control -- read on.

> If the prompt's display function were settable, I'd probably plug in pprint!

Since i've managed to convince Guido that such a hook might be nice,
i seem to have worked myself into the position of being responsible
for putting together a patch to do so...

Configurability is good.  It won't solve everything, but at least
the flexibility provided by a "display" hook will let everybody have
the ability to play whatever tricks they want.  (Or, equivalently: to
anyone who complains about the interpreter display, at least we have
plausible grounds on which to tell them to go fix it themselves.)  :)

Here is what i have in mind: provide two hooks

    __builtins__.display(object)

and

    __builtins__.displaytb(traceback, exception)

that are called when the interpreter needs to display a result or
when the top level catches an exception.  Protocol is simple:
'display' gets one argument, an object, and can do whatever the
heck it wants.  'displaytb' gets a traceback and an exception,
and can do whatever the heck it wants.


-- ?!ng

"Je n'aime pas les stupides garçons, même quand ils sont intelligents."
    -- Roople Unia