Re: Motion P1788/M0009.01_ExactDotProduct: NO
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)?
Remark: similar computations are e.g. necessary when implementing a complex
(interval) arithmetic.
Best regards, Walter
Ralph Baker Kearfott schrieb:
> My vote is NO
>
> A change that would make me vote YES:
> I would vote "YES" if, instead of an exact dot product, we mandated
> a dot product that is correctly rounded to the working precision.
> In the case of point inputs, this would mean that round-down,
> round-up, and round to nearest would be supported. For instance,
> in round to nearest, it would mean the nearest floating point
> number to the exact dot product.
>
> Note that this change would not preclude an implementer from supplying
> an exact dot product, and that would be one way the requirement
> could be achieved. However, a correctly rounded dot product
> both ensures cross-platform reproducibility and avoids certain
> efficiency or difficulty issues in implementation.
>
> Baker