Motion P1788/M0045.02:ExactDotProductRevision -- revised text
P1788
I submit Motion 45.02 which is a friendly amendment of Motion 45. Changes:
- Dan Zuras (20130605) found Clause 1 a bit ambiguous, so I revised it. I hope this removes the ambiguity.
- I changed the words about "unavoidable overflow" (renamed "intermediate overflow" which is what it is) to require that it be impossible in practice. This shortens the text a bit.
- Vincent Lefevre was unhappy with para. 1 of the proposed text producing a clash between reduction operations possibly provided by an underlying 754 system ("754 reductions"), and those provided by 1788. I think he still dislikes the rewording below, as he says:
>
> This is my point: avoid having two versions (at least from two
> different standards). This would add confusion and difficulties
> for writers of portable user code. The right solution would be
> to "fix" the IEEE 754 implementation. Let's recall that it was
> said that the IEEE 754 intent was to have these operations
> correctly rounded.
Yes indeed. But if the implementers of some 754 implementation don't get round to it (it's regarded as low priority, programmer falls under a bus, ...), surely the 1788 implementers should be allowed to provide their own? And write configuration files that ensure the correct versions are used? Experts on implementation, please comment.
I hope recent discussion in the "back to the roots" thread, on the question "who needs highly accurate computation on inexact data?", has convinced the skeptics that the answer is "you do, very much, sometimes" so these operations have an important place in the standard.
I acknowledge that Prof Kulisch will be disappointed by the change that this motion makes, if it passes. But the ineluctable facts are
- Several experts have argued conclusively that for *software* implementations, CA is not the most efficient algorithm to compute the accurate sums, etc., needed in applications.
- 1788 is not authorised to require that anything shall be done in hardware. So the fact that CA is efficient in hardware may affect what 1788 states as recommended, but not what it states as required.
Chair, I hope we can proceed to a vote after a few days.
John Pryce
======
Motion
======
1. An implementation of Exact Dot Product EDP and Complete Arithmetic CA be no longer required by P1788. They should be treated as a recommended way to achieve the broader aim of evaluating highly accurate sums and dot products, which has many uses in interval computing.
2. The current text on EDP and CA (11.11.11 in the current draft) be moved to Level 3 with minor revisions and replaced at Level 2 by the following text:
---start of text---
Reduction operations.
In an implementation that provides 754-conforming interval types, correctly rounded versions of the four reduction operations sum, dot, sumSquare and sumAbs of IEEE 754-2008 §9.4 shall be provided for the parent formats of each such type. If such correctly rounded operations are provided by the underlying 754 system, these shall be used; otherwise they shall be provided by the implementation.
Correctly rounded means that the returned result is defined as follows.
- If the exact result is defined as an extended-real number, return this after rounding to the relevant format according to the current rounding mode. An exact zero shall be returned as +0 in all rounding modes.
- Otherwise return NaN.
All other behavior, such as overflow, underflow, setting of IEEE 754 flags, raising of exceptions, and behavior on vectors whose length is given as non-integral, zero or negative, shall be as specified in IEEE 754-2008 §9.4. In particular, evaluation is as if in exact arithmetic up to the final rounding, with no possibility of intermediate overflow or underflow.
Intermediate overflow could result from adding an extremely large number N of large terms of the same sign. The implementation shall ensure this cannot occur. This is done by providing enough leading carry bits in an accumulator, or equivalent, so that the N required is unachievable with current hardware. [Note: For example, Complete Arithmetic for IEEE 754 binary64, parameterized as recommended by Kulisch and Snyder, requires around 2^88 terms before overflow can occur.]
It is recommended that these operations be based on an implementation of Complete Arithmetic as specified in §X.Y.
---end of text---