[Python-Dev] Round Bug in Python 1.6?

[Vladimir Marangozov]

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