[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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&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)
[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&focusedCommentId=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&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)
[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&focusedCommentId=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&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 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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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&focusedCommentId=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)