Is there any way to view the Rete network?

[Ged Byrne]

Hi all,

Is there any way to view the rete network for a given set of rules?

Something similar to the execution plan provided by RDBMS, or the Rete view available in the Drools IDE?  

https://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/html/ch08.html#d0e8179

Regards, 

Ged

[Ronald Finkbine]

Have one rule with all templates in the CEs. If you remove all variable checking in the CEs, then add a print statement in the rule with the fact numbers.

Therefore, you will have a list of all the combinations of facts.

Ronald Finkbine
ronaldf...@hotmail.com

---

From: clip...@googlegroups.com <clip...@googlegroups.com> on behalf of Ged Byrne <ged....@gmail.com>
Sent: Tuesday, May 9, 2023 12:27 PM
To: CLIPSESG <clip...@googlegroups.com>
Subject: Is there any way to view the Rete network?

 

--
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/cdcb1741-1a3c-4492-b2bd-419b95ea5387n%40googlegroups.com.

[CLIPS Support]

Not graphically. For individual rules, you can use the matches command to determine which facts have matched the rule patterns.

CLIPS>
(defrule example
   (number ?x)
   (number ?y&:(> ?y ?x))
   (number ?z&:(> ?z ?y))
   =>)
CLIPS> (assert (number 1) (number 2) (number 3))
<Fact-3>
CLIPS> (matches example)
Matches for Pattern 1
f-1
f-2
f-3
Matches for Pattern 2
f-1
f-2
f-3
Matches for Pattern 3
f-1
f-2
f-3
Partial matches for CEs 1 - 2
f-1,f-3
f-2,f-3
f-1,f-2
Partial matches for CEs 1 - 3
f-1,f-2,f-3
Activations
f-1,f-2,f-3
(9 4 1)
CLIPS> 

[Ged Byrne]

Thanks for the guidance.  I think this gives me what I need to manually draw the graph.

[Yurii Rashkovskii]

Working with CLIPS using its C API, is there any way (even without guarantees for a stable API) to obtain more detailed information about CEs, like the template and literal values/bindings?

I am trying to have an extremely limited form of (not-quite) backward chaining (or what I understand of it). I hypothesize that if I can gather the above assertion, then I can use it to assert a `needs` fact based on the CE to drive fulfillment of these conditions.  The implementation of `matches` helps illuminate how to get the patterns with no matches, but I am failing to work backwards from it and find the information on the CEs behind these patterns.

Thank you!

[CLIPS Support]

If you step through the matches code, in functions like PrintPartialMatch, you can see a line of code like this:

matchingItem = get_nth_pm_match(list,i)->matchingItem;

This is assigning to matchingItem the value of either the fact or instance for the position specified by i in the partial match. Once you've got that pointer you can use either the fact or instance API to retrieve slot values.

Once the rule has been compiled, however, the information about the bindings is gone, so you'd have a hard time gleaning information about what values should be placed in a needs fact. I think it would be more practical to generate that information when the rule is defined and store that information in the appropriate join in the join network.  

[Yurii Rashkovskii]

Thank you for your help and insight. I have considered getting this information when the rules are created. However (even though I wasn't able to find the CE details there yet), one concern I had is that this would effectively require me to fork CLIPS as I'd need to modify in the vicinity of `ParseDefrule` (`LHSPattern()`, `ConnectedPatternParse()`, etc.)

Do you think I am correct with this assessment that it is impossible to get that information injected into the network joins during rule definition, without patching CLIPS?

Assuming this is true, I will try continuing with this path as you suggest it may be more practical. Any tips as to what would be the best way to extract CE details at that stage will be highly appreciated!

[Yurii Rashkovskii]

I wrote a _very crude_ handler for `(requires ...)` CE (with parsing similar to `logical`): https://gist.github.com/yrashk/846432487d0afdc6168723f8612fa2f4

However, I am still unsure how to correctly retrieve slots containing values so that I can populate those in the asserted fact. Any tips or insights will be highly appreciated!

[Yurii Rashkovskii]

Nevermind, I think I figured out the basics of it and now https://gist.github.com/yrashk/846432487d0afdc6168723f8612fa2f4 contains a later version of the patch that seems to provide the basics of the functionality I wanted.

Thank you again!

[CLIPS Support]

Here's a paper that gives a good high level overview of data driven backward-chaining as provided in the Eclipse programming language: http://haleyai.com/pdf/BackwardChaining.pdf. This is the same basic approach as used in Jess which is to automatically generate goals when a pattern isn't matched by a fact, but the proceeding patterns do have matches. If you look at how an example works in Jess, you can infer some of the steps you'll need to implement:

Jess, the Java Expert System Shell
Copyright (C) 2001 E.J. Friedman Hill and the Sandia Corporation
Jess Version 6.1p4 7/8/2003

Jess> (deftemplate point (slot x) (slot y))
TRUE
Jess> (do-backward-chaining point)
TRUE
Jess>  
(defrule example
   (value ?x)
   (point (x ?x) (y 3))
   =>)
TRUE
Jess> (reset)
TRUE
Jess> (facts)
f-0   (MAIN::initial-fact)
For a total of 1 facts.
Jess> (assert (value 2))
<Fact-1>
Jess> (facts)
f-0   (MAIN::initial-fact)
f-1   (MAIN::value 3)
f-2   (MAIN::need-point (x 2) (y 3))
For a total of 3 facts.
Jess> 

In this case, when the fact (value 2) is asserted, the goal fact (need-point (x 2) (y 3)) is generated because the second pattern in the rule isn't matched. So probably what's happening is that there's an assert statement associated with the join in the join network associated with the point pattern: (assert (need-point (x ?x) (y 3))). In order to construct this, you'd need to look at the point pattern and see that the x and y slots are both used in the pattern and so the values need to be included in the assert statement. If Jess works similarly to CLIPS, then the reference to the variable ?x would be replaced with a function call that retrieves the first field from the value fact matching the first pattern. And since the goal generation is going to be happening during the assertion or retraction of a fact, the assertion of that goal will need to be queued and then asserted once the current fact assertion/retraction is complete. It wouldn't be possible to do something similar in CLIPS without creating your own patches.

I think if you're going to do this, you'll need to step through the debugger with a simple rule:

CLIPS> (deftemplate point (slot x) (slot y))
CLIPS>
(defrule example
   (point (x ?x))
   (point (x 2) (y ?y&:(> ?y ?x)))
   =>
   (println ?x " " ?y))
CLIPS> 

     

This will let you see how the patterns are constructed (because you'll need to examine these to see which slots to assert) and you can see how the references to ?x and ?y are replaced with function calls for the > function in the LHS and the println function in the RHS.

[Yurii Rashkovskii]

Thank you so much; this is indeed very useful. My current patch always asserts the `need-` facts, whether they are needed or not. It works as the first approximation but is clearly far from perfect. Your explanation helps to navigate this further, and I'll perhaps be able to keep the current code to populate the `need-` templates at the parse time but do the assertion as per your suggestions (when I'll be able to process it)