[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365924#comment-17365924
]
Matt Juntunen commented on NUMBERS-163:
---------------------------------------
IMHO, adding an {{FMA}} (or similarly named) class adds unnecessary complexity.
I would need to see a strong argument in its favor along with a use case in
order to get on board with it.
bq. [re:performance] ... the cause is probably due to at least twice as many
(useless) operations in FMA in the equivalent of your add(double t).
Correct.
bq. IMO a mutable class in the public API is a serious problem.
What exactly do you see as the serious problem here?
bq. Also: What about following Alex's suggestion of an "enum", in order to
provide a choice of implementations (with specific accuracy and performance
expectations, as per its reference description)?
I have no need or desire to implement that at this moment. I do not believe
that my design precludes that, however. If anything, having an additional class
in the mix ({{FMA}}), would make such an abstraction more difficult since the
implementation would not be completely self-contained.
bq. IMHO it is confusing to use both a generic name ("Sum") and assume specific
implementations' requirements.
How is it assuming specific implementation requirements? The API represents a
sum of terms and includes a method to add a single term and one to add a
product. This could be implemented using any number of dot-product algorithms,
where the single term method is an optimization for the case where one of the
factors is 1. I chose the class name {{Sum}} because it is the more general of
the names "sum" and "linear combination". A linear combination _is_ a sum but
not vice versa.
bq. Re. "SumPerformance.fmaSumOfProducts" vs "SumPerformance.sumOfProducts", I
consistently get better results with FMA
I would be interested in seeing those benchmarks.
> 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: 0.5h
> 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)
