(assert) returns FALSE if the fact being asserted already exists. The
fact that doesn't get asserted is a "constant"
(MAIN::__collection (__data Rubbish))
the first rule asserts it, and then the second one fails to do so,
since it already exists. Since __collection has an "id" slot, you
could avoid this problem just by giving each __collection you assert
a unique id at creation time; for example, you could do something like
(deftemplate __collection (slot id (default-dynamic (gensym* col))))
By the way, I have two reactions to your code. One is that the
subject matter -- Assemblies, Bills of materials, Products, etc, is
something I deal with myself quite often, so it's always nice to see
someone else working in the same area. But second, my hair stands on
end a little. The slot name "__data" is used internally by Jess to
represent the data in an ordered fact, and actually the presence of a
"__data" slot may cause some patterns to be processed specially
(probably in a way that you would not appreciate.) It's best to treat
all names starting with two underscores as reserved for the
implementation. If I were you I would definitely change this code not
to use such names, either for templates or for slot names.
On Feb 9, 2008, at 7:17 PM, [EMAIL PROTECTED] wrote:
Hello,
When I configure JESS 70p1 with a single rule, and feed it two sets
of facts
that each (correctly) trigger the rule, the RHS of the rule is
behaving
inexplicably differently. The RHS plainly calls for the assertion
of a fact, which occurs in one case and not the other.
Here is the entire rule:
(defrule BomType_ltr
?Assembly_1 <- (IPC2511B::Assembly
(assemblyRef ?assemblyRef_2)
(bom nil)
)
?Product_4 <- (IPC2511B::Product
(id ?assemblyRef_2_x)
(name ?name_5)
(revision ?revision_6)
)
(test (eq ?assemblyRef_2_x (AssemblyRefType_to_ShortName ?
assemblyRef_2)))
=>
(bind ?F_13 (names__ltr ?name_5 ?assemblyRef_2_x))
(bind ?bom_name_12 (nth$ 1 ?F_13))
(bind ?assembly_name_8 (nth$ 2 ?F_13))
(bind ?step_name_9 (nth$ 3 ?F_13))
(bind ?C_11 (assert (MAIN::__collection (__data Rubbish)))) ; <==
Unreliable
(bind ?BomHeaderType_7 (assert (IPC2581am1::BomHeaderType
(assembly ?assembly_name_8)
(revision ?revision_6)
(stepRef ?step_name_9)
)))
(bind ?BomType_10 (assert (IPC2581am1::BomType
(bomHeader ?BomHeaderType_7)
(bomItem ?C_11)
(name ?bom_name_12)
)))
(modify ?Assembly_1
(bom ?BomType_10)
)
)
Here is a fragment from the transcript when watchAll is activated:
FIRE 1 MAIN::BomType_ltr f-26, f-32,
==> f-118 (MAIN::__collection (__id nil) (__data Rubbish))
==> f-119 (IPC2581am1::BomHeaderType (__id nil) (affecting nil)
(assembly
"product29") (revision "revision11") (stepRef "product29"))
==> f-120 (IPC2581am1::BomType (__id nil) (bomHeader <Fact-119>)
(bomItem
<Fact-118>) (name "product29"))
<=> f-26 (IPC2511B::Assembly (__id 272) (bom <Fact-120>) (assemblyRef
"product29") (boardOrPanelRef "board7:x") (componentPlacementRefs
<Fact-27>)
(designRules nil) (drawingRefs nil) (powerSupplyRefs nil)
(testConnectRefs nil))
FIRE 2 MAIN::BomType_ltr f-23, f-30,
==> f-121 (IPC2581am1::BomHeaderType (__id nil) (affecting nil)
(assembly
"product32") (revision "revision9") (stepRef "product32"))
==> f-122 (IPC2581am1::BomType (__id nil) (bomHeader <Fact-121>)
(bomItem
FALSE) (name "product32"))
<=> f-23 (IPC2511B::Assembly (__id 258) (bom <Fact-122>) (assemblyRef
"product32") (boardOrPanelRef "board3:z") (componentPlacementRefs
<Fact-24>)
(designRules nil) (drawingRefs nil) (powerSupplyRefs nil)
(testConnectRefs nil))
It will be seen that FIRE 1:
* Asserts a new __collection as f-118 (this is expected)
* Asserts f-120 with a slot named bomItem containing f-118 (expected)
On the other hand FIRE 2:
* Does not assert a new __collection fact (unexpected)
* Asserts f-122 with a slot named bomItem containing FALSE
(assertion expected,
FALSE not expected)
I hope someone can explain this.
Thanks,
Art
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
