Re: Overflow and Inf
> Date: Tue, 05 Oct 2010 17:48:25 +0200
> From: Arnold Neumaier <Arnold.Neumaier@xxxxxxxxxxxx>
> To: Ian McIntosh <ianm@xxxxxxxxxx>, 1788 <stds-1788@xxxxxxxxxxxxxxxxx>
> Subject: Re: Overflow and Inf
>
> I resend the mail below since in order to be able to answer
> another mail, I really need an answer to my question below,
> marked ###.
>
> Arnold Neumaier
>
>
>
> =============================
>
> Ian McIntosh wrote:
>
> > AN> The real question is whether a (hardware or software) implementation
> > AN> that produces +-DirectedInf in place of Inf whenever an operation with
> > AN> directed rounding to +-Inf overflows is still 754 compatible.
> >
> > I believe it is not 754 compatible.
> >
>
> . . .
>
> ####################################################################
> Is it possible to have a 754-compatible implementation that provides
> additional rounding modes with a new behavior?
> ####################################################################
>
> Then one could define two new rounding modes up and down that behave
> according to the last section of the Vienna Proposal, with some of
> the NaNs acting as +-DirectedInf, and others acting as bounds for Empty.
> On finite data they would behave exactly as round to +-Inf, except for
> the sign of zero, and in the deviant cases they would behave as we need
> them.
>
> . . .
>
> > The representation of DirectedInf would still be an issue.
>
> . . .
>
> Arnold Neumaier
Arnold,
You appear to be asking Ian.
But I feel I should respond to this question.
If you are asking if installing a new rounding mode
would invalidate a currently conforming 754
implementation, my personal opinion is no, it would
not.
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."
Further, since assigning meaning to particular NaNs
requires that they be distinguished in their behavior
from other NaNs, you will find that you cannot count
on any particular NaN being propagated through an
operation. A conforming implementation may return
any NaN it likes (provided it is correctly chosen
from quiet & signalling) at any time. We tried to
further specify NaN propagation behavior but could
not get all the diverse existing implementations to
agree.
In my circuits there was not even a path to propagate
NaNs through an arithmetic operation. They were
recognised at the top & a new NaN was generated at
the bottom. Many floating-point datapaths operate in
a similar fashion.
If you invoke the possibility of circuits for a new
rounding mode, the propagation behavior would have to
change as well.
Then there is the practical question of: Would we
want to specify an interval standard that cannot
run efficiently on any existing 754 implementation?
As 754 systems account for 90+% of all the computers
in the world, this seems particularly unwise to me.
I realize that some (perhaps, many) of the interval
operations we discuss will have special cases (such
as dealing with Empty or infinity) that will have
to be handled in ways other than that which falls
out naturally from a conforming 754 implementation.
It is my hope that these exceptions can be handled
along execution paths that do not significantly
alter the nominal run time behavior of an interval
function.
And, yes, I believe it will be possible to design
specialized interval hardware that eliminates the
need for such exceptional execution paths. Even
hardware that automatically propagates decorations.
But that is for the future.
We still have to convince the world to use intervals
AT ALL much less design specialized hardware to
optimize it.
Hardware guys (especially those at Intel) are a
particularly conservative bunch. They will want to
see benchmark data that supports the need for new
circuits. So the use of intervals must become common
enough to be worthy of consideration for a competitive
advantage.
But, you asked for an opinion.
I'm guessing you don't share it.
It takes all kinds to make up a standard. :-)
Dan