Re: Motion P1788/M0045.02:ExactDotProductRevision -- revised 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.
Here is an example from my experience. I wanted to be able to connect VNODE-LP to any interval package
with as little effort as possible. This meant: create a small set of wrapper functions.
I did not expect the underlying package to provide e.g. linear algebra operations.
I wrote what I needed myself and often used the Standard Template Library. I could have used PROFIL's
Matrix and Vector classes, but then I was stuck with it. (I am finally writing an article on this package,
where I discuss such issues.)
For the reduction operations: why don't we build them on top of the basic interval type and operations,
so we are independent of the underlying architecture. It may be slower, but trust me, it will be much
more portable and easier to install a package that implements these operations in such a way.
My view is: let's standardize as a minimal set of operations as possible and use them to build on top of them.
When a nontrivial interval software is produced, and efficiency is an issue, one can take advantage of
"recommended" IEEE754 operations, if they are present.
Anyhow, I am strongly convinced we need to have the above reduction operations independent of what is available
as recommended operations by IEEE754. I would count only on what must be present in an IEEE754 conforming
system.
Hope the above is helpful.
Regards,
Ned
> 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---