Re: On writing negative zero - with or without sign

Ron Shepard wrote:
In article <1184572698.921310.254810@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
Terence <tbwright@xxxxxxxxx> wrote:

If a real value very close to zero has to be expressed in a limited
number of fractional digits, but these digits are all zeroes after
the decimal point, then the appropriate sign should be prefixed to
the values to indicate which side of absolute zero the values lies.

This is the basis of the problems. There is a way to designate -0.0
in this way (by using the sign bit), but there is no way to
designate a +0.0 in this way that is distinct from the actual 0.0.

Floating point is an approximation to reals. Different floating
point implementations may have different interpretations of the
approximations they provide. In IEEE floating point, there
are two different approximations to zero. The concept of
*exactly* zero is *equally* represented by either of those
approximations (hence, the two compare equal to each other).

However, the two approximations differ in that they represent
different sets of values which intersect at one point: exactly zero.
So, the sign may carry important informaion. Conversions to
other bases should preserve the sign.

If, in hardware, there were a way to designate and differentiate
-0.0, 0.0, and +0.0, then there would be no problems, everyone would
know what the three values mean.

Actually, that description exemplifies the problem. Most of
the IEEE operations specify very clearly what the sign of the
result should be. Even when the magnitude (to the limit of the
representation) is zero, the sign bit usually preserves some
information. The only exception is the result of an add or a
subtract. Here the sign of the result is indeterminate (and the
IEEE standard allows the implementation to pick either one).
So, a signless zero would most naturally fit this result. But
that means that, far from representing *exactly* zero, this
new value represents the union of the two approximations
represented by the signed zeros. It's *less* exact. (Indeed
it's *much* less exact since you didn't arrive at zero by
underflow, but by cancellation of the leading bits. Such
concepts were intended to be addressed by interval arithmetic.)

So the real problem is that people tend to think that programs
can represent, manipulate, or produce metaphysically perfect
"exact" zeros in the first place. Such things are fabulous

J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare