Hi, guys: I am using Drools 4.0.7. I find a strange behavior. When my LHS is "Message( varDouble == 99.9 )" and "varDouble" equals "new Double(99.9)", the condition is true. But when my LHS is "Message( types.doubleType == 99.9 )" and the "doubleType" field is also equal to "new Double(99.9)", the condition is false. I debug the code, and find that: When the LHS is "Message( varDouble == 99.9 )", the logic will handle the literal 99.9 as *Double.valueOf( “99.9” )*, and the comparison is between *(new Double(99.9)).doubleValue(*) and *Double.valueOf( “99.9” ).doubleValue()*, When the LHS is "Message( types.doubleType == 99.9 )", the logic is different from above. The comparison is between *new BigDecimal((Double) 99.9, MathContext.DECIMAL64)* (which double value is 99.90000000000001) and *new BigDecimal(“99.9”, MathContext.DECIMAL64)* (which double value is 99.9). I think we need make things consistent. "varDouble" and "types.doubleType" are of the same type and value. It doesn't make sense to have different behavior just because of one field is nesting while the other is not. I know Drools is using MVEL to evaluate the condition. But I am not sure it is a MVEL bug or Drools uses MVEL wrong. It will be much appreciated if you can give me any comments!

Whether the comparison is precarious or not should depend on how you handle the literal. If you handle 99.9 as BigDecimal("99.9") which precision can be controlled, you can trust the comparison. Anyway, since it has different behavior for these two cases, it should be a bug, right? I just want to know it is Drools' bug or MVEL's... If it is MVEL's, I may need ask for MVEL guys' help...

On 26 March 2012 19:50, Wolfgang Laun <wolfgang.laun(a)gmail.com <mailto:wolfgang.laun@gmail.com>> wrote: 4.0.7 is rather old. 5.1.1 and later do not exhibit this behaviour. However, it should be noted that comparing double values using == is a precarious approach. For instance, 99.9 (the mathematical number) cannot be represented as a double machine number. Hence, you do not truly test for equality with that number, just with its approximation by some machine number. -W On 26/03/2012, Zeke <xanadu860122(a)gmail.com <mailto:xanadu860122@gmail.com>> wrote: > Hi, guys: > I am using Drools 4.0.7. I find a strange behavior. When my LHS is > "Message( varDouble == 99.9 )" and "varDouble" equals "new Double(99.9)", > the condition is true. But when my LHS is "Message( types.doubleType == > 99.9 )" and the "doubleType" field is also equal to "new Double(99.9)", the > condition is false. I debug the code, and find that: > > When the LHS is "Message( varDouble == 99.9 )", the logic will handle the > literal 99.9 as *Double.valueOf( "99.9" )*, and the comparison is between > *(new > Double(99.9)).doubleValue(*) and *Double.valueOf( "99.9" ).doubleValue()*, > When the LHS is "Message( types.doubleType == 99.9 )", the logic is > different from above. The comparison is between *new BigDecimal((Double) > 99.9, MathContext.DECIMAL64)* (which double value is 99.90000000000001) and > *new BigDecimal("99.9", MathContext.DECIMAL64)* (which double value is > 99.9). > > I think we need make things consistent. "varDouble" and > "types.doubleType" are of the same type and value. It doesn't make sense to > have different behavior just because of one field is nesting while the > other is not. I know Drools is using MVEL to evaluate the condition. But I > am not sure it is a MVEL bug or Drools uses MVEL wrong. It will be much > appreciated if you can give me any comments! > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

On 27/03/2012, Zeke <xanadu860122(a)gmail.com&gt; wrote: > Whether the comparison is precarious or not should depend on how you handle > the literal. If you handle 99.9 as BigDecimal("99.9") which precision can > be controlled, you can trust the comparison. > Wait a sec: primarily, you are testing a double, and this is where some unavoidable imprecision is introduced. These are some doubles close to 99.9: a 99.899999999999990000 0x1.8f99999999999p6 b 99.900000000000000000 0x1.8f9999999999ap6 c 99.900000000000020000 0x1.8f9999999999bp6 a < 99.9 is the true value truncated, b > 99.9 is rounded (the next binary digit being 1). There just isn't a double == 99.9. (Don't be confused by b's printed value.) The BigDecimal value 99.90000000000001 you have observed is due to rounding the result of new BigDecimal( (double)99.9 ), i.e. 99.900000000000005684341886080801486968994140625 It's easy to see that a better value is obtained by using a String value: new BigDecimal( "99.9" ) but I don't know whether your Drools version would let you write doubleValue == "99.9". If you want/have to stick with 4.x you might use public static final doubles defined in some Java class instead of the magic 99.9. This should avoid the sidestep into BigDecimal and the ensuing conversion confusion. -W _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

Thanks for all your replies. I'm sorry for bring up this issue again. I tried the Drools 5.3.0.Final. For float and double type, I think current behavior is what I need. But for BigDecimal type, when my condition is "bd == 99.9" ("bd" equals new BigDecimal("99.9")), the condition is false. But if I add quotes to the literal as bd == "99.9", the condition will be true. Is this behavior is designed to be so? It seems 99.9 will be considered as double value, while "99.9" will be considered as a BigDecimal value. Thanks!