Re: Overflow and Inf
Dan Zuras Intervals wrote:
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.
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.
And Michel Hack wrote:
> Dan Zuras wrote in reply to Arnold Neumaier's ### 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.
>
> I agree. Indeed, IBM supports 8 rounding modes (three
> more than the five 754-2008 defines) for DFP (on P and Z),
> and two more for BFP (on Z).
Excellent. This is all that is needed.
I'll need some more thought and then will come up with a
related proposal.
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.
Yes, and it would be specified to be maximally useful for
interval computations.
Then there is the practical question of: Would we
want to specify an interval standard that cannot
run efficiently on any existing 754 implementation?
Of course, we must propose something that runs as efficiently
as possible on existing 754 hardware. However, nothing can
prevent us from proposing an even more efficient way that runs
with hardware that has two more rounding modes.
If at least one vendor builds such hardware, an example is set,
and users of directed rounding who use it for other purposes
than verified computations can check whether the new rounding
modes are an adequate replacement of the rounding modes
towards +-Inf that are required now. Most likely it is.
Then the next revision of the 754 standard may well decide
to switch from supporting the two rounding modes towards +-Inf
to supporting the two new rounding modes.
We still have to convince the world to use intervals
AT ALL much less design specialized hardware to
optimize it.
People who need intervals already use them today.
And those who don't need them have no incentive to use them.
But as science and engineering progresses, the world of
computations becomes more nonlinear and more global,
and the need for global optimization (and hence of intervals
as a byproduct) will increase.
When, many years ago, I started working on intervals because
of their attractive theoretical properties for validated computations,
almost _nobody_ in the main stream used them. (James Wilkinson
was one of the rare exceptions.)
This changed, and it will continue to change.
It just takes patience, persistence, and staying power.
Arnold Neumaier