Re: Overflow and Inf
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.
The other question I think is important is how that +-DirectedInf would be
represented. What bit pattern would be used? In BFP (Binary Floating
Point), every bit pattern already has a meaning. That's the reason for my
previous email listing possible implementation approaches.
AN> If it is, everything is fine, and we can recommend implementors to
AN> create and prefer this version.
AN> Initially, this may be done in less efficient ways; ultimately it will
AN> be done by all implementations, and as efficiently as the current
AN> implementations, since hardly anything but applications for rigorous
AN> computations uses directed rounding anyway.
Unfortunately 754 already specifies the meaning of rounding modes, and
there are real uses of their current meanings (and not rare, since some of
the uses are hidden inside library functions). They could not just be
redefined, unless there was a new mode. The more likely possibility would
be to have new rounding modes instead of redefining the existing ones.
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.
People never using the new modes see the standard 754 behavior, while
those working with intervals _only_ see the new modes within arithmetic
interval operations.
The representation of DirectedInf would still be an issue.
Since the new rounding mode has its own semantics, there would not be
any incompatibility. Of course, upon conversion from interval to real,
one would have to respect the different semantics.
AN> If it is, everything is fine, and we can recommend implementors to
AN> create and prefer this version.
AN> Initially, this may be done in less efficient ways; ultimately it will
AN> be done by all implementations, and as efficiently as the current
AN> implementations, since hardly anything but applications for rigorous
AN> computations uses directed rounding anyway.
I still think that, most likely, the existing uses of directed
rounding only exploit the behavior in the finite, non-overflowing range,
so that they could easily switch from roundToInf to roundUp when
the next 754-revision is due.
The current exception handling for directed rounding is simply not
well designed; maybe the few existing applications that use it in
the exceptional range also have to work around these inefficiencies.
Arnold Neumaier