Just to confirm this looks fine to me. From my point of view too much input
validation would seem a little odd given that the implementation does nothing
to protect itself from overflow in the first place.
> On Nov 1, 2017, at 1:21 PM, Paul Sandoz <paul.san...@oracle.com> wrote:
>
>
>> On 31 Oct 2017, at 16:46, joe darcy <joe.da...@oracle.com> wrote:
>>>>
>>> In that case we need to double (sorry) down on the NaNs and include sum as
>>> well:
>>>
>>> * <li>{@code (min <= max && !isNaN(sum)) || (isNaN(min) && isNaN(max) &&
>>> isNaN(sum))}
>>
>> A more complete test for the numerical consistency conditions would be
>> something like
>>
>> min <= sum/count <= max
>>
>> However, that would require a bit of thought due to potential round-off so
>> this might not be worth the complexity trade-off. (If any of min, sum, and
>> max were NaN, the comparisons would be false.)
>>
>
> Yes, my recollection from the discussions we concluded not to do such checks.
>
> Paul.
