[LCP]Negative zero problem

[Mike & Penny Novack]

> Anyway, I tried reversing the logic, testing for val >= 0.0, since
that's
> technically a more accurate reversal of the logic than testing for
> val > 0.0, and the results were the same.  If I test for val > 0.0
> instead, I get exactly opposite results.  In other words, in cases
that
> produced a negative zero before, no sign was present, but in cases
where
> there was no sign before, a sign was present.  Whether or not a sign
is
> present makes no difference in calculations, however.  They're both
> exactly zero.
>
 OK Chuck, it's possible that your implementation has both signed and
unsigned zero with which you end up with depending upon the order of
calculations. I think we may be able to come up with something to "fix"
that but first, I want you to reconsider the way you reversed the logic.
I had a very good reason for describing an EXPLICIT reversal of logic
because:

    What you code (in the high level language) is not necessarily what
the compiler does.

In other words, you do NOT know that the compiler "does" => by using <
with the operands switched. It might do it via TWO "branch on condition
instructions instead. I was describing the logic reversal in such a way
that I knew what was going to happen regardless of how the compiler
treated compound conditionals like >=

But back to your "what should I try now?" question about how to get rid
of the sign. No, I don't think you need to do something like looking for
the "-" in the "pronted" string (ie: edited for output). Let's try some
arithmetic first. Before your logic:

    val = (val + 1.0) - 1.0

Here's why I think this will work. If "val" currently contains EITHER an
unsigned or minus zero, val + 1.0 will be unsigned (or postive) and
probably that sum - 1.0 will result in an unsigned zero. BUT IT DOESN'T
REALLY MATTER IF NOT. In other words, even if the result turns out to be
minus zero it will then ALWAYS be that (ie: your result will be
consistently signed or unsigned, not sometimes one way and sometimes the
other).

Mike

PS -- That's a trick all us old COBOL programmers know about, needing to
do things like adding +0 to values to make sure they are signed
(unsigned numbers are equivalent to positive if individually compared
arithmetically but not if a bunch are done at once (a group compare is a
logical, not arithmetic operation) ---- many is the time some befuddled
programmer brought one of THESE "bugs" to my desk).