Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Message-ID: <1154989109.1250954834930.JavaMail.jira@brutus>
Date: Sat, 22 Aug 2009 08:27:14 -0700 (PDT)
From: "Henri Biestro (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Subject: [jira] Commented: (JEXL-87) Inconsistent behaviour of arithmetical
 operations
In-Reply-To: <867315699.1250765235298.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/JEXL-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12746469#action_12746469 ] 

Henri Biestro commented on JEXL-87:
-----------------------------------

About literals, it could be convenient & easy to add syntactic notations for the different literal types :
123L for (Long) 123
12.3d for Double
12.3D for BigDecimal (capital 'D'))
123I for BigInteger (capital 'I')

On the arithmetic itself, it might be easier on the user-end to follow more common rules about types by avoiding automatic conversion & add coercion operators (or functions in the global namespace) - applying the "lesser surprise principle". 

The "more common rules" would be composition rules based on a usual datatype ordering:
String > BigDecimal > Double > BigInteger > Long > Character > Int > Short  > Byte

And all operations would do:
x o y -> Compose(type(x), type(y)).o (x,y)
With compose being:
Compose(Double, BigInteger) -> BigDecimal
Composte(t1, t2) -> Datatype.Max(t1, t2) 
And each datatype implement its own code for each operation.

Since arithmetic operations could then overflow, we'd introduce explicit coercions to let users circumvent these cases.

I however suspect such a scheme would be further away from the JSF/JSP EL spec.
WDYT ?
 

> Inconsistent behaviour of arithmetical operations
> -------------------------------------------------
>
>                 Key: JEXL-87
>                 URL: https://issues.apache.org/jira/browse/JEXL-87
>             Project: Commons JEXL
>          Issue Type: Bug
>            Reporter: Sebb
>             Fix For: 2.0
>
>
> BigInteger(7) / BigInteger(2) == 3
> whereas
> BigDecimal(7) / BigDecimal(2) == 4, because the result is rounded up.
> I would expect the results to be the same.
> Rather worse is:
> BigDecimal(7) % BigDecimal(2) == -1
> which makes no sense at all.
> Seems to me that the arithmetic "rules" need revisiting and rationalising - for example why should Integer be treated as double?
> At present literal numbers are treated as Integer or Float; there's no option to generate Long or Double literals.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.