Forward Chaining using variables in rules in CLIPS - clips

So, I'm trying to make a "golf club recommendation system" for a 18 hole course. Now, after having defined the basic templates for the golfcourse, golf club and the golf player, I'm stuck due to the large search space this particular problem presents. So currently I have:
(defrule teeoff
?g <- (golfer (position "tee"))
=>
(retract ?g)
(assert (golfer (position "fairway") (Current_club "driver") (Yardage 650))
After this, the ball is on fairway and can have a combination of factors say, it can be on sand, it can be on rough or it could be on a normal green. My question is instead of making a rule for every possibility can I have one or two rules like:
(defrule makemove
?m <- (golfer (position ?x))
?go <- (golfcourse (obstacles ?$y)
=>
(assert (golfer (Current_club ?c)))
If not, then what alternatives do I have?

I suggest to you to design an object or attribute to manage the ground_material (sand, green, ...) and include it inside the rule.
You can write rule for each ground or use IF-THEN condition inside a single rule.
Hope this helps you.
bye
Nic

Related

Clips: Restriction in the variable of a vector to search

This is the Clips code that i am trying to arrange. I have some vector in de BH and I want to search among them, those which ?P is common between them. Moreover in the second vector to search the restriction is that ?E can only be that types. Please help me.
(defrule padre
(es-padre ?P ?H)
(?E & :(tigre | leopardo | jirafa | cebra | avestruz | pinguino | albatros) ?P)
=>
(assert (?E ?H))
)
Is there any solution implementing a Switch case, or the unique solution is making more rules?
You have multiple syntax errors, so it's hard to tell what you're trying to do. To start, the first field of a pattern or fact you're asserting can't be a variable. If you include examples in your question (such as the facts you're asserting and what should happen when your rule executes) it will make it easier to answer your question.

Get rule body in CLIPS

I am new to CLIPS development and I need to retrieve a rule body and store it in string in order to parse it. I tried to redirect the defrule stream but without success.
Is there any way to do it like that or does it exist a special command that I would have forgotten.
(defrule one
(fact a)
=>
(assert (fact b)))
(bind ?str (ppdefrule one))
one rule displaying but ?str is empty
Thank you for your time and consideration.
There's not a clean way to do this out of the box, but there's a C API for retrieving the text, so you could extend CLIPS with a user-defined function to allow you to do this. The alternative would be to use dribble-on/dribble-off to capture the output in a file, but this would also display the output to the screen each time you retrieved the rule text.

How to let a user modify a fact without activating a certain rule?

I wonder if it is somehow possible to have a construct, such that a user can modify a rule without triggering a rule. So my minimal example:
(defrule A-has-B
(A B)
=>
(assert (A-has-B)
)
(assert (A A))
f-1 (A A)
Now, I would like to modify (A A) to (A B) without triggering the rule "A-has-B".
First I thought about something like:
(defrule A-has-B
(A B)
(not (exists (usercontrol on)))
=>
(assert (A-has-B)
)
But after retracting '(usercontrol on)' the rule fires.
Maybe, somebody can tell me whether it's possible or not.
It is not possible to disable a pattern from being matched by a fact.

CLIPS: Retrieving a fact and getting a pointer to it

I am working with CLIPS embedded in a C program, so I have to do everything by C function calls and can't use the CLIPS command line.
Let's say I have asserted a few facts like this:
AssertString("(pizza 1)");
AssertString("(cauliflower 7)");
AssertString("(cheesecake 0)");
Obviously I do not get (let alone retain) any pointers to my facts at this point. When I want to retract a fact later by using Retract(factPtr), I obviously need the pointer to the fact I want to retract. So, after the lines above, how would I find the fact (cauliflower 7) again and get a pointer to it?
Do I have to get the entire fact list by GetFactList([...]), loop through it and compare strings? If so, how would I do that in the multifield DATA_OBJECT this function returns? Or is there a better way?
I would be grateful for any ideas or even code examples.
You can use the fact query functions to query the fact-list and perform actions. You can invoke this through the EvalFunction:
DATA_OBJECT result;
Eval("(do-for-all-facts ((?f pizza)) (eq ?f:implied (create$ 1)) (retract ?f))",&result);
Eval("(do-for-all-facts ((?f cauliflower)) TRUE (retract ?f))",&result);
In the first call, only the pizza fact with the value 1 is retracted. In the second call, all cauliflower facts are retracted.

CLIPS using (not (a-fact $?)) doesn't fire

I'm having a slight difficulty in understanding how the not function interacts with pattern matching. I'd like to write a pattern match that goes "such a fact doesn't exist".
Namely, what I want is:
(defrule init-count
(not (highest-debt ?))
(catherines ?debt)
=>
(assert (highest-debt ?debt))
)
and then:
(defrule continue-count
?debt-fact <- (highest-debt ?h-debt)
(? ?a-debt)
(test (> ?a-debt ?h-debt))
=>
(retract ?debt-fact)
(assert (highest-debt ?a-debt))
)
But for some reason not doesn't work for me here. Replacing not with (not (exists /*pattern*/)) doesn't seem to work either.
Is there something I'm missing and/or a nice way to implement finding the highest number with rules like that?
Update
The answer that I have just discovered is this: the not pattern shouldn't be the first one ((declare (salience 0)) doesn't count either). So, the following code works correctly:
(defrule init-count
(catherines ?debt)
(not (highest-debt ?))
=>
(assert (highest-debt ?debt))
)
Sorry for bothering :(
In versions 6.24 and earlier, when the not conditional element was the first pattern in a rule, the pattern (initial-fact) was added before it (this is described in section 5.4.9, Automatic Addition and Reordering of LHS CEs, in the Basic Programming Guide). The (initial-fact) fact is asserted when a (reset) command is performed. I think this is the cause of your problem. Your original rule would have worked if you'd performed a (reset) before asserting your other facts.

Resources