The important difference between these first two rules is that the
first one fires no matter what the orientation is, while the second
one only fires if

  (eq ?o (call ?c computeOrientation ?pos ?pos-in-front-of))

is true. When the first rule fires, Jess does indeed reevaluate the
left-hand-side, and it finds that it matches again, so the rule is
activated again.

When the second rule fires and changes the orientation, presumably the
function call above no longer succeeds, so the second rule only fires
once. As a general rule, if a rule matches a set of facts, and it
modifies one or more of those facts, then, if you don't want it to
fire again, those modifications have to invalidate the match. You
sometimes have to add clauses to rules to achieve this.

Regarding the "randomness" -- you can build this in easy enough,
perhaps using the (test) CE and the Math.random function.



I think El German wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
> Hi again,
> 
>   I'm using JESS with Java objects to define the behaviour of an agent 
> (well, it's not a very sophisticated thing, but I call it an agent).  At 
> this time I'm describing the movement of a car, but I've got a problem.  
> When the car finds an obstacle it must turn right/left/back to keep on 
> driving.  This is the rule that does it:
> 
> (defrule car-turns
>       (car (position ?pos)
>            (OBJECT ?c))
>       (position (OBJECT ?pos-in-front-of&:(and (call ?c isInFrontOf 
> ?pos-in-front-of)
>                                                 (not (call ?c isAllowed 
>?pos-in-front-of)))))
>       (position (OBJECT ?pos-free&:(and (call ?c isNextTo ?pos-free)
>                                         (call ?c isAllowed ?pos-free))))
> =>
>       (call ?c setOrientation (call ?c computeOrientation ?pos ?pos-free))
> 
>   Where isInFrontOf, isAllowed, isNextTo and setOrientation are Java methods 
> of the Java class car.  isInFrontOf returns a boolean value due to the 
> position attribute of car, its orientation attribute, and its parameter 
> ?pos-in-front-of.
> 
>   The problem is that my car turns too many times.  When the car turns I 
> change its orientation attribute and I fire its change (firePropertyChange), 
> but the activated rules (one activation for each adyacent position) keep on 
> activated and they shouldn't, because orientation has changed and 
> pos-in-front-of can't be in front of again.
> 
>   It seems to be like if the method isInFrontOf was not re-executed each 
> time the state of the car changes.  Surely it's a concept or programming 
> mistake.  I don't know how JESS works in this situations, but I changed the 
> code to be sure of the "reevaluation" of the conditions to activate the 
> rule.  Now this is the code for the rule:
> 
> (defrule car-turns
>       (car (position ?pos)
>            (orientation ?o)
>            (OBJECT ?c))
>       (position (OBJECT ?pos-in-front-of&:(and (eq ?o (call ?c computeOrientation 
> ?pos ?pos-in-front-of))                                                              
>                   
>                 (not (call ?c isAllowed ?pos-in-front-of)))))
>       (position (OBJECT ?pos-free&:(and (call ?c isNextTo ?pos-free)
>                                         (call ?c isAllowed ?pos-free))))
> =>
>       (call ?c setOrientation (call ?c computeOrientation ?pos ?pos-free))
> 
>   And this code works right.  I think it's because it must check the value 
> of the attribute orientation, which changes when a rule is executed.
> 
>   Am I right?  Are there any posibilities to do it in a diferent or more 
> smart way?
> 
>   I've got another problem.  The car moves right, but it does always the 
> same movements, and it enters in a loop between two walls.  Could the 
> movement of the car be random?
> 
>   I will welcome any help!
> 
>     Cherman.
> 
>   P.D:  I apologize for the extension of the message.
> 
> _________________________________________________________________
> MSN Photos es la manera m_s sencilla de compartir e imprimir sus fotos: 
> http://photos.latam.msn.com/Support/WorldWide.aspx
> 
> 
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
> 



---------------------------------------------------------
Ernest Friedman-Hill  
Distributed Systems Research        Phone: (925) 294-2154
Sandia National Labs                FAX:   (925) 294-2234
Org. 8920, MS 9012                  [EMAIL PROTECTED]
PO Box 969                  http://herzberg.ca.sandia.gov
Livermore, CA 94550

--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to