[ 
https://issues.apache.org/jira/browse/OFBIZ-9567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16121428#comment-16121428
 ] 

Jacques Le Roux edited comment on OFBIZ-9567 at 8/10/17 10:26 AM:
------------------------------------------------------------------

Thanks Dennis,

I see your point. I think we already had a discussion and a consensus on that 
because we follow 
*[Java|http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#331]*
 [Coding 
Conventions|https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions].
 So I'll not start a new discussion about that and will simply keep the 
parentheses.

What makes things blurry to me is that APL's interpretation works like function 
composition. So in APL you would have to write it 
{{(10 * 2) + 50 * (1 - 0.5)}}. 
Else; w/o 1st parentheses, you would get 270 instead of 45. And believe me 
after 20 years of such habit it's hard to read it another way, it's also very 
logical (function composition) :D





was (Author: jacques.le.roux):
Thanks Dennis,

I see your point. I think we already had a discussion and a consensus on that 
because we follow 
*[Java|http://www.oracle.com/technetwork/java/javase/documentation/codeconventions-137265.html#331]*
 [Coding 
Conventions|https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Conventions].
 So I'll not start a new discussion about that and will simply keep the 
parentheses.

What makes things blurry to me is that APL's interpretation works like function 
composition. So in APL you would have to write it 
{{(10 * 2) + 50 * (1 - 0.5)}}. 
Else; w/o 1st parentheses, you would get 270. And believe me after 20 years of 
such habit it's hard to read it another way, it's also very logical (function 
composition) :D




> [FB] Package org.apache.ofbiz.base.metrics
> ------------------------------------------
>
>                 Key: OFBIZ-9567
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-9567
>             Project: OFBiz
>          Issue Type: Sub-task
>          Components: base
>    Affects Versions: Trunk
>            Reporter: Dennis Balkir
>            Assignee: Jacques Le Roux
>            Priority: Minor
>         Attachments: OFBIZ-9567_org.apache.ofbiz.base.metrics_bugfixes.patch
>
>
> - MetricsFactory.java:236, ICAST_IDIV_CAST_TO_DOUBLE
> ICAST: Integral division result cast to double or float in 
> org.apache.ofbiz.base.metrics.MetricsFactory$MetricsImpl.recordServiceRate(int,
>  long)
> This code casts the result of an integral division (e.g., int or long 
> division) operation to double or float. Doing division on integers truncates 
> the result to the integer value closest to zero. The fact that the result was 
> cast to double suggests that this precision should have been retained. What 
> was probably meant was to cast one or both of the operands to double before 
> performing the division. Here is an example:
> int x = 2;
> int y = 5;
> // Wrong: yields result 0.0
> double value1 =  x / y;
> // Right: yields result 0.4
> double value2 =  x / (double) y;



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to