[
https://issues.apache.org/jira/browse/STATISTICS-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17746879#comment-17746879
]
Gilles Sadowski commented on STATISTICS-77:
-------------------------------------------
bq. Let me know your thoughts on this and other alternatives.
IMO, we have delineate what is the most important service these classes will
provide, before trying to cover rare use-cases.
Casual usage does not need to bother with figuring out which of {{combine}} or
{{safeCombine}}; if it seems that {{safeCombine}} is safer, a user will pick it
even if he will most probably call it where {{combine}} would have been fine,
thus loosing whatever efficiency was available.
In the context of a library, a developer may have to always call
{{safeCombine}} in methods that cannot know which implementations they receive
as input.
I repeat that if we stick with the decision made in [Numbers] for
[{{Sum}}|https://commons.apache.org/proper/commons-numbers/commons-numbers-core/javadocs/api-1.1/org/apache/commons/numbers/core/Sum.html],
the issue vanishes (IOW, we stop wondering how to implement a service which we
don't intend to provide).
> 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
> Fix For: 1.1
>
>
> 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)
