Thread overview | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
February 25, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 adamsibson@hotmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P1 |P3 -- |
February 25, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 Cédric Picard <cpicard@openmailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cpicard@openmailbox.org --- Comment #1 from Cédric Picard <cpicard@openmailbox.org> --- I would rather have a comment in the doc saying "Pairwise summation is slower than naive one, for performance use reduce!((a, b) => a+b)", adding a new function for that seems overkill. -- |
February 25, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 --- Comment #2 from adamsibson@hotmail.com --- (In reply to Cédric Picard from comment #1) > I would rather have a comment in the doc saying "Pairwise summation is > slower than naive one, for performance use reduce!((a, b) => a+b)", adding a > new function for that seems overkill. Why? There seems to be a strong resistance to convenience functions in the library, one that is unnecessary. There is a significant difference between arr.sum and arr.reduce!((a, b) => a + b) in usability. In writing this post I initially forgot I have do put a, b in an additional set of brackets, it's complicated and not particularly user-friendly. -- |
February 26, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 --- Comment #3 from Cédric Picard <cpicard@openmailbox.org> --- (In reply to adamsibson from comment #2) > (In reply to Cédric Picard from comment #1) > > I would rather have a comment in the doc saying "Pairwise summation is > > slower than naive one, for performance use reduce!((a, b) => a+b)", adding a > > new function for that seems overkill. > > Why? There seems to be a strong resistance to convenience functions in the library, one that is unnecessary. There is a significant difference between arr.sum and arr.reduce!((a, b) => a + b) in usability. In writing this post I initially forgot I have do put a, b in an additional set of brackets, it's complicated and not particularly user-friendly. I don't feel like I'm blindly refusing something because it's a convenience function. The thing is, how do you want to do it? First of all, for comparison, what exists today: [1, 2, 3].reduce!"a+b"; // Not pairwise, considered bad code... meh. [1, 2, 3].reduce!((a, b) => a+b); // Not pairwise [1, 2, 3].reduce!sum; // Pairwise Add a "sum" overload that takes a range? It would be feasible but ambiguous: [1, 2, 3].sum // Not pairwise [1, 2, 3].reduce!sum // Pairwise, non obvious at all Add a new function? "sum" is already taken and changing it would only break code uselessly (and it would be hard to explain that "sum" now means something slightly different and that the old meaning is now sumPairwise) so you'd have to add something like "simpleSum"... Feasible but not so convenient for a convenience function. Add a flag in parameters that defaults to not-pairwise? Good for the default but really complicated for pairwise summation: sum(1, 2); [1, 2, 3].reduce!sum; sum(1, 2, summation.pairwise); [1, 2, 3].reduce!((a, b) => sum(a, b, summation.pairwise)); Add a compile-time flag that defaults to not-pairwise? Not satisfying IMHO. sum(1, 2); [1, 2, 3].reduce!sum; sum!(summation.pairwise)(1, 2); [1, 2, 3].reduce!(sum!(summation.pairwise)); Quite frankly, given the other choices, I think the default isn't that bad. Otherwise my preference would go to the overload but I'm sure it would be refused for being too ambiguous. So this is a real question: how would you like to see it done? -- |
March 09, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 John Colvin <john.loughran.colvin@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |john.loughran.colvin@gmail. | |com --- Comment #4 from John Colvin <john.loughran.colvin@gmail.com> --- https://github.com/D-Programming-Language/phobos/pull/4069 -- |
March 09, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 --- Comment #5 from adamsibson@hotmail.com --- >John Colvin 2016-03-09 15:08:05 UTC https://github.com/D-Programming-Language/phobos/pull/4069 Thanks John! Out of interest what is the impact on accuracy between the two methods? -- |
April 05, 2016 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 Jack Stouffer <jack@jackstouffer.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |performance CC| |jack@jackstouffer.com -- |
December 17, 2022 [Issue 15722] std.algorithm sum should favour speed | ||||
---|---|---|---|---|
| ||||
https://issues.dlang.org/show_bug.cgi?id=15722 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P3 |P4 -- |
Copyright © 1999-2021 by the D Language Foundation