Wednesday, May 13, 2009

Take your Chance

If you read a paper, or a journal, or an article, or a note recommending NOT to use a Production Rule System, you will find that one of their strongest point is that Rule Systems are too... logical. In fact, a Rule Base must be built with complete and correct Knowledge of its domain, and it is expected to evaluate exact data, to yield new exact information. No need to say that domain knowledge can hardly ever be defined complete and correct - and even then, when can the input data be defined exact?

Actually, there are many applications for which these conditions ARE true, but what happens when they are not - e.g. medicine, finance, forecasts, .... A RBS is an all-or-nothing solution: either the knowledge and the inputs are precisely defined, or no information will ever be entailed. Yet there is another option: letting the engine become imperfect, so that it can deal with the imperfection in its inputs. Is it ironic for an engine to become more powerful by being less perfect? If it seems so, consider the simple example:

Room ( temperature > 25 , $f : fan )

This rule, "turn the fan on, if the room is hot (and you have one)", is perfectly acceptable, but could easily become inadequate under a few circumstances:

  • Imagine the temperature fluctuates with imprecision around 25°, say from 24.9° to 25.1°: should you activate the fan or not? Such action could have a cost, and with the energy prices rising...

  • Imagine you have a sensor measuring 30°, but it is placed in a sunny spot just under the window: the value it returns may not be the real one. Or the sensor could be broken and, from time to time, yield random, unreliable values. Is your confidence strong enough to justify the activation of the fan?

  • Imagine you don't have a temperature sensor: you know that the room is hot, for sure more than 20°, but not the exact value of the temperature. Should the fan be turned on even in presence of such a vague estimate?

  • Imagine you are getting back home from work, and can activate the fan using a SMS. You know your room IS hot, unless someone opened the window earlier in the afternoon. There is some probability that you need to turn on the fan, but some that you need not

  • In any case, is turning on the fan always the right decision? Maybe there are exceptions to be considered...

  • and so on...

The target of the new sub-project, Drools:Chance, is to make our favorite rule engine capable of dealing with any - possibly even more than one - type of imperfect information natively. This means that the degrees of imperfection will not have to be processed explicitly in the rules, as the engine will take care of it behind the scenes. Moreover it will be possible to configure the behavior of the engine to reason with different types of imperfection without changing the rules: like different flavors, a user will be able to pick his favorite one.

I have been working on a prototype for some time, and have implemented several new features, which I will show in this blog. However, there is still much to do: from implementation, to optimization, to documentation, to testing, to providing advice. So any help, even a simple but constructive comment, will be appreciated.

Davide "sotty" Sottara
-- No Laws, just Rules.

coming soon: Custom Degrees, Evaluators and much more...


  1. Is there a link to a related paper we can read?

  2. It looks like drools is trying to bring the concept of 'fuzzy'. Would that be correct or drools-chance is something different?

    This is not to assert at all that if it is 'fuzzy' then it isn't worthwhile or anything like that. Rather 'fuzzy logic' is a very powerful technique (pioneerd by Lotfi Zadeh) and can have many uses. For ex. in insurance industry it is a commong practice to use rules, logic engines, historical data, demographics etc. to predict a number that represents the chances of a driver being in an accident in the first year. This number itself is typically is a range. More importantly the facts which contribute to the calculation of this number aren't fixed values. They are ranges (open or closed).

    I think drools-chance is a very good idea. As requested by the other commenter it would be nice to read some whitepaper on this.


  3. Drools Chance is a way to deal with imperfect reasoning, it is not tied to any specific sub system for this. We have an api that makes it possible to work with a range of approaches, from fuzzy logic to certainty factors to bayesian.

    Davide will being doing a series of articles exploring this and should be unveiling the new code within the next few months.

  4. There is a white paper for this, but it's not public yet. Once it's public we will provide a link from this blog, but for now the series of blogs that Davide has planned should suffice.

  5. Looking forward to Davide's article series and the public whitepaper.


  6. Is there any progress with Drools Chance?

  7. Hello, Has there been any updates to Drools Chance?

  8. There has, best to ask on the dev mailing list.

    It's still only for the adventerous though.

  9. From where can I download drool-chance executable. I can see only github path. Could not get executable jars. Please suggest suitable link.