[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet edited comment on DROOLS-315 at 4/3/15 8:23 AM:
-----------------------------------------------------------------
Hey Edson,
What's the status of this issue? Do we have sumInt(), sumLong(), sumBigDecimal() available in Drools?
Or better yet, support for overloaded methods support, so sum(int), sum(long), sum(BigDecimal) just do the right thing (instead of using sum(double)).
was (Author: ge0ffrey):
Edson,
What's the status of this issue? Do we have sumInt(), sumLong(), sumBigDecimal() available yet in Drools?
Or better yet, overloaded methods support, so sum(int), sum(long), sum(BigDecimal) just do the right thing (instead of using sum(double))?
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> {code}
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
{code}
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
{code}
was:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> {code}
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
*Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
was:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> *Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
> Old description:
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
was:
*Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).*
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an *incorrect result* of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Description:
Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
Old description:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
was:
TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
There are 2 ways I see to implement this:
1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
This is not so user-friendly. This is what I 've done in the patch.
2) Support overloading of accumulate functions based on the function arguments.
AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
sum($myInteger)
and bind it to SumIntegerAccumulateFunction,
while binding
sum($myInteger.doubleValue())
to SumDoubleAccumulateFunction.
And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
sum($myString)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> Using a sum(Number) accumulate of these 2 numbers: new BigDecimal("0.01") and new BigDecimal("0.09") give an incorrect result of 0.09999999999999999.
> Support sumBigDecimal(BigDecimal) or better yet sum(BigDecimal).
> Old description:
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet updated DROOLS-315:
------------------------------------
Priority: Critical (was: Minor)
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Critical
> Attachments: JBRULES-1075.patch
>
>
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months
[JBoss JIRA] (DROOLS-315) Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
by Geoffrey De Smet (JIRA)
[ https://issues.jboss.org/browse/DROOLS-315?page=com.atlassian.jira.plugin... ]
Geoffrey De Smet commented on DROOLS-315:
-----------------------------------------
Edson,
What's the status of this issue? Do we have sumInt(), sumLong(), sumBigDecimal() available yet in Drools?
Or better yet, overloaded methods support, so sum(int), sum(long), sum(BigDecimal) just do the right thing (instead of using sum(double))?
> Support overloading of accumulate functions: Add int (or long) based sum's, int based avarage's, etc
> -----------------------------------------------------------------------------------------------------
>
> Key: DROOLS-315
> URL: https://issues.jboss.org/browse/DROOLS-315
> Project: Drools
> Issue Type: Feature Request
> Reporter: Geoffrey De Smet
> Assignee: Edson Tirelli
> Priority: Minor
> Attachments: JBRULES-1075.patch
>
>
> TTP nl10 solver has about a 3% performance increase when switching from sumDouble to sumLong (and possibly a bit more when switching to sumInteger)
> There are 2 ways I see to implement this:
> 1) Force the user to explicitly declare he wants to use an integer based sum and add a sumInteger.
> This is not so user-friendly. This is what I 've done in the patch.
> 2) Support overloading of accumulate functions based on the function arguments.
> AFAIK drl is strongly typed (at least with the java dialect), so it should be theoretically possible for the drl parser to see
> sum($myInteger)
> and bind it to SumIntegerAccumulateFunction,
> while binding
> sum($myInteger.doubleValue())
> to SumDoubleAccumulateFunction.
> And added advantage is that the drl compiler will also mark some bugs as compiler errors. For example
> sum($myString)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 9 months