Re: On writing negative zero - with or without sign

James Giles writes:

....

And, you keep failing to specify what magic you think the I/O
library is going to use to infer more than one bit of information
from the one bit that's present.

Wasn't "interval arithmetic" your magic, Giles?

Interval arithmetic carries *a* *lot* more information.

There's your "magic".

Yes, if you provide the I/O library with a new data type
(intervals) the I/O thenhas something else to work with.
It's not magic, it's well defined, hardnosed, pragmatic
I/O.

So, I answer your question about the magic by referring to something
you brought up, and now suddenly it's not magic anymore. Why am I
not surprised?

You keep recommending that the Fortran I/O library do
something different with just plain float.

Where did I make such a recommendation, Giles?

What? You keep failing to specify.

Why should I? That was never the issue to which I responded. Rather,
I responded to the issue of an "exact" zero. I specified my concept
of an exact zero.

The sign has two states.

When limited to one bit. Just like the character set has 256 states
when limited to 8 bits. But now we have double byte character sets.
What's to prevent some new generation of computer and compiler to come
along with interval arithmetic and multi-bit sign?

Design it and we'll talk. But if it's filled with unnecessary
complexity just to deal with you mystical belief that the
difference of inexact values is exact, forget it.

The key word here is "if". I have no need to do such a thing,
because I don't believe that the difference of inexact values
is exact. I do believe that the difference of two identical
internal representations is a reasonable concept of an "exact"
zero, however, in the sense that there is no way to decide
whether a plus or minus sign should be attached to that zero.

No one will buy a backward step as progress. Mysticism is a
dark age phenomenon.

Irrelevant, given that I haven't proposed any backward step.

Besides, I elided it above, but weren't you the one that
just said:

But we're talking about the Fortran standard here, not the IEEE
standard.

Surely some hypothetical multi-bit sign form is even more
off topic than IEEE. Your multi-sign replacement hasn't
even reached the design stage yet. IEEE is nearly universal.
It's certainly ubiquitous.

Interval arithmetic isn't universal or ubiquitous, yet you brought it
up. Obviously you don't have a problem with bringing up things that
aren't universal or ubiquitous, so you shouldn't have a problem when
somebody else does likewise.

And using said different notation just complicates
the language for no purpose, The present convention of using
a minus sign if the sign bit is set, and a plus sign (or nothing at
all) if the sign bit is clear answers admirably. It tells the whole
story.

How can you say that when a single bit offers only two states, but
there are more than two possible outcomes?

I say it because there aren't more than two *IMPORTANT*
outcomes.

Just because a third one isn't important to you doesn't mean that it
can't be important to someone else.

Even those two are sometimes unimportant. I say
it because I am self consistent

I disagree; refer to your interval arithmetic as an example.
It's not magic, except when you believe there's no way for
somebody else to provide the necessary information.

- I oppose unnecessary complexity
in computing environments.

Which depends entirely on what you consider necessary and
unnecessary.

At least all of the story that the I/O library knows without
arbitrarily making up information out of the air!

There's more to the matter than just the I/O library.

As you've reminded me in three messages now, none of
those are on topic in this thread. What is Fortran I/O to
do with floating point output *NOW*?

That's been addressed by members of the standards committee.
The answer apparently isn't clear because of contradictions
involving the sign bit, which wants a minus sign to be attached,
and the SP edit descriptor, which wants a plus sign to be
attached.

The issue to which I responded was your reference to an exact
zero.

And it has a 100% chance of being wrong if it claims that the
answer is *exact* zero.

But you claimed that there is no such thing. [...]

So that makes it even more wrong for the I/O library to claim it!

So you consider yourself the final arbiter in what an I/O library
should do.

[...] Although I disagree,
that doesn't mean I believe the thermometer example represents a
case of an exact zero.

You said it was before.

No I didn't.

You *defined* exact zero as the difference
of two values with identical internal represenations.

But I used an example that was quite different from your
thermometer example.

You made no
allowances for the provenance of the numbers involved.

I've talked about the uncertainties of the numbers. I've talked
about propagation of error.

Your own
words require that you believe that the thermometer example
represents a case of exact zero.

Not at all. Propagate the quantization error of 0.1 degrees.

That's not an improvement.

Irrelevant, given that I never said it would be an improvement.

Good, now we're getting somewhere.

Not yet, because you've misinterpreted your thermometer example
as being equivalent to my concept of an exact zero.

Can we now stop talking
about changing the admirable rule Fortran already has for writing
zeros?

