Re: exact dot product
On 2013-05-23 08:20:43 -0500, Ralph Baker Kearfott wrote:
> Ulrich, Dan, P-1788,
>
> OK, now I think I understand what you mean by "complete arithmetic";
> let me paraphrase: If we have a long chain of operations with inputs
> (base nodes in the expression tree) in one of the basic floating
> point formats, then the arithmetic is done in such a way that the
> output (leaf of the expression tree) is the exact result. This exact
> result can then be rounded into the floating point type.
If the final goal is to round the final result or get an interval
containing it, then you do not need "complete arithmetic". The same
result could be obtained by other means.
And an exact dot product could also be obtained in a context of
multiple precision. Again, no need for "complete arithmetic".
> Personal opinion (not as acting chair): I don't see it as within the
> scope of P-1788 to specify the number of bytes needed, or the exact
> bit pattern of any data type to effect this result. However, it is
> possible for us to specify a data type that will hold the exact
> result, and we may give (in non-normative explanatory text) the long
> accumulator as an example.
With the advantage that it could be more powerful than that.
> (Again as acting chair): The questions I have for the working group are:
>
> * Do we interpret our decision in Motion 9 to mean we just want an exact
> dot product, or do we interpret it to mean we want both an exact
> dot product and complete arithmetic?
Complete arithmetic would be used more like a particular arithmetic
or a particular format. That's not abstract enough.
> * If we just want an "exact" dot product, and do not intend to
> define an "exact" data type, it is possible to use 754-language,
> which had registers and memory storage patterns in mind: The
> rounded-down, rounded-up, rounded-to-nearest, or
> rounded-towards-zero result of the dot product would be "as if"
> the exact result were first computed, and the dot product would
> be a required function with the same requirements as the other
> optional functions. However, if we mean by "exact dot product"
> that a representation of the exact result be available, we would
> need to specify how that is done, and the situation would be
> more similar to the situation where we require complete
> arithmetic.
You do *not* need to specify *how* this is done. You just need to say
that you have a datatype that can always represent the result exactly.
> So: (1) Do we want complete arithmetic or just an exact dot product?
An exact dot product could be OK (in such a case, also include an
exact sum). But you also need to specify the inputs (be careful
that IEEE 754 allows extended precisions, with potentially large
exponent range).
> (2) If we just want an exact dot product, do we want access to a
> representation of the exact result?
Do you need the representation? What would this mean in practice,
with the endianness problems?
What do you want to do with an exact dot product? e.g. compare two
results? Should such operations be specified in the standard?
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)