This rule fires:
(defrule count-icd9-codes-in-a-group-for-zip
(declare (salience 5))
(granularity
(gran "ZIP"))
(ICD9_COUNTING_GROUP
(id ?id)
(codes $?codes))
?factV <- (ICD9_CODE (ICD91 ?code))
(test (neq (member$ ?factV $?codes) FALSE))
(analysis_window
(startDate ?startDate)
(endDate ?endDate)
(OBJECT ?countWindow))
(ZIP (zip ?gran))
?c <- (accumulate (bind ?count 0) ;; initializer
(bind ?count (+ ?count 1)) ;; action
?count
(ADS_ENCOUNTER
(DATETIME ?date &: (and (> ?date ?startDate) (<= ?date
?endDate)) )
;(ICD91 ?theCode &: (eq ?theCode (str-cat ?code)))
(ICD91 ?code)
(ZIP ?gran))
)
=>
(code removed)
This rule does not:
(defrule count-encounters-in-time-window-for-zip-granularity
(declare (salience 5))
(granularity
(gran "ZIP"))
(analysis_window
(startDate ?startDate)
(endDate ?endDate)
(OBJECT ?countWindow))
(ZIP (zip ?gran))
?c <- (accumulate (bind ?count 0) ;; initializer
(bind ?count (+ ?count 1)) ;; action
?count
(ADS_ENCOUNTER
(DATETIME ?date &: (and (> ?date ?startDate) (<= ?date
?endDate)) )
(ZIP ?gran))
)
=>
the ZIP, analysis_window and granularity facts are the exact same between
the two. I call reset after loading the rules, and then load the facts and
then execute a run. I guess I was calling the ICD9 stuff the 'junk' on the
LHS of the first rule. If I take it out, then the new rule (essentially the
2nd one with just the ICD9 ?code part of the pattern removed) doesn't fire.
Thanks,
Roger
On 12/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> All pattern-matching has to be driven by *some* change to working
> memory. A few CEs (not, test, accumulate) can pass when they match no
> facts at all. Therefore, these CEs need a little help to know when to
> fire. If any of them appear first on the LHS of a rule, Jess inserts a
> pattern "(initial-fact)" before them, making them dependent on the
> "reset" function being called. It's always a good practice to use
> "reset" sometime before you call "run", but in this case it's a
> necessity: if "accumulate" is the first CE on the LHS of a rule, then
> you *must* call reset at some point before calling run, or the rule
> will never fire.
>
> Other than that, yes, it should fire whenever the preceding patterns
> or its own embedded pattern match, returning 0 if the count is indeed 0.
>
>
> I think Roger Studner wrote:
> [Charset iso-8859-1 unsupported, filtering to ASCII...]
> > Are there situations or usages of (accumulate) that would actually
> prevent a
> > rule from firing?
> >
> > ?c <- (accumulate (bind ?count 0) ;;
> initializer
> > (bind ?count (+ ?count 1)) ;; action
> > ?count
> > (pattern to look for.. single fact, not even complex)
> > )
> >
> > If there are *no matches* to this pattern, should it always fire and
> have ?c
> > bound to zero?
> >
> > Thanks,
> > Roger
>
>
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Advanced Software Research Phone: (925) 294-2154
> Sandia National Labs FAX: (925) 294-2234
> PO Box 969, MS 9012 [EMAIL PROTECTED]
> Livermore, CA 94550 http://herzberg.ca.sandia.gov
>
> --------------------------------------------------------------------
> 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]
