Currently, when summing longs in an accumulate, we get something like this:
This has 3 problems:
- Loss of precision: the long sum `1881617265586265321L` will incorrectly return `1.88161726558626534E18`, so `13` too much! The BigDecimal sum of `0.09` and `0.01` will also be incorrect.
- Loss of performance: Summing with a Double total is significantly slower than summing with a Long total or an Integer total.
- Example complexity (minor, not all of us agree on this argument): the use of `Number` is an abstraction that doesn't bring any value to the use case. It's worthless complexity.
Solution proposal A) for 7.0 as discussed with Mario:
Based on the argument type to the sum function, the compiler selects a different sum function implementation. This is similar to java overloading mechanism, where `System.out.println(1)` selects a different method implementation than `System.out.println(2.0)`.
and also support sum(Integer) and sum(BigInteger).
If this works well, we can consider it for other functions as well in a different jira issue.
Special case 1: sum(Number) should default to sum(Double) for backwards compatibility.
Not-so-special case 2: to sum integers into a long total, the user should just use: