My Jess app works fine in [61p8], and broke in [71b1].
After much tedious sleuthing, I isolated the culprit to a change
in the way (test) nodes are compiled into the rete.
The following file has 1 function, 1 rule, and 1 fact.
[61p8] Loads fine.
[71b1] During the assert call, it calls F(), which throws.
==begin======================
(deffunction F (?score)
(bind ?r (random))
(>= ?score 71))
(defrule R
(triple #score ?Dp ?s)
(test (F ?s))
=>
(printout t "R!" ?Dp crlf)
)
(view)
(assert (MAIN::triple #Z P10S03 S03))
==end======================
The call to (random) is not necessary for F -- it's just a debug hook.
Assuming you have Jess 71b1 in your Eclipse workspace, then
a) create a new Eclipse project
b) add this file
c) Projects: add Jess 71b1
d) in Debug Dialog...
d1) define a "Java Application" (not Jess Application!)
d2) Arguments = <this file>.jess
e) In Jess 71b1/src/jess/MathFunctions.java, put a breakpoint
in JessRandom#call().
That's the only way I've found to stop and step at the Java level.
(You can also define a separate Debug config as a Jess application,
but then it will step only at the Jess level.)
Superficially, the Java exception occurs because my function
F() is called with ?score bound to a string "S03" from the singleton
fact, and F() applies >= to it, but >= expects only integers.
More deeply, F() should not be called at all, because my fact
(deliberately!) does not match the first pattern in rule R.
[71b1] is skipping pattern 1 and going straight to pattern 2.
Using old-fashioned (view), I see the following retes:
[61p8 on white] A-B-C---D-E-G-H (correct)
[71b1 on gray ] A-B-C-K-D-E---H (buggy)
A = root
B = TECT that fact class is MAIN::triple
C = MTELN 3
D = 0,0 is #score
E = left input adapter
G = NodeJoin (F ?s)
H = defrule R
K = TEQ (F ?s) is not FALSE
Everything in [61p8] is correct. In [71b1], node G has become
node K. More interestingly, K occurs *before* node D, i.e. the
(test) occurs before the (triple #score ? ?) filtering.
This contradicts [71b1, docs/rules.html, 6.12], which states:
A test CE is evaluated every time the preceding pattern
[here, node D] on the rule's LHS is evaluated.
JIA states the same, and the Jess change log through 71b1 doesn't
explicitly supercede this anywhere, so I assume that it's still the intent
to preserve this behavior. [rules.html] goes on:
In fact, starting with Jess 7.1, the functions in a test CE are
simply added to the previous pattern's tests.
That's not what the rete shows. It doesn't show that K has been
merged into D -- it shows K *before* D.
My singleton fact does, in fact, match A-B-C. It does not match D.
But in [71b1], the rete evaluates K before D. So it calls K even on
facts that are syntactically invalid for my function F().
--
Eric Wang
Creative Design and Intelligent Tutoring Systems (CREDITS) Research Center
Sungkyunkwan University
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
