Re: Motion 31 - incorporating Complete Formats into the standard
P1788
Before re-submitting the Level 1 text I need some answers relating to motion 9...
On 8 Feb 2012, at 14:07, Vincent Lefevre wrote:
> On 2012-02-07 13:04:09 -0600, Ralph Baker Kearfott wrote:
>> ...seems like there is a bit of misunderstanding.
>> In particular, motion 9, ... passed, and it says that the dot product will
>> be in the standard. Thus, the argument must
>> be related to how or where it is specified
>> in the actual standards document.
>>
>> Regarding "exact" vs "accurate" or "faithful" dot product,
>> this is still an element of informal, offline discussion.
>> The title of Motion 9 was "exact dot product," so I assume
>> this is what we voted on. (My link to the motion
>> itself comes up blank.) The position paper is
>> a description of uses of the dot product, but
>> is not written as a motion, so it is not
>> immediately apparent what the standard is to mandate...
The position paper I have is "The Exact Dot Product as Basic Tool for Long Interval Arithmetic" by Ulrich Kulisch and Van Snyder (UKVS for short), which seems to be written very much as a spec, since it contains "An implementation shall ..." sentences.
> I think that P1788 should not do the job of 754...
IMO it's reasonable to specify what we think will lead to better interval computation and has a chance of being implemented, and then worry whether it's within our remit. But it's time to clarify what voting for Motion 9 committed us to. There are several loose ends that need a separate motion -- unless an outbreak of agreement makes it obvious this isn't needed.
Voting for UKVS didn't *primarily* commit us to an exact dot product, but to Complete Arithmetic. This consists of a (limited) number of operations on a datatype called a Complete Format CF. Specifically, CF(F) = CF parameterized by a standard floating point (FP) format F which itself is characterized by
(b,l,emin,emax) = (radix, significand length, least exponent, greatest exponent).
The operations were well summarized by Michel Hack (30 October 2009 18:46:45 GMT):
- conversions between CF(F) and a FP format F' that need
not equal F but must have the same radix;
- addition and subtraction of two inputs that are CF, FP
or integer (if I understand) giving a result of a CF at
least as wide as the inputs (all are of the same radix);
- completeMultiplyAccumulate, a kind of FMA, forming a CF
result x*y+z from FP inputs x,y and a CF input z (all
are of the same radix).
UKVS specifies the interval dot product of two FP interval vectors as a by-product of these. (An inf-sup type is implicitly assumed.)
Here are some points:
(1) It seems to me Motion 9 is purely about finite-precision issues, so should not be mentioned at Level 1. (At present I mention dot product at Level 1, but to what purpose?)
(2) How to make UKVS compatible with Implicit interval types? Motion 16 says "A conforming implementation shall support at least one inf-sup type..." (*). UKVS says (above Table 1, slightly transcribed) "an implementation shall provide CF(binary64) if it provides binary floating-point and CF(decimal64) if it provides decimal floating-point" (**).
UKVS only considers CFs derived from IEEE754 FP types -- no shame in that. But we need to re-interpret (**) to cover the case that the only inf-sup interval type comes from a non-IEEE754-conforming format F -- possible on a GPU system I believe. What should we do that catches the spirit of UKVS?
How about replacing (**) by this requirement?
"Call a radix *supported* if the underlying system provides a FP
format of that radix. Let infsup(F) denote the inf-sup interval
type derived from a format F. Then there shall be at least one
format F of each supported radix, such that the implementation
provides both infsup(F) and CF(F). If it provides infsup(F) for
any 64-bit format, it shall provide CF(F) for this format."
Professors Kulisch & Snyder, and other experts, is that on the right lines?
(3) The relation of CFs to the *user level* troubles me. A CF object is pretty large, 4288/8 = 536 bytes for CF(binary64), by UKVS Table 1, and about 11 times larger for binary128.
(a) May an implementation provide just *one* CF object (per thread), which sits behind the scenes behaving like part of the Floating Point Unit? Or
(b) should the user be able to create CF variables at will, including arrays of them (Yuk)? Or
(c) is this none of P1788's business?
The specification of completeAddition/Subtraction implies that (a) is NOT sufficient. Kulisch & Snyder, is that indeed your intention?
Regards
John Pryce