[PATCH] 8178117: Add public state constructors for Int/Long/DoubleSummaryStatistics

Peter Levart peter.levart at gmail.com
Wed Apr 12 20:58:54 UTC 2017


Hi Joe,

On 04/12/2017 07:59 PM, Joseph D. Darcy wrote:
> On 4/11/2017 1:48 PM, Chris Dennis wrote:
>> Color me confused… what would the javadoc on the parameter say? It 
>> could I guess have an @implNote documenting the meanings of the 
>> parameters… but then what use is it? The proposed API simply limits 
>> the precision with which a DoubleSummaryStatistic can be copied to be 
>> the same as the precision with which it can be “accessed”.  That 
>> doesn’t seem an enormous problem since I suspect that bulk of usages 
>> would be to marshall a “finished” instance and therefore there is no 
>> real loss occuring. If we wanted to support arbitrary precision 
>> wouldn’t it be better to have a constructor variant that took a 
>> BigDecimal, and a matching getPreciseSum() that returned a BigDecimal?
>>
>
> The javadoc would say something like "takes an array of double values 
> representing a sum." In other words, rather than forcing the 
> in-progress sum to be represented as a single double, it could be 
> represented as more than one double.
>
> The current implementation basically uses two doubles internally to 
> represent the on-going summation. This extra state prevents many 
> numerically poor outcomes occurring when computing the sum. Greater 
> accuracy would be possible if additional internal state were used.
>
> -Joe
>
>

But constructor taking this state is not enough for the solution to the 
problem. There would have to be a getter returning that state too, 
otherwise there's no point in having such constructor, right?

Are you envisioning that any possible future enhancements of the 
summation would all keep the state as a series of double values?

Regards, Peter



More information about the core-libs-dev mailing list