in reply to Re: Re: Rules-based Perl?
in thread Rules-based Perl?

Pretty much, the way I plan to develop this is as follows: My current thoughts is that the key data item, facts, are only arrays; they may be arrays of mixed data, or just scalars, but they are arrays. Of course, from the practical understanding of a rules-system, you shouldn't be using very complex data structures in any case, as you can always alter them to be replaced by multiple facts, but I want to leave that open in case someone wants to take the concept to advanced levels. The only time that data is introduced to the system would be by facts; while perl input can be used to generate data, the data would go out of scope at the end of the rule unless specifically put into a fact and stored away. Standard perl output can be used for any other generation, while backend stuff can be directed to another file (ie which rules have fired, with which facts, etc).

The trickiest part, for me, is making the rule triggering more efficient. Rules will have two values associated with them: priority (higher priority rules will trigger first) and probability (rules of the same priority and that all can be triggered at the current step; probability will select a random rule from this to trigger). These could change as the rules are fired, though this can lead to bad rule-based systems. In addition, some criteria for rules are dynamic, for example in my pseudo code...: 

rule find-max
1:( value ?id1 ?X )
2!( value ?id2:{ ?id2 != ?id1 } ?Y:{ ?Y > ?X } )
=>
etc...

[download]
That is, the first criteria takes a rule that matches the format of "value <id> <number>". The second is a negative criteria; this is, we don't want any rule where a different ID has a larger number. Now, to check this, one must take all N facts, and do N^2 checks with the criteria (though it can be assumed that this might be closer to 0.5 * N^2, since once a fact denies the second criteria, the first rule obvious cannot match. In small cases (few rules & facts) this isn't bad, but it won't scale well to larger systems. I'd like to have a side strucutre that notes when facts match the criteria of rules in order to improve this efficiency; this is easily done for the first criteria of the example above but the second step may still require O(N^2) checks. In general, for N rules with an average of K criteria per rule, and M facts, the system scales as N*(M^K), and any possible reduction of this would help.

At this point, I've mostly got ideas, and it's a matter of implementing things in a perl-ish way (eg transferring variables from matched rules to the 'body' of the rule).

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Replies are listed 'Best First'.
Re: Re: Re: Re: Rules-based Perl?
by Brovnik (Hermit) on Jun 26, 2001 at 20:17 UTC
    I haven't seen any statement of purpose yet (or in XP jargon "Users stories").

    Are you expecting the knowledge engineer (the person writing a rules base) to be a programmer ? A Perl programmer ?

    What degree of complexitiy of (real-world) problem do you expect to be able to solve ?

    For a user, a table isn't a complex concept, but inputing it might be unless the system is designed to cope at the beginning. Writing a rule such as (in my pseudo code) : 

    [ID in (A B C)]
=>
[D = rows from TABLE_D where KEY=ID]

    [download]

    could be difficult otherwise.

    Re. The rule efficiency, you are right, this is the hard part.
    To some extent the responsibility lies with the knowledge engineer (read ruleset creator), since you can write bad (==slow) programs/algorithms in any language.

    Giving the engineer tools (such as the priority / weighting mechanism you mention can help, as can other options such as choice of search mechanism and direction.

    In my experience, a lot of knowledge engineer time is spent tuning the knowledge base, and the system should be proactive in helping that process, providing timing / coverage analysis.
    --
    Brovnik

[reply]
[d/l]
      At this point, it's merely for the purposes of "because it (the lack of perl&rules) is there". Mind you, yes, I'm thinking down the road and making this professional quality, which means that I have to consider the audience at that point. But the initial proof-of-concept would be a working rules engine, in which simply flow control is directed by what facts; anything beyond that , such as how facts are formatted, how rules are defined, etc, is mostly the 'user interface' part of the problem. And by providing a working engine, weaknesses and strengths of the interface can be figured out faster.

      I guess my overall goal is to provide a way to run a rules-like system (which in my previous experience has had weak interaction with the OS outside of input and output to terminal) using perl (which has strong OS interaction including networking, etc). An ultimate use would to place a perl script with the rules engine at the backend of a network socket, such that new facts can be introduced remotely and actions on local and remote systems taken as such (a so-called business logic server); so the language and depth would have to be simple enough to write the rules in but still allow for taking full advantage of using perl. There's obvious approaches to doing this, but determining how to draw the line between perl-isms and language elements I can introduce is way down the road.

      Once I get moving on this, I'll be posting the code as I've done with other modules of mine here for feedback and such, at least until it's stable and usable enough for CPAN inclusion.

      Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain
[reply]

In Section Meditations