You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Henri Biestro (JIRA)" <ji...@apache.org> on 2015/07/23 17:50:04 UTC

[jira] [Resolved] (JEXL-156) BigDecimal does not take precedence in arithmetic operations

     [ https://issues.apache.org/jira/browse/JEXL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Henri Biestro resolved JEXL-156.
--------------------------------
       Resolution: Fixed
         Assignee: Henri Biestro
    Fix Version/s: 3.0

Not a problem in 3.0 and no 2.x is likely to be ever produced.

> BigDecimal does not take precedence in arithmetic operations
> ------------------------------------------------------------
>
>                 Key: JEXL-156
>                 URL: https://issues.apache.org/jira/browse/JEXL-156
>             Project: Commons JEXL
>          Issue Type: Bug
>    Affects Versions: 2.1.1
>            Reporter: Waldemar Horbowicz
>            Assignee: Henri Biestro
>             Fix For: 3.0
>
>
> According to javadoc on org.apache.commons.jexl2.JexlArithmetic for arithmetic operations when either operand is BigDecimal both are coerced to BigDecimal to perform operation.
> During formula evaluation however operation is calculated on BigDecimals only if both operands are BigDecimal. If one of them is float(double) calculations are done on Double.
> Example:
> Given method
> Object evaluate(String formula) {
> return new JexlEngine().createExpression().evaluate(new MapContext()) ;
> }
> evaluate("463.0B * 0.1") returns 46.300000000000004 of type java.lang.Double
> while
> evaluate("463.0B * 0.1B") returns 46.30 of type java.math.BigDecimal
> From my perspective this is a bug as operation is performed on type with less precise result causing as in above example floating point representation error for quite trivial calculation.
> While reporting this bug I also noticed similar downgrade for operations on BigDecimal and integral values :
> evaluate("463.0B * 1") returns java.lang.Integer
> evaluate("463.0B * 1L") returns java.lang.Long
> while
> evaluate("463.0 * 1") returns java.lang.Double
> evaluate("463.0 * 1L") returns java.lang.Double
> Fortunately for results that cannot be expressed as integral value BigDecimal is returned so precision of calculations is not lost.
> From what I have seen in sources this issue should not occur in JEXL3 however it is not yet released.
> I'm willing to contribute a patch for that If this would result in release of JEXL2 with a fix in the near future. Would that be possible?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)