Re: DirectedInf
> Date: Wed, 06 Oct 2010 11:00:30 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> MIME-Version: 1.0
> To: Dan Zuras Intervals <intervals08@xxxxxxxxxxxxxx>
> Subject: Re: DirectedInf
> X-Univie-Virus-Scan: scanned by ClamAV on joan.univie.ac.at
>
> Dan Zuras Intervals wrote:
> >>
> >> . . .
> >>
> > Arnold,
> >
> >
> > You seem to be picking & choosing from among my words
> > to support your approach.
> >
> > I do NOT support it. And I believe it WOULD invalidate
> > a system from conforming to 754.
> >
> > I repeat the next paragraph from that note:
> >
> >>> However, if you are asking that there exist values
> >>> (such as +/-DirectedInf) other than those spelled out
> >>> in the 754 document, I'd have to say, yes, that would
> >>> invalidate an implementation.
> >>>
> >>> The clause you would violate is section 3.3 & I quote:
> >>>
> >>> "These are the only floating-point data represented."
>
> I read that. But I intend to define +/-DirectedInf as two particular
> NaNs with payload, whose propagation is as 754 requires under the
> existing modes (with all the implied uncertainty) but which propagates
> as required in my new specification in the new rounding modes.
Perhaps you are reading it but I guess you are not
believing it. Or me.
It has nothing to do with the rounding modes. It has
to do with using NaNs to create new values not intended
by the standard.
The example Michel cited was of a system that had new
rounding modes for the EXISTING set of numbers. There
is no clause against doing that.
But the clause above prevents you from changing or
adding to the set of floating-point values that are
represented in a conforming system.
It says nothing about the rounding mode being used at
the time.
>
> The latter cannot be subject to the rules of 754 if I understood you
> correctly. Or does 754 specify anything about how NaNs must propagate
> in _arbitrary_ rounding modes, including any implementation-dependent
> mode? This would make things more difficult but probably still
> manageable if the requirements are not too strict.
Again, the rounding mode has nothing to do with it.
>
> . . .
>
> > Something that I went on to opine would be unwise of
> > us to do.
> >
> > I am NOT opening that door for you. You force yourself
> > through it by yourself.
>
> 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.
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.
>
>
> Arnold Neumaier
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.
Dan