In addition to the refreshingly unusual problem domain, it was Ernest's
response that has inspired me to propose a variation. The idea is to have a
fact for the next Play of "the player", which is initially created with
"fold" and low priority. Each of the strategy rules matches on this Play
fact but only if the rule's priority is higher than the one found so far. On
a match, the new action replaces the old one, and the priority is set to the
higher value. As a result, the final rule will only have to deal with the
one and only Play fact.
(deftemplate Player (slot nick)(slot type))
(deftemplate Card (slot rank)(slot suit))
(deftemplate Play (slot what)(slot prio))
(deftemplate History (slot who )(slot what))
(deffunction rand()
(return (/ (random)65536))
)
(defrule raise-or-call-on-pocket-rocket-against-bluffer
?p <- (Play (prio ?prio & :(< ?prio 90)))
(History (who me)(what bluff))
(Card (rank ace)(suit ?s))
(Card (rank ace)(suit ~?s))
=>
(if (<= (rand) 0.90) then
(modify ?p (what "raise")(prio 90))
else
(modify ?p (what "call")(prio 90))
)
)
(defrule raise-on-pocket-rocket
?p <- (Play (prio ?prio & :(< ?prio 30)))
(Card (rank ace)(suit ?s))
(Card (rank ace)(suit ~?s))
=>
(modify ?p (what "raise")(prio 30))
)
(defrule call-on-pocket-rocket-against-bluffer
?p <- (Play (prio ?prio & :(< ?prio 60)))
(Player (type bluffer))
(Card (rank ace)(suit ?s))
(Card (rank ace)(suit ~?s))
=>
(modify ?p (what "call")(prio 60))
)
(defrule enact-play
(declare (salience -100))
?p <- (Play (what ?what))
=>
(printout t "my play: " ?what crlf)
(retract ?p)
)
(reset)
(assert (Card (rank ace)(suit hearts)))
(assert (Card (rank ace)(suit spades)))
(assert (Play (what fold)(prio 0)))
(run)
(assert (Player (type bluffer)))
(assert (Play (what fold)(prio 0)))
(run)
(assert (History (who me)(what bluff)))
(assert (Play (what fold)(prio 0)))
(run)
On Tue, Nov 25, 2008 at 4:46 AM, Ernest Friedman-Hill <[EMAIL PROTECTED]>wrote:
> On Nov 24, 2008, at 7:01 PM, Ken Banks wrote:
>
>
>> 1. Is a rule based engine such as jess an appropriate solution given
>> the type of problem that I am trying to solve
>>
>
> Yes, I think it's very well suited, actually.
>
>
>
>> 2. What mechanism is in place to control the order of priority of
>> rules? I know that I can manually specify a salience for my rules but
>> is there a better way of doing things?
>>
>>
>
> Salience controls firing order, and it's appropriate for real-time or
> pseudo-real-time control systems and other environments where the rule that
> fires first is the one that counts. A more nuanced way of handling this
> would just be to define a "play" template that described a possible play
> based on the current hand, and give that template an explicit "priority"
> slot. Each rules could, when it fires, create a play with an associated
> priority -- i.e.,
>
> (defrule raise-on-pocket-aces
> (holding pocket aces) ;; I apologize, I don't know what that means, so I
> can't show a better pattern here!
> =>
> (assert (play (action raise) (priority 10))))
>
> (defrule call-on-pocket-aces
> (holding pocket aces)
> (opponent (is-bluffer TRUE))
> =>
> (assert (play (action call) (priority 20))))
>
> and so on. Your system can let many rules fire, creating any number of
> different plays; then a final rule (one with low salience, so it fires
> last!) can choose the play with the highest priority, and use it.
>
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Informatics & Decision Sciences, Sandia National Laboratories
> PO Box 969, MS 9012, 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]
> --------------------------------------------------------------------
>
>
