Re: Motion P1788/M0009.01_ExactDotProduct: NO
Dear Walter,
Yes, I mean that.
I am perfectly aware that in some "extreme" cases, getting a correctly rounded dot product will be almost as complex as getting an exact one.
And yet, in most cases, it will be much easier: one can for instance imagine a two-step method: the first step almost always returns a correctly-rounded result, and warns when it fails, so that an accurate second step can be used (this is the mechanism we use for correctly rounded elementary functions), so that we would always have correct results, and almost always have them quickly.
More generally, I think the standard should just focus on specifying the results of operations, without specifying a method for getting them. One could imagine interval arithmetic being implemented on very different platforms (e.g., from GPUs to supercomputers): I am not sure the solutions would be the same. Also, depending on the applications (say, simulation vs embedded computation), the constraints are very different, so that an implementor may choose strategies that minimize average time, or worst case time, or size of code (very important for embedded software), or memory consumption, or...
Regards
Jean-Michel
Le 18 nov. 2009 à 13:35, Walter Kraemer a écrit :
> 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
--
Jean-Michel Muller, directeur de recherches CNRS
Lab. LIP, ENS Lyon, 46 allée d'Italie, 69364 Lyon Cedex 07, France
Phone (+33) 4 72728229 - Fax (+33) 4 72728806
Jean-Michel.Muller@xxxxxxxxxxx http://perso.ens-lyon.fr/jean-michel.muller