[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746174#comment-17746174
]
Anirudh Joshi commented on STATISTICS-77:
-----------------------------------------
I understand that it makes sense to not throw exceptions during the {{combine}}
operation of instances using different underlying implementations of a
{{{}Statistic{}}}. If we would want to support this along with a flexible API
(i.e. possibly supporting different algorithms to compute the
{{{}Statistic{}}}), I feel we would not be able to make guarantees about the
accuracy and / or efficiency of the combine operation, with a single combine
method.
We could possibly support {{combine}} of instances created with different
underlying implementations with a {{javadoc}} stating that if {{combine}} is
used outside of the {{DoubleStream#collect}} or {{Stream#collect}} target, it
might result in first instance losing precision and / or the combine being
inefficient (since this could possibly involve finding the type of the instance
being combined through the {{instanceof}} operator).
I was also thinking about defining 2 combine methods in the
{{DoubleStatisticAccumulator}} interface as follows
- combine(T other);
- safeCombine(T other);
with {{javdoc}} stating that {{combine}} does a direct cast of the input param
and is intended purely as a target in {{{}Stream#collect{}}}. {{safeCombine}}
tries to ascertain the type of the input param being combined and makes a best
effort combine with no guarantees about precision and / or efficiency.
Of course, nothing can prevent an user from calling combine on two instances
with different underlying implementations and this would result in a
{{ClassCastException}} which I feel would be ok (since the user should ideally
be calling {{safeCombine}} method).
The downside of this approach (whether we have 2 combine methods or a single
combine method) is that, when a new implementation is added, we would be to
ensure that all the {{combine}} / {{safeCombine}} methods for existing
implementations are updated to support the new implementation.
Let me know your thoughts on this and other alternatives.
> 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)
