Re: IEEEP1788
I have not been involved in the committee deliberations so far back, but
from my reading of the material online, it seems that the statements
regarding the usefulness of the integration of routines (or hardware) for
dot product into a programming language are not entirely justified.
Looking at
The Exact Dot Product as Basic Tool for Long Interval Arithmetic
I quote
"Experience has shown that computing the dot product by function calls
leads
to clumsy and awkward programming. "
I don't understand this. If A,B are vectors (or pointers to vectors)
and C is a storage array for a (complete?) number (or pointer to it), then
C:=dotproduct(A,B)
is probably supportable in some languages. Maybe
C:= A dotproduct B.
but even a FORTRAN call dotproduct(A,B,C)
is not so bad.
In my opinion, what is clumsy and awkward from a programming language
perspective is the introduction
of another numeric type which participates only partially in the suite
of operations that work
with the other numeric types.
For example, if C1,C2, .. are complete numbers computed from dotproduct,
and F1, F2, ... are ordinary floats of some type,
can one compute sqrt(C1)? cos(C1), C1^C2, C1*C2, C1^F1?
Can one compute a dot product where the vector entries are C1, C2, .... ?
Are these silly things to compute? I don't know, but I would make 2
observations here.
1. Some of these items break the notion of completeness since they could
lead to overflow, I think.
So to just add exact dot product / complete numbers to a programming
environment but only allow
them in very restricted circumstances would be confusing, and one might
in fact have to write substantial
frameworks for the programming language to allow only the legal
operations, or to signal overflow if
they are attempted and they do overflow.
2. Arbitrary precision floats and many operations on them
are supported by existing programming packages such as MPFR,
or any number of computer algebra systems.
In fact these provide much more: truly arbitrary precision floats,
directed roundings,
elementary function evaluation, input and output.
I expect that a system such as MPFR could be set up to include
a component that provides exact/complete dot product. Whether MPFR (etc)
could be
hooked up to special hardware to do complete arithmetic when useful
would not be out of the
question. So it appears to be a superset capability, and not necessarily
slower.
And it would not make a hash of the supporting programming language.
Richard Fateman
Without On 4/27/2015 10:14 AM, Oliver Heimlich wrote:
On 27.04.2015 18:16, Ulrich Kulisch wrote:
Am 21.04.2015 um 22:36 schrieb Oliver Heimlich:
The only place, where IEEE 754 specific arithmetic is actually used in
the standard document, is in chapter 12.12.12 (reduction operations on
IEEE 754 data types), where arithmetic with NaNs and signed zeros is
required. Again, this only applies if the implementation supports IEEE
754 data types.
Oliver Heimlich
*Comment: *The entire section 12.12.12./Reduction operations /would be
superfluous if in the section 12.13.5 /Exact reduction operations/ the
*should* would be replaced by *shall*. All operations in 12.12.12. would
then be simple consequences.*
****
**The logic behind all this:* We have two problems:
Problem A: compute dot products exactly,
Problem B: compute dot products correctly rounded.
Evidently a method that solves A also solves B. The opposite is not
true!
Problem B looks simpler than problem A. So P1788 requires B.
But in fact solving A is much simpler and faster than all known
solutions of B that ignore A.
In the document P1788 the dot product should already be mentioned in
/4.2 Definitions,/ in particular in:/
//4.2.6. arithmetic operations.*
**A basic arithmetic operation* /is one of the seven fuctions +, -, ×,
÷, fused multiply add (fma), dot product (dot), and square root (sqrt).
There is no reason why the dot product should be given less weight than
fused multiply-add, and there are good reasons for listing it under
basic arithmetic operations (speed and accuracy). In an early draft of
P1788 it was indeed listed here.
The dot product is a fundamental operation in Numerical Analysis. It
allows a simple and very fast implementation on computers. *The exact
dot product* is the key operation for variable precision interval and
floating-point arithmetic. It would be a highlight of P1788.
Best wishes
Ulrich
Personally, I completely agree. I have filed a similar comment on the
importance of dot and on the need for interval vectors in the first
sponsor ballot. This has been the “official” answer for comment
#18333500023:
“Extensive discussion, involving at least three motions, indicates
that the chosen design, while not perfect, is the compromise most
acceptable to the whole group. Interval reduction operations were not
regarded as a high priority. As for Complete Arithmetic, there was
support for a possible project to make it a separate IEEE standard.”