[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365978#comment-17365978
]
Gilles Sadowski commented on NUMBERS-163:
-----------------------------------------
{quote}What exactly do you see as the serious problem here?
{quote}
{{Complex}}, {{Fraction}}, {{BigFraction}}, {{Quaternion}}, etc. are all
immutable.
{{Sum}} should be similar (since it just stores two {{double}} values).
{quote}I have no need or desire to implement that at this moment.
{quote}
All the hard work has been done (implementation/testing/benchmark) already. The
question to be settled is whether we want an API that allows choosing from all
the alternative algorithms.
{quote}I do not believe that my design precludes that,
{quote}
If {{Sum}} is provided as is, how would you call the "enum" that would hold
several implementations to achieve the same functionality?
{quote}How is it assuming specific implementation requirements?
{quote}
The requirements (the reference algorithms) are explicitly mentioned in the
Javadoc.
To be contrasted with something like "the resulting can have higher precision
than the equivalent operations on double values, at the expense of CPI and/or
RAM usage".
That's why I proposed an interface, which the enum could implement; for v1.0,
the latter could even contain a single {{DEFAULT}} element, corresponding to
algorithm implemented in {{Sum}}.
{quote}[new] PR #97
{quote}
Same question as in a previous comment: What's the added value of methods with
2, 3 and 4 arguments for the "add" functionality and with 4 and 6 arguments for
"addProducts"?
{quote}IMHO, adding an FMA (or similarly named) class adds unnecessary
complexity.
{quote}
True _for now_ with the algorithm which you selected in order to implement the
functionality at hand (linear combination).
My initial proposal was to float the idea of an alternative implementation,
that possibly operates on 3 values at a time (like "Math.fma" does) and not 2
(like "addProducts" does), but we can indeed delay further discussions until
such algorithm is available (provided we don't abuse of overloading – cf.
preceding question).
bq. I would be interested in seeing those benchmarks.
You just need to implement an _immutable_ version of {{Sum}} (similar to
{{FMA}}).
> Summation and LinearCombination Accumulators
> --------------------------------------------
>
> Key: NUMBERS-163
> URL: https://issues.apache.org/jira/browse/NUMBERS-163
> Project: Commons Numbers
> Issue Type: New Feature
> Reporter: Matt Juntunen
> Priority: Major
> Attachments: FMA.java, Sum.java
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It would be useful to have simple accumulator classes in {{Summation}} and
> {{LinearCombination}} to perform extended precision operations on arbitrary
> collections of values without requiring conversion to {{double[]}}. Ex:
> {code:java}
> Summation.Accumulator sum= Summation.accumulator(1d);
> sum.add(x)
> .add(y)
> .add(z)
> .add(w);
> double sumResult = sum.get();
> LinearCombination.Accumulator comb = LinearCombination.accumulator(1d);
> comb.add(x, scale)
> .add(y, scale)
> .add(z, scale)
> .add(w, scale);
> double combResult = comb.get();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
