Two things to understand:
1) Jess's working memory can't contain duplicate facts. If you modify
a fact and it becomes identical to another fact, then the modified
fact object is effectively removed from working memory. You can think
of it as "merging" with the pre-existing fact that it is now
identical to.
2) When you call modify, Jess takes the fact you pass in and
(quickly) finds one in working memory that is equal to the argument,
then modifies that found fact. That way you don't have to have a
reference to an actual working memory element to modify the "real"
element.
So here, ?m is bound to the fact object with id 61. When you modify
that fact, it becomes equal to the fact with id 62, and so fact 61 is
dropped from working memory. ?m is still bound to the jess.Fact
object, but that object is no longer in working memory. Then when you
call modify on ??m again, Jess finds fact 62, which is equal to fact ?
m but is in working memory, and modifies that fact.
Make sense?
If the double-modified fact would not be equal to fact 62, then don't
call modify twice -- just call it once, with both slot specifiers at
the same time. It will not only do the right thing, but it will be
more efficient, too:
(modify ?m (tb-added ?ta1 ?ta2) (literals ?add ?lit))
On Nov 27, 2007, at 4:47 PM, Szymon Klarman wrote:
Hi,
I've noticed the following problem. A rule matches a fact and its
id is
assigned to some variable ?m. Later, in the body of that rule I
call twice
the (modify) function on ?m. The program started acting strange so I
switched to (watch facts) mode and it turns out, that on one input
(in no
significant way different from others) program modifies a different
fact
than it assigns to variable and only at the second call of (modify).
here's the relevant fragment of the rule's body:
(printout t "value of ?m "?m crlf)
(modify ?m (tb-added ?ta1 ?ta2))
(printout t "modified (1st)"?m crlf)
(modify ?m (literals ?add ?lit))
(printout t "modified (2nd) "?m crlf)
and here's the relevant screen from the run of the program (with facts
watching)
value of ?m <Fact-61>
<=> f-61 (MAIN::model (origin <F......
modified (1st)<Fact-61>
<=> f-62 (MAIN::model (origin <F......
modified (2nd) <Fact-61>
Could someone please confirm that this could be actually the case,
while it
seems too awkward to believe. Absolutely nothing in the rule or any
other
part of the program can justify such behaviour. Is it possible that
the
engine simply makes a mistake???
all best,
Szymon
PS. I encountered also similar phenomena while experimenting with
accumulate
CE, which eventually led me to dropping it and using more complex
but more
reliable querying.
--
View this message in context: http://www.nabble.com/Jess-confuses-
Fact-id-assigned-to-a-variable-%28%21-%21%29-tf4884619.html#a13980506
Sent from the Jess mailing list archive at Nabble.com.
--------------------------------------------------------------------
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 owner-jess-
[EMAIL PROTECTED]
--------------------------------------------------------------------
---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences Phone: (925) 294-2154
Sandia National Labs FAX: (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://www.jessrules.com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
