[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17368551#comment-17368551
]
Matt Juntunen commented on NUMBERS-163:
---
Docs added in b46db089d6a16f7cf2371a1521507218dd2df96a
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17368395#comment-17368395
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. extra Sum documentation
+1
Thanks!
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17367797#comment-17367797
]
Matt Juntunen commented on NUMBERS-163:
---
I've created a PR with extra Sum documentation (along with a build fix for the
jmh module): https://github.com/apache/commons-numbers/pull/100
If anyone is able to give it a quick once-over that would be appreciated.
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366851#comment-17366851
]
Matt Juntunen commented on NUMBERS-163:
---
bq. Do you want to support this?
I do not. I'm of the opinion that we add a bit more documentation, per [~erans]
comments above, and then stick a fork in it.
On a related note, I just made a PR for GEOMETRY-126, which updates
commons-geometry to use the new {{Sum}} class instead of {{LinearCombination}}.
I also removed the {{VectorXD.linearCombination()}} methods there and replaced
them with {{VectorXD.Sum}} classes following the pattern we just used here.
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366760#comment-17366760
]
Alex Herbert commented on NUMBERS-163:
--
I think that allowing the addition of a BigDecimal in the API would have
problems ensuring accuracy. Either you convert the BigDecimal to a double (loss
of precision) or you convert it to a series of overlapping double values and
add each one. This will be slow.
Untested...
{code:java}
// Addend
BigDecimal x;
if (x.abs().compareTo(new BigDecimal(Double.MAX_VALUE)) > 0) {
// Throw or just make the sum infinity
throw new IllegalArgumentException("Too big");
}
while (true) {
double d = x.toDouble();
if (d == 0) {
// Because BigDecimal can be below Double.MIN_VALUE
break;
}
// Add the double d to our sum
// Get the rest of the number
x = x.subtract(new BigDecimal(d));
}
{code}
Do you want to support this?
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366317#comment-17366317
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}[...] can of worms.
{quote}
Good point.
The flexibility is probably not worth the trouble:
# we choose the best compromise (accuracy, performance),
# we document that the choice may be different in future releases,
# we refer to the alternative implementations in the "examples" module.
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366243#comment-17366243
]
Matt Juntunen commented on NUMBERS-163:
---
One effect of this is that downstream APIs, such as {{Norm}}, would need to
choose whether to code to a specific algorithm or increase their complexity by
allowing the user to specify the algorithm. This could potentially be a can of
worms.
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366238#comment-17366238
]
Matt Juntunen commented on NUMBERS-163:
---
Looks good to me. Thanks.
I thought about it some more and your proposal of having an enum to select the
summation algorithm no longer seems like such a major leap. I sketched it out
in code just now and this is what I came up with.
{code:java}
// interface abstraction of the current Sum class with additional methods
// to add and return BigDecimal
public interface Sum extends DoubleSupplier, DoubleConsumer {
Sum add(double v);
Sum add(double... arr);
Sum add(BigDecimal d);
Sum add(BigDecimal... arr);
Sum add(Sum s);
Sum addProduct(double a, double b);
Sum addProducts(double[] a, double[] b);
BigDecimal getExact();
}
// enum for selecting the algorithm and creating instances
public enum Summation {
// standard double operations
STANDARD(...),
// Current dot2s algorithm
DOT2S(...),
// DotK(x) algorithm in examples-jmh with k = 3
DOTK3(...),
// other dotk implementations, eg DOTK4, DOTK5, ... ?
...
// exact computation using BigDecimal
EXACT(...);
// create a new sum instance
public Sum create() { ... }
// create a new sum instance initialized with the given value
public Sum create(double val) { ... }
public Sum create(BigDecimal val) { ... }
}
{code}
The majority of the work here would be unit tests. Also, the name {{Summation}}
for the enum isn't striking me as quite right, although it works. I'd like it
to be {{Sum.DOT2S.create()}} but {{Sum}} works best for the interface name.
[~erans], [~aherbert], thoughts?
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17366077#comment-17366077
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. [...] benchmarks
Using the one from PR #97, {{Sum}} is consistently ~15% faster.
I assume that it exercises the intended use case (array arguments). I had been
testing chained calls...
I've just committed {{Sum}} from PR #97 with some minor changes:
* Javadoc style
* Replaced methods with multiple similar arguments (cf. earlier comment)
Please review.
> 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 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365926#comment-17365926
]
Matt Juntunen commented on NUMBERS-163:
---
FYI, I closed my previous merge request and opened a new one based on the
{{Sum}} class: https://github.com/apache/commons-numbers/pull/97
This may help with the current discussion.
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365898#comment-17365898
]
Gilles Sadowski commented on NUMBERS-163:
-
Re. your benchmark "SumPerformance.fmaSum" vs "SumPerformance.sum", the cause
is probably due to at least twice as many (useless) operations in {{FMA}} in
the equivalent of your {{add(double t)}}. [Although in my timings, the gap is
~2, not ~3.6. And it goes down to ~0.1 by defining an additional method.]
Re. "SumPerformance.fmaSumOfProducts" vs "SumPerformance.sumOfProducts", I
consistently get better results with {{FMA}}
So I don't think that there is a performance issue with immutability.
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365209#comment-17365209
]
Matt Juntunen commented on NUMBERS-163:
---
I don't get where fma is coming into this. Nothing of the sort is mentioned in
our source algorithms. The name is also incorrect. The {{fusedMultiplyAdd}}
operation is part of the IEEE 754 standard and is definitely not what is
implemented here. In addition, this design has performance implications,
especially for simple addition (see below comparison with the implementation in
my draft PR).
||Benchmark||(c)||(size)||Mode||Cnt||Score||Error||Units||
|SumPerformance.fmaSum|1e20|1000|avgt|5|58292.678|± 7177.043|ns/op|
|SumPerformance.fmaSumOfProducts|1e20|1000|avgt|5|37880.075|± 1680.896|ns/op|
|SumPerformance.sum|1e20|1000|avgt|5|16214.321|± 159.853|ns/op|
|SumPerformance.sumOfProducts|1e20|1000|avgt|5|30733.531|± 330.481|ns/op|
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17365006#comment-17365006
]
Gilles Sadowski commented on NUMBERS-163:
-
Attached
* "FMA.java" (additional factory method)
* "Sum.java"
To prevent API bloat in the upcoming release, we should remove the
{{LinearCombination}} and {{Summation}} classes given that they are syntactic
sugar for the more versatile {{FMA}} class (name TBD if "FMA" is confusing).
I wouldn't add {{Sum}} for the same reason (and because of its "mixed bag"
feeling of addition and product).
Those now seem fairly application-dependent. E.g. one may need
{code:java}
public double linearCombination(double[] a, double[] b) { /* ... */ }
{code}
while another would rather have
{code:java}
public double scalarProduct(Vector3D a, Vector3D b) { /* ... */ }
{code}
There are no failures with {{SumTest}} (using {{Sum}} as implemented in the
attached file); but I didn't check that all cases were covered by that test
suite. IOW, if you agree with the above, a review of {{FMA}} is necessary and a
test suite yet to be written...
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364634#comment-17364634
]
Gilles Sadowski commented on NUMBERS-163:
-
I've attached files "FMA.java" and "Sum.java.patch".
It should clarify that {{Sum}} (and {{LinearCombination}} and {{Summation}})
are built upon {{FMA}}.
The unit tests in "SumTest.java" still pass after applying the patch.
{{FMA}} is thread-safe because it is immutable.
> 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.patch
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364471#comment-17364471
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. I picture fma and the dot2s/sum2s algorithms that we use for
LinearCombination and Summation as separate but complementary functions. FMA is
a single, well-defined operation that produces a highly accurate double value
from 3 inputs.
It seems that there is a misunderstanding: I was considering the name "FMA" as
an abstraction for {{a . b + c}} where {{a}}, {{b}} and {{c}} are *reals*. If
the values are {{double}} values, it could be implemented with {{Math.fma}}
(without loss of accuracy IIUC) or with a plain {{a * b + c}}, or with
something in-between like the algorithms which Alex and you had been testing.
Both the {{LinearCombination}} (abstraction of a sum of products) and the
{{Summation}} (abstraction of a sum) can be defined in terms of the {{FMA}}
abstraction. My question was about whether the respective current
_implementations_ of {{LinearCombination}} and {{Summation}} (or the new
{{Sum}}) could achieve better accuracy than calls to {{FMA}} (as I've
illustrated in the previous comment).
bq. draft PR containing the {{Sum}} class
If there is
{code}
public static Sum of(final double a, final double b) {
return new Sum(a).add(b);
}
{code}
and
{code}
public Sum add(final double t) {
final double newSum = sum + t;
comp += ExtendedPrecision.twoSumLow(sum, t, newSum);
sum = newSum;
return this;
}
{code}
why provide
{code}
public static Sum of(final double a, final double b, final double c) {
return new Sum(a)
.add(b)
.add(c);
}
{code}
?
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364398#comment-17364398
]
Matt Juntunen commented on NUMBERS-163:
---
bq. With the above API, is it possible to implement the combined functionality
of LinearCombination and Summation, with the same accuracy?
I picture {{fma}} and the dot2s/sum2s algorithms that we use for
{{LinearCombination}} and {{Summation}} as separate but complementary
functions. {{FMA}} is a single, well-defined operation that produces a highly
accurate double value from 3 inputs. Any computed round off errors are lost at
the end of the computation when the high precision result is converted back to
a double. In contrast, the dot2s/sum2s algorithms accept any number of inputs
and propagate round-off errors throughout the entire computation. So, I do not
see {{fma}} playing a role in the changes discussed here.
I've created a [draft PR|https://github.com/apache/commons-numbers/pull/96]
containing the {{Sum}} class I outlined earlier. I believe the class itself is
complete. I just need to write/update the unit tests and add performance
benchmarks. Please let me know what you think.
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17364188#comment-17364188
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. FMA is a lot more complicated to implement than the summation performed in
LinearCombination.
>From a design (API/implementation) POV, and following up on Matt's proposal,
>could we provide a class that mimics FMA usage (even if not all its
>requirements)?
{code}
public class FMA implements DoubleSupplier {
// ... state?
private FMA(double m1, double m2, double a) {
// ...
}
public FMA.of(double m1, double m2, double a) {
return new FMA(m1, m2, a);
}
public FMA.of(double m1, double m2, FMA other) {
final double a = ...
return new FMA(m1, m2, a);
}
// To allow usage in a collector.
public FMA fma(FMA other) {
// ... ?
}
@Override
public double getAsDouble() {
// The equivalent of Math.fma(m1, m2, a).
return ...
}
}
{code}
With the above API, is it possible to implement the combined functionality of
{{LinearCombination}} and {{Summation}}, with the same accuracy?
>From a usage POV,
{code}
LinearCombination.of(a1, v1, a2, v2);
{code}
would be replaced with
{code}
FMA.of(a1, v1, FMA.of(a2, v2, 0));
{code}
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363980#comment-17363980
]
Alex Herbert commented on NUMBERS-163:
--
{quote}Isn't this "FuseMultiplyAdd"?
{quote}
Not quite. LinearCombination computes the double length product of two
arguments. The higher and lower parts of the 106-bit mantissa of the result.
The high part is the standard product and the lower part is the bits lost
during rounding. LinearCombination then sums the standard products and during
this summation computes the round-off and sums them separately, along with the
lower parts of each product. This is not exact.
For FMA the second addition argument has to be added to the lower part first,
and the intermediate result added to the higher part. The bits lost to rounding
in the first addition have to be carried forward to ensure exact rounding. The
operation has to avoid intermediate overflow by using scaling:
{code:java}
double x = Double.MAX_VALUE;
double y = Math.fma(x, 2, -x);
assert x == y;
{code}
x should not be infinity.
All this means that FMA is a lot more complicated to implement than the
summation performed in LinearCombination. The gain may be a single ULP of
precision for the result, and overflow protection.
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363917#comment-17363917
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. running sum of terms, with some single terms and some products
Isn't this "FuseMultiplyAdd"?
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363526#comment-17363526
]
Matt Juntunen commented on NUMBERS-163:
---
I've been thinking about this more and it seems to me that if we go the
instance route with {{LinearCombination}} and {{Summation}}, we could combine
them into a single {{Sum}} class. The class would represent a running sum of
terms, with some single terms and some products. I'm picturing something like
this:
{code:java}
// compute a + b + c
Sum s = Sum.create();
s.add(a)
.add(b)
.add(c);
double result = s.getAsDouble();
// compute a0*b0 + a1*b1 + a2*b2
Sum s = Sum.create();
s.addProduct(a0, b0)
.addProduct(a1, b1)
.addProduct(a2, b2);
double result = s.getAsDouble();
// compute a + b*c
double result = Sum.create().add(a).addProduct(b, c).getAsDouble();
// Implement DoubleConsumer for use with DoubleStream.
// compute sum of stream elements
Sum s = Sum.create();
doubleStream.forEach(s);
double result = s.getAsDouble();
// Provide convenience factory methods for supplying multiple values at once.
// compute a + b + c
Sum s = Sum.of(a, b, c);
double result = s.getAsDouble();
// compute a0*b0 + a1*b1
Sum s = Sum.linearCombination(a0, b0, a1, b1);
double result = s.getAsDouble();
// Perhaps provide convenience static methods for directly computing
// the double result. These could be implemented internally using the
// instance methods.
// compute a + b + c
double result = Sum.value(a, b, c);
// compute a0*b0 + a1*b1
double result = Sum.linearCombinationValue(a0, b0, a1, b1);
{code}
Thoughts?
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363317#comment-17363317
]
Matt Juntunen commented on NUMBERS-163:
---
Ok, I think I see what you're doing here. We don't need the accumulator class
because {{LinearCombination}} can be the accumulator itself. A few questions on
the API:
- Are you picturing {{LinearCombination}} being mutable?
- If we go this route with {{LinearCombination}}, would it make sense to try
something similar with {{Norm}} for consistency?
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363285#comment-17363285
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. Can you flesh out the API you're proposing?
In part, it's the same as in you PR, minus the {{Accumulator}} class:
{code}
LinearCombination acc = LinearCombination.of(0, 0, 0, 0)
.add(u1, v1)
.add(u2, v2)
.add(u3, v3)
.add(u4, v4);
{code}
We could also provide
{code}
LinearCombination s = LinearCombination.of(u1, v1, u2, v2);
s = s.add(LinearCombination.of(u3, v3, u4, v4));
{code}
> 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
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17363020#comment-17363020
]
Matt Juntunen commented on NUMBERS-163:
---
bq. ... we should perhaps encapsulate the (extended precision) "implementation
details" in a SumVector3D class
+1. That's the plan :-)
bq. To add it to another instance; thus providing the accumulation
functionality (without an additional name).
Perhaps I'm not seeing the full picture here. Can you flesh out the API you're
proposing?
> 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
> Time Spent: 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362985#comment-17362985
]
Gilles Sadowski commented on NUMBERS-163:
-
I would have suggested the {{Accumulator}} inner class myself, on the a priori
that the alternative was less efficient. I recall having suggested inner
classes where [~mattjuntunen] didn't want them. ;)
But now it seems that such a class could just be redundant.
{quote}You can have different implementations of LinearCombination.
{quote}
Yes (I seem to recall I raised that point somewhere else).
By maintaining the "static" API, we prevent the flexibility (IIUC).
{quote}What would one do with an instance of LinearCombination besides get the
double value from it? In that case, why even have an instance at all?
{quote}
To add it to another instance; thus providing the accumulation functionality
(without an additional name).
Note: An accumulator class may still be needed in the context of a
[collector|https://docs.oracle.com/javase/8/docs/api/java/util/stream/Collector.html]
but it could perhaps be private (?).
> 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
> Time Spent: 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362908#comment-17362908
]
Alex Herbert commented on NUMBERS-163:
--
{quote}There is (surprisingly perhaps) no performance loss (on the contrary,
for the simple cases).
{quote}
Thanks for testing. I have no other issues with the builder type API and that
is more flexible. Maintaining the static methods when performance is no
different is not necessary.
{quote}As far as making LinearCombination itself implement DoubleSupplier, I do
not see the utility.
{quote}
You can have different implementations of LinearCombination. dot2s is a 2-fold
precision algorithm. The generic extension is the dotK family for k-fold
precision. There is also the unlimited precision method (within the bounds of
the range of a double).
But this would also work for the accumulator class you are describing. The
accumulator can have sub-class implementations.
The algorithm should be specified in the constructor:
{code:java}
double x1 = LinearCombination.of(LinearCombination.DOT_2S)
.add(1e300, 1)
.add(1e100, 1)
.add(1, 1)
.add(-1e300, 1)
.add(-1e100, 1)
.getAsDouble();
assert x1 == 1;
{code}
I think this fails for the dot2s algorithm. But it would work for DOT_3
algorithm.
This would allow code to switch the accuracy by just putting in a different
enum specified algorithm.
> 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
> Time Spent: 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362906#comment-17362906
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}[here|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L173]
[...] replace [...] {{Vector3D}} accumulator [...] with extended precision
[...]
{quote}
As this is (conceptually) a ({{Vector3D}}) addition (to be carried by 3
{{Summation}} instances), we should perhaps encapsulate the (extended
precision) "implementation details" in a {{SumVector3D}} class (name TBD):
{code:java}
public class SumVector3D {
private Summation x = Summation.zero();
private Summation y = Summation.zero();
private Summation z = Summation.zero();
public SumVector3D() {}
public void add(Vector3D v) {
x = Summation.add(v.getX());
// ...
}
public Vector3D get() {
return Vector3D.of(x.getAsDouble(), y.getAsDouble(), z.getAsDouble());
}
}
{code}
(Unrelated) nit: Variable
[{{centroidVector}}|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L175]
should be declared inside the loop and "final".
> 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
> Time Spent: 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362900#comment-17362900
]
Matt Juntunen commented on NUMBERS-163:
---
I've made a PR with the changes I was picturing here:
[https://github.com/apache/commons-numbers/pull/95]. Please let me know what
you think.
bq. Isn't there a possible loss (depending on the order of accumulation)?
Yes, but the static methods have the exact same issue. The dot2s add sum2s
algorithms that we are using are designed to reduce this loss as much as
possible. The accumulator classes simply unroll the algorithms and give the
caller control over when and how the inputs are added.
As far as making {{LinearCombination}} itself implement {{DoubleSupplier}}, I
do not see the utility. What would one do with an instance of
{{LinearCombination}} besides get the {{double}} value from it? In that case,
why even have an instance at all?
> 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
> Time Spent: 20m
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362671#comment-17362671
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. performance impact should be checked.
I've adapted {{LinearCombinationPerformance.java}}. E.g.
{code}
@Benchmark
public void twoDStatic(Factors factors, Blackhole bh) {
for (int i = 0; i < factors.getSize(); i++) {
final double[] a = factors.getA(i);
final double[] b = factors.getB(i);
bh.consume(LinearCombination.value(a[0], b[0], a[1], b[1]));
}
}
@Benchmark
public void twoDInstance(Factors factors, Blackhole bh) {
for (int i = 0; i < factors.getSize(); i++) {
final double[] a = factors.getA(i);
final double[] b = factors.getB(i);
bh.consume(LinearCombinationInstance.of(a[0], b[0], a[1],
b[1]).getAsDouble());
}
}
{code}
Benchmark (c) (length) (size) Mode Cnt Score Error Units
StaticVsInstancePerfTest.fourDInstance 1e20 N/A 1000 avgt 5 31512.374 ± 62.728
ns/op
StaticVsInstancePerfTest.fourDStatic 1e20 N/A 1000 avgt 5 31614.226 ± 9.056
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 2 1000 avgt 5 20752.786 ± 133.433
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 3 1000 avgt 5 27923.824 ± 64.643 ns/op
StaticVsInstancePerfTest.nDInstance 1e20 4 1000 avgt 5 35315.521 ± 63.024 ns/op
StaticVsInstancePerfTest.nDInstance 1e20 8 1000 avgt 5 64917.926 ± 7542.116
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 16 1000 avgt 5 119683.016 ± 108.595
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 32 1000 avgt 5 235226.364 ± 82.889
ns/op
StaticVsInstancePerfTest.nDInstance 1e20 64 1000 avgt 5 454769.978 ± 4762.963
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 2 1000 avgt 5 20615.813 ± 55.909 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 3 1000 avgt 5 27732.619 ± 11.160 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 4 1000 avgt 5 35240.831 ± 32.135 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 8 1000 avgt 5 64602.804 ± 7745.583 ns/op
StaticVsInstancePerfTest.nDStatic 1e20 16 1000 avgt 5 119715.009 ± 116.848
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 32 1000 avgt 5 235239.053 ± 1996.640
ns/op
StaticVsInstancePerfTest.nDStatic 1e20 64 1000 avgt 5 453945.774 ± 312.060
ns/op
StaticVsInstancePerfTest.threeDInstance 1e20 N/A 1000 avgt 5 24793.222 ±
30.967 ns/op
StaticVsInstancePerfTest.threeDStatic 1e20 N/A 1000 avgt 5 25110.065 ± 162.728
ns/op
StaticVsInstancePerfTest.twoDInstance 1e20 N/A 1000 avgt 5 18087.386 ± 6.255
ns/op
StaticVsInstancePerfTest.twoDStatic 1e20 N/A 1000 avgt 5 18447.334 ± 15.277
ns/op
bq. There is no need to instantiate an object to perform the computation in the
simple cases.
There is (surprisingly perhaps) no performance loss (on the contrary, for the
simple cases).
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362563#comment-17362563
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}it accumulates them
{quote}
Isn't there a possible loss (depending on the order of accumulation)?
{quote}LinearCombination would be similar.
{quote}
It's indeed what I had understood; hence my point that the additional class is
not strictly necessary (unless the performance cost of creating an instance
that stores two {{double}} values is significant).
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362559#comment-17362559
]
Matt Juntunen commented on NUMBERS-163:
---
{{LinearCombination}} would be similar.
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362558#comment-17362558
]
Matt Juntunen commented on NUMBERS-163:
---
No, it accumulates them. The basic structure should look like below. I have a
specific idea for the API, I just haven't had time yet to write it.
{code:java}
static class Accumulator {
private double sum;
private double comp;
public Accumulator add(double d) {
double t = sum + d;
comp += ExtendedPrecision.twoSumLow();
sum = t;
return this;
}
public double get() {
return summationResult(sum, comp);
}
}
{code}
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362557#comment-17362557
]
Gilles Sadowski commented on NUMBERS-163:
-
Do you actually mean that {{Accumulator}} will store the coordinates (in an
array?) and perform the {{Summation}} in one go when {{get()}} is called?
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362556#comment-17362556
]
Gilles Sadowski commented on NUMBERS-163:
-
{quote}no need to instantiate an object to perform the computation in the
simple cases.
{quote}
Sure; performance impact should be checked.
{quote}I don't see how this addresses my use cases.
{quote}
I showed extended usage of {{LinearCombination}} for which I understood that
intermediate values should be kept (i.e. "p + s" should only be computed when
the "double" result is requested). I didn't look at {{Summation}}.
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362553#comment-17362553
]
Matt Juntunen commented on NUMBERS-163:
---
I agree that we should keep the static methods. There is no need to instantiate
an object to perform the computation in the simple cases.
Additionally, I don't see how this addresses my use cases. Specifically, I want
to replace the use of {{double}} accumulators
[here|https://github.com/apache/commons-geometry/blob/master/commons-geometry-spherical/src/main/java/org/apache/commons/geometry/spherical/twod/RegionBSPTree2S.java#L173]
(technically a {{Vector3D}} accumulator) with extended precision accumulators.
The result would look something like this:
{code:java}
Summation.Accumulator xacc = Summation.accumulator();
Summation.Accumulator yacc = Summation.accumulator();
Summation.Accumulator zacc = Summation.accumulator();
for (final ConvexArea2S area : areas) {
// ...
xacc.add(centroidVector.getX());
yacc.add(centroidVector.getY());
zacc.add(centroidVector.getZ());
}
Vector3D centroidVectorSum = Vector3D.of(
xacc.get(),
yacc.get(),
zacc.get());
{code}
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362551#comment-17362551
]
Gilles Sadowski commented on NUMBERS-163:
-
bq. I don't think the static method should be replaced.
What's the problem with writing
{code}
double r = LinearCombination.of(a, b, c, d).getAsDouble();
{code}
in place of
{code}
double = LinearCombination.value(a, b, c, d);
{code}
?
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362541#comment-17362541
]
Alex Herbert commented on NUMBERS-163:
--
I don't think the static method should be replaced. They can be supplemented by
a builder type pattern. I see use cases for both, and advantages to keeping
both.
> 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
>
> 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)
[jira] [Commented] (NUMBERS-163) Summation and LinearCombination Accumulators
[
https://issues.apache.org/jira/browse/NUMBERS-163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17362477#comment-17362477
]
Gilles Sadowski commented on NUMBERS-163:
-
{code}
public class LinearCombination implements DoubleSupplier { /* ... */ }
LinearCombination t = LinearCombination.of(a1, y1, b1, z1);
LinearCombination u = LinearCombination.of(t, b2, z2);
double result = u.get();
{code}
> 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
>
> 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)
