Dynamic salience

I'm torn between debugging and fixing pyRete's current RuleCompiler and refactoring it altogether. In order to keep up apperances I've been focusing on other things these past few weeks. So when Mark announced support for Dynamic Salience in JBoss Rules I naturally decided to add it to pyRete ;-)

Dynamic Salience was actually already on my to-do list for pyRete but I wouldn't have spent time looking into it if Mark hadn't posted about it. It turns out that it's not too difficult to add it. This time, I'm doing a few things differently from Clips though.

First of all, Salience evaluation is local (per Rule) and not global as in Clips.

Also, technically, there won't be any difference between Static and Dynamic Salience, both will always have an expression evaluated when needed. The only real difference is that using a Python constant (an integer) won't ever change the Salience and will therefore appear to be static.

And last, but not least, I'm not sure about how to differentiate between Clips' concepts when-activated and every-cycle. I'm going to have to add some meta-data to the Rule Syntax one way or the other. At the moment, Salience is always calculated when a Token is added to a Rule's Production Node. I'm hoping that's enough but we'll have to see about that. Also, I'm worried about doing too much work in the match-resolve-act cycle if I allow every-cycle. pyRete is slow enough as it is.

[2007-05-31] Update: I've been trying to figure out more about Clips' behaviour in relation to dynamic salience (see my comments on Mark's post).

What Mark has implemented for JBoss Rules and what I have done for pyRete is different in many ways from what's been implemented in Clips and my questions about the differences between when-activated and every-cycle have been answered. The design decisions of allowing the salience declaration to access LHS variables and to only calculate salience when a Token reaches a Production Node makes it unneccessary to implement both.

4 kommentarer:

woolfel sa...

There is a case where recalculating the salience on every cycle "may" be needed. If a defglobal participates in the pattern matching for a rule and it participates in the calculation of the salience. Since defglobal changes do not go through the normal modify/retract/assert process, an activation in the agenda would not know to recalculate. In that case, the only real way to handle this case is to calculate the salience on every cycle. By cycle I mean when a new activation is removed from the agenda for firing.

Johan Lindberg sa...

Well, the current design won't allow Activations to change Salience once they're on the Conflict Set. I see your point.

I've been so focused on implementing Dynamic Salience in the way that's *not* supported by Clips that I completely forgot about the use-cases that *are* supported. ;-)

Thanks for pointing that out, I'll implement it this weekend.

woolfel sa...

glad that info was interesting to you. I'm writing up a new entry that goes into dynamic salience a bit more.

woolfel sa...

I've posted another entry about dynamic salience, which may interest you.