[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746042#comment-17746042
]
Alex Herbert commented on STATISTICS-77:
----------------------------------------
IMO:
If the API does not expose some way to know the underlying implementation then
it is not reasonable to throw an exception because the user could not know the
combination is invalid. The reasonable result is that it works. Any loss of
precision is better than simply refusing to work (exception).
The primary use case for combine would be in the reduction of a parallel
stream. Here the objects are of the same type as they are created by supplying
a generator for the parallel instances. Combinations of mismatched types may be
rare in general usage, and the negatives of throwing exceptions outweigh
possible benefits of the combination being of the correct type.
Currently the Sum class is only extended within the descriptive package due to
the use of a package-private constructor. As more implementations are added, an
all-vs-all combine must be tested to ensure compatibility. This would be true
of any Statistic combine method. Total incompatibilities within the type should
be rare. E.g. A population and sample variance can be combined; in this case
the statistic being combined into may take precedence. If incompatibilities or
possible loss of precision (or other side effects) do arise, then the behaviour
should be appropriately documented.
Some alternatives:
# Allow the API to be used to check if a combine is allowed (e.g.
a.canCombine(b) or a.getType() == b.getType()). This will bloat the API
somewhat and make usage a burden for users who combine stats of unknown origin.
# Document that mismatched types will throw an exception and expect users to
use a try-catch with a fallback:
{code:java}
Sum a;
Sum b;
try {
a.combine(b);
} catch (RuntimeException e) {
a.add(b.getAsDouble());
}{code}
Note: If this is considered, then why not do this anyway within the statistic
combine method and make them compatible.
> Implement Sum
> -------------
>
> Key: STATISTICS-77
> URL: https://issues.apache.org/jira/browse/STATISTICS-77
> Project: Commons Statistics
> Issue Type: Sub-task
> Components: descriptive
> Reporter: Anirudh Joshi
> Priority: Minor
> Labels: gsoc, gsoc2023
>
> This implementation uses {{commons-numbers}}
> [Sum|https://github.com/apache/commons-numbers/blob/master/commons-numbers-core/src/main/java/org/apache/commons/numbers/core/Sum.java]
> as the underlying implementation.
> This may be further expanded to include various other Sum implementations
> like [Kahan Sum|https://en.wikipedia.org/wiki/Kahan_summation_algorithm],
> {{Neumaier Sum}} (Two sum method) etc. with the option for the users to
> choose an implementation. However, before beginning the implementation of
> various other algorithms it may be worthwhile to discuss and investigate the
> relative speed of the current Sum implementation compared to
> {{DoubleStream.sum}} through JMH benchmarks.
> When we know the different speeds, it would be more clear if the user should
> have a choice for this statistic, e.g.
> * When using {{DoubleStream.sum}} is too slow and it would be nice to have a
> simple sum variation.
> * When the sum has a lot of cancellation and {{DoubleStream.sum}} suffers
> from random walk around zero.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
