Dan Zuras Intervals wrote:
> Arnold Neumaier wrote:
>
> I didnt' say that _you_ opened the door, but that the fact you
> mentioned
(which was confirmed by Michel Hack and John Pryce), opens a door that,
fortunately, wasn't locked by IEEE 754 ...
The one Michel cited wasn't locked by the IEEE.
Your's is.
... in letter, if not in spirit. For what is the point of NaNs
with payload if you cant them make behave as you please?
Ah, there we agree. But alas we were not able to
agree on a common behavior for NaNs in 754-2008.
We tried. It was inadequately specified in 1985 &
30 years of dusty decks prevented us from specifying
it in this century. Indeed we had to loosen it just
a bit. I've forgotten why. Having lost out on the
chance to make NaNs useful for something it was not
important.
We were able to agree on many 'should's in the text
concerning NaNs. But not one 'shall' ever passed a
vote.
Thus you cannot count on any consistent NaN
propagation behavior to support your scheme even if
it WEREN'T specifically disallowed.
So I must agree that it is unfortunate that NaNs
with a payload CANNOT be made to behave the way
you want.
They are virtually useless.
Indeed, since there are only two NaNs, and not as many NaNs
as there are payloads.
This makes things more difficult for us, but not impossible.
The door is smaller than anticipated but still open.
Would that it were otherwise...
So please let me know the precise text (or refer to the par.) where
the new 754 restricts the permitted behavior of NaN for rounding
modes that were not specified there.
It is the line above. You can find it in the 2008
document on page 8, the first paragraph after the
bullet list of represented values.
Please note that it does NOT say "These are the only
floating-point data represented when your activities
are confined to the supported rounding modes."
It says "These are the only floating-point data
represented."
The relevant passage in the 1985 document can be found
on page 6 in section 3.1 Sets of Values, in the first
paragraph after the list of defining parameters, & I
quote:
"Within each format only the following entities shall
be provided:"
And it goes on to list the same set of values.
This statement is also not further qualified.
It is not some whim we dreamed up in the past decode.
We were continuing to support the same standard that
has been supported for some 30 years now.
Indeed, we could not do otherwise.
Thanks for the clarification and the reference to the precise phrases.
After carefully checking the statements in the standard,
I am sure that one can make things 754-conforming by defining the
new concept of an interval-point format, which agrees with the
floating-point format on finite reals but differs on the treatment
of inf and NaN. Then none of the constraints on floating-point data apply
for interval-point data.
But the same hardware can be used with a switch of rounding modes,
and the exceptions can be handled as required for fast interval support.