Mailing List Archive

Tim Peters wrote:
>
> Suppose you're computing f(x) to 2 significant decimal digits, using 4-digit
> arithmetic, and for some specific x0 f(x0) turns out to be 41.49 +- 3.
> That's not enough to know whether it *should* round to 41 or 42. So you
> need to try again with more precision. But how much? You might try 5
> digits next, and might get 41.501 +- 3, and you're still stuck. Try 6 next?
> Might be a waste of effort. Try 20 next? Might *still* not be enough -- or
> could just as well be that 7 would have been enough and you did 10x the work
> you needed to do.

Right. From what I understand, the dilemma is this:

In order to round correctly, how much extra precision do we need, so that
the range of uncertainity (+-3 in your example) does not contain the middle
of two consecutive representable numbers (say 41.49 and 41.501).

"Solving" the dilemma is predicting this extra precision so that the
ranges of uncertainity does not contain the middle of two consecutive
floats. Which in turn equals to calculating the min distance between
the image of a number and the middle of two consecutive machine numbers.

And that's what these guys have calculated for common functions in IEEE-754
double precision, with brute force, using an apparently original algorithm
they have proposed.

>
> that's-what-you-get-when-you-refuse-to-define-results-ly y'rs - tim
>

I haven't asked for anything. It was just passive echoing with a good
level of uncertainity :-).

--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

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

Ka-Ping Yee writes:
>Here is what i have in mind: provide two hooks
> __builtins__.display(object)
>and
> __builtins__.displaytb(traceback, exception)

Shouldn't these be in sys, along with sys.ps1 and sys.ps2? We don't
want to add new display() and displaytb() built-ins, do we?

--amk

On Wed, 12 Apr 2000, Andrew M. Kuchling wrote:
> Ka-Ping Yee writes:
> >Here is what i have in mind: provide two hooks
> > __builtins__.display(object)
> >and
> > __builtins__.displaytb(traceback, exception)
>
> Shouldn't these be in sys, along with sys.ps1 and sys.ps2? We don't
> want to add new display() and displaytb() built-ins, do we?

Yes, you're right, they belong in sys. For a while i was under the
delusion that you could customize more than one sub-interpreter by
giving each one a different modified __builtins__, but that's an
rexec thing and completely the wrong approach. Looks like the right
approach to customizing sub-interpreters is to generalize the
interface of code.InteractiveInterpreter and add more options to
code.InteractiveConsole.

sys.display and sys.displaytb would then be specifically for
tweaking the main interactive interpreter only (just like sys.ps1
and sys.ps2). Still quite worth it, i believe, so i'll proceed.



-- ?!ng

"You should either succeed gloriously or fail miserably. Just getting
by is the worst thing you can do."
-- Larry Smith