Re: On writing negative zero - with or without sign

James Giles writes:

....

It's a small of shaped subset of the rationals.. If and only if
*ALL* your inputs, *ALL* your intermediate results, and *ALL* your
results are members of that set can you say that the arithmetic is
exact.

So, the difference between two exactly representable real numbers that
have exactly the same internal representation could be taken as an
exact zero, contrary to your claim that there is no such thing.

I said there isn't such a thing when using float to simulate continuous
reals.

And I noted that there is a subset of continuous reals that can be
represented exactly using a finite number of bits. Zero should be
a member of that subset.

In the above, the calculation is obviously defined on some
subset of the rationals. I was the first in this thread to state explicitly
that using float for something *other* than simulating continuous reals
could give exact results.

Then it could give an exact zero, no?

You're grasping at straws if you think that changing the basis of the
discussion to exclude continuous reals has any relevance to your
previous mistakes.

What alleged previous mistakes?

You've maintained that zeros are exact even
when dealing with simulated continuous reals

Where did I allegedly say that? I've not claimed that all such
zeros are exact. A subset of such zeros could be exact, according
to the definition I provided.

(the very purpose
of the temperature example was to make *sure* the values involved
were definitely known in advance to be inexact).

But my definition of an exact zero was made before you offered
your temperature example: the difference of two identical
internal representations. That way we get the same answer from

L = X == Y

and

L = (Y - X) == 0.0

Your *definition*
of "exact" disregard the provenance of the values involved.

How so?

It's comical that you focus on the *KNOWN* most error prone
operation in all of floating point as youtr shining example
of exactitude: subtract.

Don't try to put words into my mouth, Giles. The issue has not been
"exactitude" in general, but rather a very specific issue, namely
your claim that there is no such thing as an exact zero.

The issue has *always* been exactitude in general.

Balderdash. The original issue was whether the default behavior in
gfortran should be to put a minus sign on a zero when the sign bit
is set. The original item to which I responded was your statement
"So the real problem is that people tend to think that programs
can represent, manipulate, or produce matephysically perfect 'exact'
zeros in the first place." Note the specific reference to an
exact zero, not exactitude in general.

If you meant
any other kind of exactitude you should have said so at the outset.

It should have been obvious from my response to your statement that
I was dealing with the concept of an exact zero.

Words are usually considered to have their usual meaning in
conversations unless you explicitly identify some novel meaning.

Irrelevant, given that I never claimed otherwise. Now, is there a
usualy meaning of "exact zero"? If so, then please tell me what it
is. If not, then we need to adopt a meaning. I gave you my concept
of an exact zero. What's yours? Let's at least agree on a definition
before continuing.

But, in any case, the temperature example is a case where you've
claimed exactitude when it's not present.

On the contrary, I've specifically stated that one doesn't know
the correct sign to attach to the zero in that case. How could
you possibly misinterpret that as a claim of exactitude?

And it's a specific case, not general at all.

Also irrelevant, because I've not claimed otherwise.

What you offered is in conflict with the definitions of floating
point

How so? Put up or shut up, as the saying goes.

I have several times. Floating point is intended as a computational
simulation of continuous reals. That's it's stated purpose.

And the implementation of floating point allows for a subset of
continuous reals to be represented exactly.

For that purpose, zeros have no exactitude (nor do any other values).

I disagree. There is a subset of continuous reals that can be
represented exactly using a finite number of bits.

But IEEE zeros always do. Live with it.

I take it that you're opposed to progress, Giles? I can just
imagine someone like you, after devising the 128 character ASCII
character set, being asked by some oriental person "What about
our lanugage, which has thousands of symbols?", responding with
"Live with it".

No, I *like* progress. I like it alot. That's why I embrace signed
zeros.

So why not encourage the next step rather than saying "live with it"?

It's also why I'd oppose the unnecessay complexity of all
kinds of arcane (and mostly mystical) ways of reporting the
result of float operations in I/O. If you care so much you can
write your own filter to use internal I/O and to get the data
and then delete the signs you don't like. I doubt your colleagues,
customers, or employers will agree with the unnecessary work.

