medlock at turboshower.net
Fri Oct 5 01:04:29 MSD 2007
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
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
as floating point, there's no way to determine whether the value of the
original number to 2 digits should be
More information about the TAG