strange behaviour

[denis.be...@gmail.com]

Consider two (large) sets of rules R1 and R2, with R1 included in R2, designed to solve the same class of problems.

Both sets are error-free with extremely high probability: they have been tested on millions of cases for the 1st and on 10,000s for the largest one, and the problem is such that any error is detected after only a few instances are tested.

Here is what I observe in very rare instances of the problem (say 1 in 10,000): the problem is solved by R1 but not by R2.

In and of itself, this shouldn't be too much of a surprise: some of the new rules might  fire before the old ones, preventing the old ones from firing later. This is a standard problem of non-commutativity in the set of rules.

However, what I observe after a deeper study of the situation is different and much more diabolical. Suppose I run the two sets of rules in different instances of CLIPS, for the same problem instance. After some common rules fire, a state is reached where all the facts are the same (easy to check). However, at this point, a rule of R1 that fires in the first version doesn't fire in the second (and it should because it has higher salience than the rule that fires next).

So, I wonder if there is any limit on the number of rule instantiations in the agenda(s) and what happens when some limit is reached.

PS: this happens in both 6.3 and 6.4, last release.

[CLIPS Support]

No, the only limitation is the amount of available memory.

[denis.berthier]

I should have asked the same question also for the sizes of nodes of partial matches in the Rete network.

--------------------------------------
Denis BERTHIER
4 rue Alphonse DAUDET
75014 Paris, FRANCE
tél. : (33) 1 45 43 62 15
http://www.carva.org/denis.berthier

http://denis-berthier.pagesperso-orange.fr

--------------------------------------

--
You received this message because you are subscribed to the Google Groups "CLIPSESG" group.
To post to this group, send email to CLIP...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/CLIPSESG?hl=en
 
--> IF YOU NO LONGER WANT TO RECEIVE EMAIL <--
Visit this group at http://groups.google.com/group/CLIPSESG?hl=en
Click on "Edit my membership" link.
Select the "No Email" radio button.
Click the "Save these settings" button.

--> IF YOU WANT TO UNSUBSCRIBE <--
Visit this group at http://groups.google.com/group/CLIPSESG?hl=en
Sign in
Click on "Edit my membership" link.
Click the "Unsubscribe" button.
Note: This appears to be the most reliable way to unsubscribe
 
Alternately, send email to CLIPSESG-u...@googlegroups.com. You will receive an email which you must respond to as well to unsubscribe. Clicking the link mentioned in the unsubscribe reply does not appear to work reliably.
---
You received this message because you are subscribed to the Google Groups "CLIPSESG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clipsesg+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/clipsesg/4edb0ff6-7989-41ac-a480-05fba0f7329cn%40googlegroups.com.

[CLIPS Support]

The number of partial matches are also only limited by memory. The number of patterns in a rule and slots in a deftemplate that can be referenced by the rete network is the max size of an unsigned short which is guaranteed to be at least 65536.

[denis.be...@gmail.com]

Thanks for your answers. These were the first two hypotheses that came to mind for this strange behaviour.

Do you see any possible other reason why a rule that fires when only R1 is loaded doesn't fire when the larger R2 is loaded, at a point where the sets of facts are the same (and a rule with lower salience fires instead)?

[CLIPS Support]

Between rules of the same salience, the selection of the next rule to execute is arbitrary but deterministic. It can be effected by the order in which rules are defined because new nodes in the rete network are generally added at the same point (either the beginning or the end of the list of nodes). So it's possible given two sets of rules R1 and R2, where R1 is a subset of R2, to have rules fire in a different order, even if none of the additional rules in R2 are ever activated or fired.

If you have the same set of facts and you load those in both R1 and R2 and you have a rule in common that's activated in R1 but not in R2, then that would likely be a bug in CLIPS that should be easy to isolate since you don't have to actually trace through execution of the rules. 

If you have to allow both sets of rules to both run up to a point where they've both executed exactly the same rules, but they reach a point where the activations for the common rules are not the same, then that would indicate a corruption problem and those are usually more difficult to track down. That's assuming that you're not doing something that's asking for trouble (like calling fact query functions from the conditions of a rule). 

[denis.be...@gmail.com]

My apologies if this is redundant with a previous message, but it seems there was a problem with publishing it.

My problem is solved. All the rules in R1 and R2 are individually bug-free (I never suspected them: the rules in R2 are mathematically proven and automatically generated). However, in rare cases, problems of non commutativity between rules can prevent a rule from firing. This is what the addition of so many rules (R2) did. This kind of problem is very hard to find, but once the possibility of memory problems were discarded, there were not many other possibilities.

Thanks for your answers.

[denis.be...@gmail.com]

For those of you who have followed this conversation and who would like to see more details, the 4*(630-38) rules (making the R2 set of my previous posts) are published in the last update of CSP-Rules on GitHub (https://github.com/denis-berthier/CSP-Rules-V2.1) with details of their working in the simultaneous update of the user manual.