Comments on: The Short Circuited OR Considered Harmful

By: Charles Young

Charles Young — Tue, 08 Aug 2006 14:47:48 +0000

Jess, CLIPS et. al. avoid short-circuiting, and split rules internally into separate rules. There is a problem, though. This approach will often result in duplicate productions being placed on the agenda. This is because a particular set of tuples may match on both sides of the OR - i.e., the same set matches the two internal rules created from that OR. This logically compromises the basic refraction strategy common to almost all production engines, and is therefore generally unwelcome. A few engines have built-in de-duplication features within their agendas to get around this problem. This is a fairly elegant solution. It avoids short-circuiting, maintains all side-effects, but avoids breaking the engine's refraction strategy.

De-duplication on the agenda appears to be fairly rare. One reason is that engines that consume LISP-like ordered and unordered tuples generally have no very convincing way of determining duplicates. Typically, there is no strong identity at the tuple level. One engine I work with which does support de-dupe is only able to do so because it consumes facts as objects rather than relational tuples. Event when used directly over relational data sets or a database connection, it represents individual data rows using objects. It (in part) uses OO identity to identify duplicates.

By: Michael

Michael — Wed, 02 Aug 2006 10:24:37 +0000

I think there are 2 types of or:

Foo(a equals b) or Foo(a equals c)

and

Foo(a equals b | c)

(excuse my pidgeon Jrules).

In the former, 2 rules are "generated", in the latter, it may be a short circuit.

But I don't know from recent experience (no longer use Jrules), perhaps they have optimised it to make OR conditional elements short circuiting (I was thinking of it at one point, as it does confuse people).

By: Dietrich Kappe

Dietrich Kappe — Fri, 28 Jul 2006 21:11:53 +0000

JRules? I remember running into the short-circuited OR problem with JRules not too long ago and again in their .NET version. I can go back and confirm on the .NET version. Can someone test on a recent version of JRules?

By: Peter Lin

Peter Lin — Fri, 28 Jul 2006 14:40:42 +0000

Just to add a bit more information to the discussion. I've seen procedural rule engines which have the OR short circuit issue. To the best of my knowledge, CLIPS generates 2 rules for an OR disjunction. The same for JESS and Drools3. On the benefits of using rule generation, I like using rule generation because it makes testing and validation easier. If users are constrained to specific set of patterns, the ruleset validation can be more focused, which should make it easier. Within those patterns, an user can write all the rules they need, not all the rules they "want". There are many rules an user might "want" to write, but many of them may be garbage or poorly organized.

In my bias thinking, part of the job of the IDE is to help users write good rules by providing good guidelines. If a rule IDE uses a DSL based on the terms of that given domain, an user might not even realize all the rules they need to write are covered by a dozen templates.

peter

By: Michael Neale

Michael Neale — Fri, 28 Jul 2006 14:15:32 +0000

Engines like Jess, CLIPS, even JRules and Drools all have their OR conditional element as non shortcircuiting (both sides of the or are actually effectively split into 2 rules – so both consequences could fire). I always thought it was a side effect, but you have provided the best non-short circuiting explanation I have yet seen, thanks !

By: Michael Chermside

Michael Chermside — Thu, 27 Jul 2006 13:40:14 +0000

A more elegent solution would be for the engine that builds your justification to be driven by the actual data your BRE is working from. These rules contain “or” clauses, and it’s perfectly appropriate for the BRE to follow only one branch of the “or” (to short-circuit). But it is NOT appropriate for the justification engine to do so, and it need not.