We haven't been talking about that. We've been talking about an
exact zero. I'll leave it to the standards committee members to
clarify the standard.

The existing implementation is writing all zero digits for the
value already. To anyone with an understanding of float, that
means the value (the result of a subtract), by itself, has no
significance at all, much less does the sign mean anything.

So a single sign bit isn't sufficient.

For a quantity that means nothing, it's overspecified.

What about for a quantity that means something?

That means it's *more* than sufficient. There's certainly no need
for even more.

When the quantity means nothing. What about when it means something?

Unfortunately, the compiler doesn't spit out the intention of
notational conventions along with the numerical results. Do
you have any Fortran compiler documentation that explains how
signs are handled?

The standard is pretty precise. Taken with the specification
of whatever float representatin you use, it's conclusive.

So you're saying that everyone who buys a compiler also needs to
buy a copy of the standard implemented by that compiler in order
to learn how to properly use the compiler?

Then by gosh the programmer can write a string of plusses and
minuses or draw a picture of a clown if (s)he wants.

Imagine that, extra bits to work with. [...]

Extra bits on output you mean.

No. I mean extra bits. In the past, compiler vendors would
have different choices for the number of bits to assign to
the exponent and to the rest of the number. They chould just
as easily reserve one of those bits for another purpose.

No extra bits on input (to the I/O library) though.

Why not?

This extra noise warns the user of a bogus
problem in a bogus way. I can't prevent a bad programmer from
doing it. I can't prevent all sorts of counterproductive behavior.

You're presupposing that having a bit reserved to do something
else represents noise. That's not necessarily the case.

[...] Do the propagation of
error computation, show what the uncertainty in the result is, [...]

Not unless the I/O library is given that information. NO? You
didn't pass that data? You didn't say *specifically* (as I keep
asking) what you expect the I/O library to do? No, you didn't.

What are you harping about now? I've already said what I expect
given the current situation. And I've already talked about other
possibilities for the future.

And interestingly, if you *do* a formal error propagation
analysis, the existing rules for handling signs (even of zeros)
are sufficient to clearly report the results.

Really? Then which sign is the correct sign for your thermometer
example? Sorry, the answer is neither. There's no way for the
processor to know which sign to pick.

I disagree. A single bit has only two states, but there are more
than two possible outcomes. Doing a propagation of error
computation carries far more information.

Then *DO* *IT*.

That's exactly what I do in my own work. But that's not the issue
here. The issue here is whether there is such a thing as an exact
zero. If you prefer, consider Shepard's absolute zero. There has
to be a dividing line between where you use minus and where you use
plus. You may feel as though a result can never be on that dividing
line, but the concept of the dividing line must be present to
separate the plusses from the minuses. Is that a better concept of
an exact zero?

You mentioned none of this before!

Kevin Rhoads should disagree, considering the amount of time we
spent discussing it.

Your
previous claims were entirely based on just the normal float
results.

My previous claim for the thermometer example is based on the
fact that the processor can't know which sign to use.

This is like the bad mystery writer that tells a long
story with lots of clues concerning central characters and then
reveals the crime was committed by a stranger that was just caught
in the next state. What a gyp. Ringing in a whole different
issue never mentioned before. and so late in the game.

You're erroneously presupposing that it's never been mentioned
before.

What a responsible programmer will do is label the output.
Something like: "first differences of temperature readings".

You think that's more responsible than a full propagation of
error computation? Of course, you have to do the computation
properly. Too often quantization noise is ignored.

In this simple case, I think the savvy reader knows what the
error was without such expensive analysis. The source of
error is the reliability of the thermometer and the fact that
it discretized the data. The only operation is a subtract.

Actually, a subtract without a time normalization isn't terribly
useful. If you sample the temperature every nanosecond, you
could get lots of identical results, given the quantization.
Sample every hour and you just might get around that problem.
But then you need a divide in there as well to compute the
rate of change.

I've actually taught students about the problems of quantization
noise. The specific exercise involved the timing of the period
of a pendulum using a stopwatch. The way around the problem is
to time multiple periods and divide by that multiple. Also
reduces error contributed by human reaction time. But it increases
the error caused by atmospheric friction.

No, a *really* complex, slow method is like killing a fly
with an atomic bomb.

And that is relevant how?

.

Relevant Pages

  • 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: 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)
  • Re: Re: Evidence for Gods existence?
    ... This evidence is 'good enough' for me. ... Someone may have taken my school thermometer, ... inserted it into some ice and made a mark and "called it" zero degrees ... water freezes a see that my water also freezes at zero degrees C. ...
    (uk.religion.christian)