First let me tell you that using floats or even doubles for monetary values is a big no-no. You'll run into lots of problems such as sums not being computed correctly, rounding not being made in the right place, and what have you. BigDecimal is an alternative.

Second, permit me to say that asking for some cute "almost equal" operator in Drools is not a good idea. (If it were, many programming languages would provide it - after all, Drools is just another programming language.) For one thing, this "almost equal" depends on too many things a compiler doesn't know about - most importantly the error in the input data and the error accrued in the computation. Also, the interval must be relative to the absolute size of the value (because that's the way real numbers work); this means that comparing 99999999.99 would have to return true for the range 999899999.99 through 999000000.01 - obviously absurd for monetary units.

Not using doubles will avoid users wondering about strange effects. To hide the nastier features of rules from them, you might consider using a Domain Specific Language in your rules.

-W


2009/4/22 Zeke <xanadu860122@gmail.com>
Thanks for your reply, Wolfgang! But I don't think this makes sense. Yes, I know rational numbers has precision. We can not use "==" in Java program to decide equality. But I think when we use Drools, Drools should handle the precision and make "==" works. We may use Drools in our Business product. For example, say, user may set a rule like "SomeProduct.price == 99.9" which is a common use case, right? The user may not know computer very well. He will wonder why this rule wil not satisfy.
I think Drools can do thing in this way, given a precision scope. For example, if the price > 99.989999999 and price < 99.900000001 then let price == 99.9 true.

Thanks
- Zeke

2009/4/21 Wolfgang Laun <wolfgang.laun@gmail.com>
The long answer to your question can be found in http://en.wikipedia.org/wiki/Floating_point.

The short answer is that machine numbers for floats and doubles are approximations to almost all rational numbers, or, if you prefer, fractions. This is because most numbers have infinite binary expansions (such as 1/3 in decimal).

Even when you use "99.9" in one place (a Java program), there's no guarantee that the double produced by the Java compiler is equal to the double resulting from the same literal via Drools' compiler chain (in a DRL file). Conversion between double and float is guaranteed to generate inequality for such numbers.

For your tests you might try a fraction that can be represented accurately, e.g., 0.5 or 0.125.

-W


2009/4/21 Zeke <xanadu860122@gmail.com>
Hi, All:
  My drl file is like below:
  package org.drools.examples;
 
  import org.drools.examples.HelloWorldExample.Message;

  rule "check deep int"
      dialect "java"
      when
          m:Message( sec.fir.d == "99.9" )
      then
          System.out.println( "===check deep double ok===" );
  end
 
  I find that "==" operator does not work well on double and float type. This condition can not be satisfied. If I change the condition to sec.fir.d < "100" or sec.fir.d > "99.8", it works well. Is it a bug?

  I attach my test code. And I add below jars into classpath:
  antlr-runtime-3.0.jar
  core-3.2.3.v_686_R32x.jar
  drools-compiler-4.0.7.jar
  drools-core-4.0.7.jar
  drools-decisiontables-4.0.7.jar
  drools-jsr94-4.0.7.jar
  janino-2.5.10.jar
  jsr94-1.1.jar
  mvel-1.3.12-java1.5.0.jar

  Can anyone kindly help me?

Thanks!
- Zeke
 
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users



_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users