Re: Motion P1788/M0045.01:ExactDotProductRevision -- discussion period begins
On 2013-06-05 14:36:45 -0500, Ralph Baker Kearfott wrote:
> ======
> Motion
> ======
> 1. The status of Exact Dot Product EDP and Complete Arithmetic CA
> be changed from required to recommended.
About Complete Arithmetic (CA): I think it should be at most
informative, just given as an example for EDP (if accepted).
The reasons are:
* Its main purpose seems the implementation of some particular
operations: EDP and variants (exact sums...). It doesn't seem to
have any other practical applications; for instance, it can't be
extended to do exact divisions... This would mean that CA would
be there only to specify *how* EDP is implemented, not just as a
general arithmetic. This would be bad because a standard should
specify the behavior of operations, not how they are implemented
and because there are (better?) alternatives (see below).
* CA is mostly targeted at hardware implementations, while P1788
is not a standard on hardware. Even for hardware, CA may not
be that interesting: it would take resources that could be
used for other, more common purpose. And the fact that CA was
implemented in hardware in the past but has been dropped means
that it was not so attractive. No processor vendors have shown
a particular interest in implementing CA in the future.
* In software (in particular), there are alternatives, which are
probably better, based on conventional multiple precision or
some forms of FP expansions...
* There are almost no implementations (see also the second point
above).
* There are not many potential CA users, at least compared to the
users of floating-point and the users of interval arithmetic.
About Exact Dot Product (EDP): It doesn't need CA. The return type
could be an abstract type able to represent the result exactly. One
important question is: What do you want to do with the exact result
of EDP? If you just want to be able to convert the result to a basic
floating-point format, then you do not need the exactness of EDP:
an accurate implementation, which IEEE 754-2008 can provide, may be
sufficient and would be much faster in average. So, I don't think
that EDP should even be recommended (just be made optional), except
if it is shown that exactness is more useful than accuracy.
Note that for applications requiring more than accuracy, EDP could
be useless as its inputs are just basic FP numbers, whose precision
may not be sufficient.
> 2. The current text on EDP and CA (11.11.11 in the current
> draft) be moved to Level 3 with minor revisions and replaced at
> Level 2 by the following text:
>
> ---start of text---
> An implementation that provides 754-conforming interval types
> shall provide the four reduction operations sum, dot, sumSquare
> and sumAbs of IEEE 754-2008 §9.4, correctly rounded. These shall
> be provided for the parent formats of each such type.
And I think this is bad because one would have an implementation
from IEEE 754-2008 and an implementation from P1788. IMHO, the
following would be better:
An implementation is said to be 754-conforming if:
* [the current conditions...]
* the four reduction operations sum, dot, sumSquare and sumAbs
are provided by the IEEE 754-2008 implementation and are
correctly rounded. [Details...]
[...]
> Unavoidable overflow results from adding an extremely large
> (implementation-dependent) number of large terms of the same
> sign. If it occurs, NaN shall be returned and an
> implementation-defined exception shall be raised. [Note. An
> implementation should be designed such that the relevant number
> of terms is unachievable with current hardware, making overflow
> impossible in practice. For example, CA for IEEE 754 binary64,
> parameterized as recommended by Kulisch and Snyder, requires 2^88
> terms before overflow can occur.]
2^88 was just an example. It may not be sufficient in case of
optimizations such as compile-time evaluation when possible
(now, a user wouldn't probably write such a code using so many
terms, at least before a distant future).
> It is recommended that these operations be based on an
> implementation of Complete Arithmetic as specified in §X.Y.
I wouldn't say "recommended" because one can do better as said above.
CA could just be given as an example for hardware implementations.
[...]
> CA is not appropriate at *all* points along that spectrum. But
> if CA is as good as its supporters say, the market will find it a
> place somewhere in that spectrum. A strong recommendation in
> 1788 should help this happen.
I don't think so. Implementers, applications needing it, and a large
community could help this happen.
Note that even directed rounding modes, which have been *required*
since 1985 by IEEE 754 and are very useful (almost necessary) for
verification purpose (e.g. in interval arithmetic), are still not
yet supported by GCC. Similarly, IEEE 754 exceptions are not well
supported by some compilers, so that writing portable code is
difficult.
--
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)