--- Begin Message ---
Arnold Neumaier schrieb:
> 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 result of the exact dot product in example 2 is not exactly
representable. The exact result is m - square(smallest pos. flp number).
> 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.
>
But this still implies that intermediate overflow and underflow
situations are always handled correctly, doesn't it?
Walter
>
> Arnold Neumaier
>
>
--- End Message ---