Re: Motion P1788/M0009.01_ExactDotProduct: NO
On Wed, November 18, 2009 13:35, Walter Kraemer wrote:
> Dear Baker, dear Jean-Michel and others,
>
> just to be sure: Does "correctly rounded dot product" mean
>
> Example 1:
> Let m denote the largest flp number and x and y flp vectors with
> x[1] = x[2] = x[3] = m;
> y[1] = m; y[2] = 1; y[3] = -m;
> Then the computation
> r = correctly_rounded_dot_product(x,y)
> results in the value m (i.e. no intermediate overflow) independent of the
> rounding mode in use?
>
> Example 2:
> x[1] = smallest positiv flp number, x[2] = x[3] = x[4] = m;
> y[1] = -smallest positiv flp number, y[2] = m; y[3] = -m; y[4] = 1;
> Then the computation using round to -infinity
> r = correctly_rounded_dot_product(x,y)
> results in predecessor(m)?
In both cases, the result is exactly representsable, hence m should be
returned independent of the rounding mode.
The main difference between the correctly rounded dot product and the
exact dot product as required by the current motion is that the latter
would require to compute and returm the exact result to 4000 or more
binary digits in case the exact inner product have this many digits --
e.g., for the dot product of (maxpos,minpos) with itself -- although most
of these digits are never inspected.
While this may be adequate in a hardware implementation that has special
registers for accumuating such ultralong numbers, it is a disastrous
requirement for software implementations.
In contrast, the correctly rounded dot product is assumed to be exact
_only_ when the exact value of the dot product happens to be exactly
representable.
Arnold Neumaier