Re: Motion 31: V04.2 Revision of proposed Level 1 text
P1788, in particular Vincent, Dmitry, Dan
On 26 Jan 2012, at 13:19, Vincent Lefevre wrote:
> On 2012-01-25 11:07:04 -0800, Dmitry Nadezhin wrote:
>> 2) fma(x,y,z)
>> The operation fma is mentioned in definitions, but the document
>> don't clarify the status of interval version fma. Is it required,
>> recommended or none ?
>
> At Level 1, it is the same as x * y + z. I wonder whether it should
> be defined. Level 2 could introduce a generic concept of fused
> operations, and recommend or require some of them.
> (If there is a dot product, why not a sum of n intervals?)
>
Oh dear, fma is meant to be required.
>> 3) negate(x) = -x
>> The unary minus is an operator in most programming languages.
>> Shouldn't we require interval version of negate ?
>
> This is equivalent to 0 - x, and since { 0 } can be exactly
> represented by [0,0], negate(x) may not be really necessary.
> Ditto for recip(x), since { 1 } can also be exactly represented
> by [1,1].
There are good arguments in either direction. We need a consistent policy on when derived operations (ones expressible in terms of existing ones) should have a separate definition in the standard.
If you take the argument against fma to its conclusion, you'll decide not to give a definition for atan (derivable from atan2) or sinh and cosh (derivable from exp). IMO this is going too far.
My attempt at a consistent policy is informal and incomplete:
(a) If an operation is defined (for floating point) in all the common scientific languages,
that's a good reason include it. That means include negate(x) (as required).
(b) If it is a required operation in 754, we should make it required. That means fma should
be required. Also, fma is a formatOf operation (754§5.4.1) so an implementation, that
supports the mentioned types in a 754-conforming way, shall support, e.g.,
ww_binary64 = fma_binary64(xx_binary128, yy_binary32, zz_binary64)
with the indicated inf-sup types of the inputs and output, with a "tightest" result, i.e.
the binary64infsup hull of the mathematical result. Other types shall provide fma, but
are neither required to make it "tightest" nor required to support mixed-type operations.
(c) Some cases puzzle me. We have sqr(x)=x^2 required because in interval arithmetic it
behaves much better than x*x. But it is the case of (required) pown(x,p) when p=2. And
the case for recip, which is pown(x,p) when p=-1, is even weaker.
Should we remove these (and similar cases such as rsqrt(x)) from the Level 1 lists, and
say they just rename existing operations? I regard negate(x) as different, since
defining it as 0-x converts a 2-real argument to a 1-real argument operation.
Dan, I think you have the experience to devise a consistent policy for this issue. Are you willing to submit a motion on it? I think my arguments (a,c) are just about Level 1, but (b) straddles Levels 1 and 2.
John