commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Biestro (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JEXL-87) Inconsistent behaviour of arithmetical operations
Date Sat, 22 Aug 2009 15:27:14 GMT

    [ 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.


Mime
View raw message