First, read Chapter 8 of the manual (The Rete Algorithm.) This chapter
describes how rules are transformed into a network of pattern-matching
nodes. What 'matches' shows you are the cumulative fact-lists that
have been sent to the left and right inputs of each node in the join
part of the network.
Second, do a (ppdefrule <rule-name>) to make sure you know how Jess
has transformed your rule, if at all. Sometimes things are changed in
various ways.
Now. In the (matches) output, you'll see one clump of output for each
join node. There are N-1 joins, where N is the number of patterns you
saw in step 2. The joins are shown in top-to-bottom order, such that
the first join displayed joins the first pattern and the second, while
the second one joins the second and third patterns, etc.
Each [Token] represents one input that a join has received. The tokens
in the right memory are always one fact in length, while those on the
left are n facts long, where n is the 1-based index of the join.
The tokens in the left memory of join n+1 imply the outcome of tests
done in join n; i.e., if you see two facts together in a left memory,
that means that any tests that compared them in the previous join must
have passed.
A brief example: say you define this rule:
Jess> (defrule sample
(fact ?x ?y)
(data ?x ?y)
(exec)
=>
)
TRUE
And assert these facts
Jess> (assert (fact 1 2) (data 1 2) (fact 3 4) (data 1 4))
<Fact-3>
Then this is what (matches sample) shows:
----------------------------------------------------------------------
Jess> (matches sample)
[Node2 ntests=2 [Test2Multi:
test=EQ;tokenIdx=0;leftIdx=0;leftSubIdx=0;rightIdx=0;rightSubIdx=0]
[Test2Multi:test=EQ;tokenIdx=0;leftIdx=0;leftSubIdx=1;rightIdx=0;rightSubIdx=1]
;usecount = 1;unique = false]
Left Memory:
[Token: size=1;sortcode=0;tag=UPDATE;negcnt=0;facts=(fact 1 2);]
[Token: size=1;sortcode=2;tag=UPDATE;negcnt=0;facts=(fact 3 4);]
RightMemory:
[Token: size=1;sortcode=1;tag=UPDATE;negcnt=0;facts=(data 1 2);]
[Token: size=1;sortcode=3;tag=UPDATE;negcnt=0;facts=(data 1 4);]
[Node2 ntests=0 ;usecount = 1;unique = false]
Left Memory:
[Token: size=2;sortcode=1;tag=UPDATE;negcnt=0;facts=(fact 1 2);(data 1
2);]
RightMemory:
TRUE
----------------------------------------------------------------------
The first Node2 shown joins the first two patterns. It has several
"Test2Multi" tests - these compare the identity of specific data
between two multislots (recall that ordered facts are implemented as
unordered facts with one multislot named _data.) These tests assure
that any tokens sent "out the bottom" of this join into the next join
will have the requisite matching fields. In this first join, as
expected, you see all the (fact) slots in the left memory, and all the
(data) slots in the right. Additional tests might have pruned this -
tests that can be done on a single fact are done in the pattern
network, which has no memory and therefore is not shown here.
In the second Node2, we see that of the four possible combinations of
one (fact) and one (data) fact, only a single Token was sent to the
left input. This token contains the only two facts for which the
previous join's tests both pass: (fact 1 2) + (data 1 2).
So, obviously there are many additional details, but there's the basic
idea. You can tell if something got stuck in the pattern network by
seeing whether it appears in the appropriate "first" memory, and you
can see if joins succeed by looking in the "next" memory.
Note that the (view) command, which now takes a rule name as an
optional argument, is a good way to visualize how the network fits
together. You can see the same information, plus more, by
double-clicking on the nodes that make up a rule.
I think Ryan Eberhard wrote:
> Has anyone used "(matches <rule name>)" to try and debug a Jess rule set?
>
> In particular, I have a rule that I think should be active, but it is not.
> When I executed the matches command, I received the appropriately described,
> "ugly", printout. Does anyone know how to parse the meaning of the left and
> right memory displays to find the prediate that is not satisfied?
>
> Thanks in advance,
> Ryan Eberhard
> Gradient Technologies
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
Org. 8920, MS 9012 [EMAIL PROTECTED]
PO Box 969 http://herzberg.ca.sandia.gov
Livermore, CA 94550
---------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
