[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17365439#comment-17365439
]
Gilles Sadowski commented on NUMBERS-163:
-----------------------------------------
{quote}name is also incorrect
{quote}
Class was just named so because it computes [the exact product of the first two
arguments summed with the third
argument|https://docs.oracle.com/javase/9/docs/api/java/lang/Math.html#fma-double-double-double-]
Alex mentioned that the requirements for {{Math.fma}} (the "true" one) are
different; no problem: Class can be called {{LinearCombination}} or {{Dot}} or
{{SumOfProducts}}.
What I'm discussing is whether
* immutability (cf.
[ValJO|https://blog.joda.org/2014/03/valjos-value-java-objects.html] which
almost everything in [Numbers] is based on)
* accumulation
can be provided together (without too much loss of performance).
bq. performance implications
I certainly did not get similar results; we likely are testing different
use-cases...
Such a big discrepancy would warrant a separation of the above two properties.
IMO a *mutable* class in the public API is a serious problem. I recall that a
long, long, time ago, we switched to an immutable {{Vector3D}} on the ground
that it was _not_ less performant.
bq. source algorithms
IMHO it is confusing to use both a generic name ("Sum") and assume specific
implementations' requirements.
Shall we define an interface:
{code}
public interface SumOfProducts implements DoubleSupplier,
BinaryOperator<SumOfProducts> {
SumOfProducts add(double m1, double m2);
SumOfProducts add(SumOfProducts other);
@Override
default SumOfProducts apply(SumOfProducts a, SumOfProducts b) {
return a.add(b);
}
// ...
}
{code}
?
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)?
> 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)
