[TAG] Talkback:143/sephton.html

[Jan Medlock]

On Tuesday 02 October 2007 06:11:33 pm Paul Sephton wrote:
> On Tue, 2007-10-02 at 16:06 -0400, Jan Medlock wrote:
> > Are you sure this isn't because FE_TONEAREST is the default, which rounds
> > 'N + 0.5' to the nearest *EVEN* integer?
>
> Of course what you refer to is the reason behind the mistake.  Rounding
> the result of calculations to nearest binary representable value, or to
> nearest even binary representable value on boundaries (where the closest
> even and closest odd is equidistant) is indeed the default rounding mode
> FOR BINARY FLOATING POINT OPERATIONS, which is as it should be.
>
> ...

Wow, thanks for the detailed reply and my apologies for not having understood 
the depth of the problem.  I see that IEEE rounding direction is *not* the 
problem.

I'm afraid I don't understand your backward-stepping algorithm.

It seems to me that the problem is that rounding is inherently sensitive to 
the errors in storage of a number as a floating-point representation.  I.e. 
round(x - e) != round(x + e), where e is the error between x and its 
float-point representation.  I don't see that this is resolvable.

E.g. once you've stored
5000.525
and
5000.524999999999999999999999999999991
as floating point, there's no way to determine whether the value of the 
original number to 2 digits should be
5000.53
or
5000.52.