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
