Re: On writing negative zero - with or without sign

On 2007-07-20 04:51:21 -0300, tholen@xxxxxxxxxxxx said:

James Giles writes:

....

Maybe I've misunderstood the earlier discussion, but I thought that
minus zero applied only to cases where the actual numerical value
was in fact negative, but the chosen display format was insufficient
to show any significant digits, therefore the number would be
displayed as all zeros, with the question being whether to display
the minus sign or not. For example, should the value -1.2E-5, when
displayed with the format edit descriptor F4.1, be -0.0 or 0.0?

That's easy, the Fortran standard says that a negative value should
have a minus sign output. The earlier discussion was more concerned
over whether an internal value was negative or not, when its magnitude
was zero but it had a set sign bit. The rule should be more clearly
stated in the standard: if the sign bit is set the output should begin
(after any padding blanks) with a minus sign. That's independent of
the magnitude (infact, I think that should be the rule even if the
number turns out to be NaN).

Why should the sign bit be set if the magnitude is zero?

Two analogies:

1. Font hinting is something that is not true in some restricted and narrow
sense but it sure makes a lot of things a lot smoother.

2. Extended reals are a valid mathematical system that you may not be familiar
with that shares many properties with the reals and also permits various
additional operations to proceed gracefully. (There are even some rather
"wild" systems that mimic what you would think of as ordinary arithmetic
but that lead to a lot of interesting (at least to those who study them)
mathematics.)

Signed zeros may not be what you are used to or were taught in an earlier
mathematics course but they do make a lot of things proceed more gracefully
if used according to their intended rules. You can view the signed zeros as
hints of their history which can be important in many analytic applications
or as a similar formal system with only a few rules changed.

The usual rule of "if you don't like it then don't use it" applies with
the additional comment that you may have to ignore some negaive signs
on a few zeros supplied by others.

As far as I am concerned, there is only one exact zero, not two, and
not three, and there should be no sign associated with an exact zero.

And, if you're simulating genuine real numbers with your floating
point REAL data type, you'll *never* see something you're sure
is an exact zero.

Why not? Suppose I difference two real numbers that have the exact
same internal representation.

Suppose you have a record of temperatures recorded at some
observing site and you go through generating a first-difference
(an approximation to a derivative). Well, the thermometer reports
to a tenth of a degree. Suppose two consecutive times show a
value of 15 degrees. That means each value is actually somewhere
between 14.95 and 15.05 degrees and whatever true temp occurred
was rounded to just 15.0 degrees. The float difference of those two
measurements will have a magnitude of zero. But, it's pretty clear
that the temps at the two times were almost certainly more different
than the ~10^(-39) precision of floating point! That zero difference
is hardly *exact* (in fact, the correct answer is in the interval from
-0.1 through 0.1, somewhere). The sign printed with a zero arising
from such a calculation is meaningless, why do you care which is
printed?

You're assuming that I would want one or the other printed. In such
a case, I would be content to have no sign. It's up to the user to
properly interpret the results of a calculation.

In using float to simulate continuous real arithmetic, zeros
can arise a number of ways. They reduce to two categories:
1) underflow, where the sign bit still carries useful (maybe
decisive) information; 2) result of discrete approximation
(like the above difference) where the sign bit means nothing
and a good programmer knows it. There are no third cases,
that is, where it's actually *important* to supress the sign.

If the sign bit carries decisive information, then it's important
for the correct sign to be displayed. In your temperature example
above, you noted that the correct answer could be either positive
or negative, so there is no way for the processor to know which is
the correct sign, thus I would argue it's important to suppress the
sign.

Now if you are using floating point to do some kind of discrete
arithmetic rather than as a surrogate for continuous reals, the
sign bit of zero may or may not be important (usually not).
However, I can still see no reason for the implementation
to supress it.

Consider your temperature example. The sign could be misleading
if not suppressed.


.

Relevant Pages

  • Re: On writing negative zero - with or without sign
    ... but the chosen display format was insufficient ... the minus sign or not. ... was zero but it had a set sign bit. ... and there should be no sign associated with an exact zero. ...
    (comp.lang.fortran)
  • Re: On writing negative zero - with or without sign
    ... but the chosen display format was insufficient ... the minus sign or not. ... was zero but it had a set sign bit. ...
    (comp.lang.fortran)
  • REPRESENT revisited
    ... Forth-94 has few floating point display functions [none in the ... If u is greater than zero the character string shall consist ... If u is zero the string shall consist of one digit representing ...
    (comp.lang.forth)
  • Re: On writing negative zero - with or without sign
    ... but the chosen display format was insufficient ... the minus sign or not. ... was zero but it had a set sign bit. ... arithmetic rather than as a surrogate for continuous reals, ...
    (comp.lang.fortran)
  • Re: Skipping parameters in a printf()
    ... I have a set of int variables: some variables can be negative and ... I want to display the ... zero and shows no minus sign. ...
    (comp.lang.c)