Reduction operations in P1788/D9.5
On Sun, 11 Jan 2015 07:17:49 +0000, John Pryce wrote:
> 754 is fairly clear on what NaN *does* -- the Level 2. (Actually it's
> vague on the Level 2 of NaN payloads.) It is vague on what NaN *is* --
> the Level 1. Of several views of NaN at Level 1, two are
> A. NaN is the result of a previous error.
> B. NaN stands for an unknown number, finite or infinite.
Yes. And, as John points out, Inf is also overloaded -- as is zero.
Note that the above applies to QNaN.
There are also three common views of SNaN:
C. An uninitialised table entry or variable
D. Encoded diagnostic information
E. An encoded nonstandard representation
Interpretation E is useless unless Invalid Operation traps are enabled.
The other two survive quieting in the absence of traps, with C mapping
to either A or B, and D typically mapping to B.
> However 754 does distinguish sNaN from qNaN. My suggestion is
> that 1788 might use these for views A and B. This can be done
> by a sentence in 12.12.12 such as
>
> In this standard, in any IEEE 754 format, a signaling NaN
> is regarded as the result of a previous error, while a
> quiet NaN stands for an unknown number, finite or infinite.
No -- this does not work, as no operation *generates* SNaN.
All errors result in QNaN, and this includes converted SNaNs.
Note that there are few genuine error cases in 754 -- the only one
that comes to mind (besides SNaN conversion) is sqrt() of a negative
argument. The "indefinite forms" 0/0 or Inf-Inf can in many contexts
be interpreted as B, because the zero or Inf may have been "impure",
i.e. the result of underflow or overflow.
> The precedence rule for sumAbs, implied by this Level 1 meaning,
> would then be
> If an sNaN is encountered, sNaN shall be returned. Otherwise, if
> an Infinity is encountered, +oo shall be returned. Otherwise, if
> a qNaN is encountered, qNaN shall be returned.
One of the goals of "754-conforming 1788" is to allow an implementation
to be based on an underlying 754-conforming system. In that case, it
would be very unwise to change the rules for an inherited operation.
> Michel, and others expert in low-level aspects, can say if this fits well
> with the 754-defined behaviour of sNaN and qNaN, and if it can implemented
> efficiently enough that the extra clarity outweighs the cost.
It's not an efficiency issue; it's more fundamental than that: (a) the
information needed to distinguish A from B is typically unavailable, and
(b) even assuming that interpretation A can be ascertained, code would have
to be inserted to convert QNaNs to SNaNs, a very non-standard operation.
At one point I had proposed -- as a thought experiment only, not as an
actual implementation proposal -- a variant floating-point format that
redefined the low-order significand bit as an "impurity" indicator, with
associated new arithmetic propagation rules. It may be on our website
under the name ifp.pdf (January 2012). That document examines some of
the issues related to overloading of zero and Inf. But the solution is
necessarily incomplete, as operations on "zero with an indeterminate sign"
may still be forced to return NaN.
Michel.
---Sent: 2015-01-11 14:37:47 UTC