Re: On writing negative zero - with or without sign

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

You keep recommending that the Fortran I/O library do
something different with just plain float. What? You keep
failing to specify.

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. No one
will buy a backward step as progress. Mysticism is a
dark age phenomenon.

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.

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. Even those two are sometimes unimportant. I say
it because I am self consistent - I oppose unnecessary complexity
in computing environments.

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

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!

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

You said it was before. You *defined* exact zero as the difference
of two values with identical internal represenations. You made no
allowances for the provenance of the numbers involved. Your own
words require that you believe that the thermometer example
represents a case of exact zero.

That's not an improvement.

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

Good, now we're getting somewhere. Can we now stop talking
about changing the admirable rule Fortran already has for writing
zeros?

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. That means
it's *more* than sufficient. There's certainly no need for even
more.

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.

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 extra bits on input (to the
I/O library) though. 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.

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

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.

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*. You mentioned none of this before! Your
previous claims were entirely based on just the normal float
results. 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.

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.
No, a *really* complex, slow method is like killing a fly
with an atomic bomb.

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


.