Fwd: Motion P1788/M0045.02:DotProduct -- final text
-------- Original Message --------
Subject: Motion P1788/M0045.02:DotProduct -- final text
Date: Tue, 9 Jul 2013 15:22:25 +0100
From: John Pryce <j.d.pryce@xxxxxxxxxx>
To: rbk@xxxxxxxxxxxxx
P1788
This is the text to be voted on. Webmaster, please put this on the web site. I am happy to keep the rationale as originally written, but of course all subsequent discussion in the group is relevant.
In response to a nit from someone I changed [vectors whose length] "is given as non-integral, zero or negative" to "is not given as a positive integer". I hope this isn't some dreadful solecism.
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.
An implementation that provides 754-conforming interval types shall provide the four reduction operations sum, dot, sumSquare and sumAbs of IEEE 754-2008 §9.4, correctly rounded. These shall be provided for the parent formats of each such type.
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 not given as a positive integer, 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---