[ https://issues.jboss.org/browse/DROOLS-1175?page=com.atlassian.jira.plugi... ] Geoffrey De Smet updated DROOLS-1175: ------------------------------------- Description: Currently, when summing longs in an accumulate, we get something like this: {code} when ... $t : Number(...) from accumulate(..., sum($p.getLongWeight())) then scoreHolder.addHard($t.longValue()); {code} 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)`. Support sum(Long): {code} when ... $t : Long(...) from accumulate(..., sum($p.getLongWeight())) then scoreHolder.addHard($t); {code} and sum(BigDecimal): {code} when ... $t : BigDecimal(...) from accumulate(..., sum($p.getBigDecimalWeight())) then scoreHolder.addHard($t); {code} 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. {code} when ... $t : Number(...) from accumulate(..., sum($p.getNumberWeight())) then scoreHolder.addHard($t.doubleValue()); {code} Not-so-special case 2: the sum integers into a long total, the user should just use: {code} $t : Long(...) from accumulate(..., sum((long) $p.getIntWeight())) {code} was: Currently, when summing longs in an accumulate, we get something like this: {code} when ... $t : Number(...) from accumulate(..., sum($p.getLongWeight())) then scoreHolder.addHard($t.longValue()); {code} 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)`. Support sum(Long): {code} when ... $t : Long(...) from accumulate(..., sum($p.getLongWeight())) then scoreHolder.addHard($t); {code} and sum(BigDecimal): {code} when ... $t : BigDecimal(...) from accumulate(..., sum($p.getBigDecimalWeight())) then scoreHolder.addHard($t); {code} 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) {code} when ... $t : Number(...) from accumulate(..., sum($p.getNumberWeight())) then scoreHolder.addHard($t.doubleValue()); {code} Not-so-special case 2: the sum integers into a long total, the user should just use: {code} $t : Long(...) from accumulate(..., sum((long) $p.getIntWeight())) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)