Re: On writing negative zero - with or without sign

tholen@xxxxxxxxxxxx wrote:
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. 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.

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. You've maintained that zeros are exact even
when dealing with simulated continuous reals (the very purpose
of the temperature example was to make *sure* the values involved
were definitely known in advance to be inexact). Your *definition*
of "exact" disregard the provenance of the values involved.

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. If you meant
any other kind of exactitude you should have said so at the outset.
Words are usually considered to have their usual meaning in
conversations unless you explicitly identify some novel meaning.

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

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. For that
purpose, zeros have no exactitude (nor do any other values).

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. 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.

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

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

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

I do believe it's off topic. I didn't bring it up. I've tried to
abandon 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? 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.
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. Yes, I shouldn't have. Trampling on someone's
religion is always a mistake. 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. I've paid. You inquisitors will
insure I continue to pay.

--
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


.

Relevant Pages

  • Re: Math, The Friend of Relativity
    ... Don't be reassured by the ranting of Uncle Bonehead, ... As if we would believe something just because Einstein said so. ... zero, either, by the same argument Uncle Ben gave for real numbers. ... I've already proven h does NOT belong to the set of reals, ...
    (sci.physics.relativity)
  • Re: On writing negative zero - with or without sign
    ... exact zero, contrary to your claim that there is no such thing. ... And I noted that there is a subset of continuous reals that can be ... representation to account for "actual zero"). ...
    (comp.lang.fortran)
  • Re: in fact zero _is_ neither positive nor negative. THIS STATEMENT IS NOT TRUE
    ... So in fact zero can be negative and can be positive and it just ... which most then build the reals from. ... and agree that magnitude is much more fundamental ... and if you want to use the bourbaki "positive" (positif ?) to include ...
    (sci.math)
  • Re: The common usage of "nonnegative real number" is ludicrous.
    ... not necessarily zero, and that is usually what is meant by ... a complicated construction. ... When I want to talk about magnitude I am talking about ... reals contain zero or not is just convention. ...
    (sci.math)
  • 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)