But I haven't proposed to do any unnecessary work, Giles.

....

I'm dealing with an issue that you brought up. [...]

No, [a third party] brought it up. (see below)

My response was to you. Your response was to Ron Shepard,
who noted that there is no way to represent three zeros,
namely -0.0, 0.0, and +0.0 using the sign bit, which can
have only two values. In your response, you first said that
"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)." But then you later said "So the real problem
is that people tend to think that programs can represent,
manipulate, or produce matephysically perfect 'exact' zeros
in the first place." So first you talk about exactly zero,
and then you call it a problem to think about an exact zero.
Isn't that inconsistent?

[...] If you believe that
it's off-topic, [...]

I do believe it's off topic. I didn't bring it up.

Who allegedly brought up the matter of exact zero before you?
Ron Shepard referred to an absolute zero, but the whole
concept of a sign on the zero requires the concept of an
absolute zero, namely the dividing line between where you
use a minus sign and where you use a plus sign or blank.

I've tried to abandon it.

By continuing to post responses about it?

Any discussion in response to my (point two) in
the summary should not mention it at all. Why do you think
I separated the issues in the first place?

The issue I responded to is the one you made five days ago,
namely the exact zero.

I wanted to abandon
the irrelevant mystical discussion about exactitude. I've
obviously trampled on something you believe with religious
fervor -- as if God himself invented numbers and it was
blasphemy to put a sign on zero or doubt its exactitude.

I suggest you go back and reread what I've written, because
you've either misread something or have confused me with
somebody else, because I have no such religious fervor.

Well, I though it was a bogus argument when it was introduced
(not you, another person actually wanted yet another backward
step in computing by adding a third zero to the internal
representation to account for "actual zero"). I still think it's
a bogus argument. I responded to what is obviously a very
bad idea.

So, you believe that computational mathematics needs nothing more
than just two kinds of zero?

Yes, I shouldn't have. Trampling on someone's
religion is always a mistake.

You're erroneously presupposing that some religion is involved
here. If you still believe otherwise, then perhaps you should
think about your own religion being involved as well.

There's not even a remote
possibility that IEEE or anyone else will act on such a poorly
founded suggestion as to add yet another way to represent zero.
So I had no need to mention it.

But you did anyway.

I've paid. You inquisitors will
insure I continue to pay.

Interesting the way you view the discussion. We're the "inquisitors",
and you're not?

.

Relevant Pages

  • Re: Simple subtraction formula returning strange results = Excel g
    ... subtraction differ only in some number of the least significant bits ... The 64-bit floating-point representation is shown in the stylized hex form &hEEEMMMMM,M...M, where "E" is the biased exponent and "M" is the mantissa. ... always results in a zero in A3. ... A1 displays as 1.79769313486232E+308, but the first 30 digits of its exact representation are 179769313486231,57081452742373. ...
    (microsoft.public.excel.worksheet.functions)
  • Re: On writing negative zero - with or without sign
    ... I responded to the issue of an "exact" zero. ... that doesn't mean I believe the thermometer example represents a ... Propagate the quantization error of 0.1 degrees. ...
    (comp.lang.fortran)
  • Re: On writing negative zero - with or without sign
    ... exact zero, contrary to your claim that there is no such thing. ... that using float for something *other* than simulating continuous reals ... "exactitude" in general, but rather a very specific issue, namely ...
    (comp.lang.fortran)
  • Re: On writing negative zero - with or without sign
    ... of representing an "exact" zero... ... My definition of an "exact" zero is whatever internal representation ... *only* value associated with that approximation. ... A subset of floating point numbers can have an exact representation. ...
    (comp.lang.fortran)
  • Re: On writing negative zero - with or without sign
    ... I sure hope that a program can represent an exact zero. ... programs represent, manipulate, and produce approximations. ... (which is not what floating point does) ...
    (comp.lang.fortran)