Fwd: JDK 9 RFR of JDK-8030942: Explicitly state floating-point summation requirements on non-finite inputs

[Georgiy Rakov]

On 22.07.2014 20:12, Joe Darcy wrote:
> Hello Georgiy,
>
> On 07/22/2014 08:49 AM, Georgiy Rakov wrote:
>> Hello Joe,
>>
>> following assertion seems to me too loose:
>>
>>      * Because of the unspecified order of operations and the
>>      * possibility of using differing summation schemes, the output of
>>      * this method may vary on the same input values.
>>
>> as I see it this assertion imposes no constraints on how the sum can 
>> be varied. Strictly speaking, I'm afraid from conformance point of 
>> view it can cause the entire method to become untestable.
>>
>> Thank you,
>> Georgiy.
>>
>
> I would argue the statement above is just a clarification of the 
> existing (non) specification of how the method can operate.
>
> Ideally, the sum method would state an error bound for its operation. 
> There are bugs in this subcomponent mentioning adding such a bound, 
> which may be done later in JDK 9.
>
> -Joe
The sentence above and the following one actually say about 
implementation details which couldn't be verified by conformance tests - 
what is the order of summation, what is the summation scheme, whether 
the result varies because of different summation scheme.

      * <p> The value of a floating-point sum is a function both of the
      * input values as well as the order of addition operations. The
      * order of addition operations of this method is intentionally
      * not defined to allow for implementation flexibility to improve
      * the speed and accuracy of the computed result.

What do you think about turning them into implementation notes? They 
won't be normative in this case.

But I'd like to say that following sentence I would leave as normative 
since it talks about the condition which could be used in conformance 
tests - "to reduce the error bound in the numerical sum compared to a 
simple summation of {@code double} values".

      * In particular, this method may be implemented using compensated
      * summation or other technique to reduce the error bound in the
      * numerical sum compared to a simple summation of {@code double}
      * values.

Thanks,
Georgiy.