          IDEAS for CONTROLLING INFERENCE in ALGERNON

                  MH:  2 Oct 1996



1.  Why do we want to control (the order of) inference?

    Algernon eventually executes every action and for the
    most part the results are independent of order of
    execution.  However, there are situations where it is
    desirable to exert some control over the inference:

    interactive dialog        For coherence, it is important to 
                              ask questions in a reasonable order.

    efficiency                In narrow applications, where "every action"
                              is related to finding a solution to a 
                              specific problem, it is essential
                              to follow "good" paths first in order
                              to quickly generate an answer.  

                              It is well known that the order of
                              inference can greatly impact the 
                              overall runtime.

    adaptability              For some applications, the desired rule
                              ordering changes during execution.  In
                              chess, there are several distinct phases:
                              opening; mid-game; end-game.  Many other
                              problem domains have the same pattern.
                    


2.  Types of inference control mechanisms

    Almost every system allows some sort of inference control,
    ranging from very simple to very complex.  Here is a list
    of various control schemes, simplest first:

    fixed rule order          If multiple rules are available for
                              execution, they are executed in the
                              order they were entered into the system.
                              CLIPS and many rule-based systems use
                              this mechanism.

                    Problems: rule order, which may be alphabetical,
                              categorical, or simply random, may have
                              no relation to the desired execution order.
                              Causes problems with large systems and
                              multi-file rule sets.  Rule order not
                              modifiable at runtime.


    heuristic                 There are many heuristic-based control
                              mechanisms for logic-based inference:
                              resolve the shortest clause; resolve the
                              most recent clause; etc.

                    Problems: No user control over the heuristic used.
                              Fixed heuristic not optimal in all situations.


    inheritance-based         Execute rules from the most specific set
                              first.  This is used by object-oriented
                              languages, where they give the user the
                              ability to override the default ordering.

                    Problems: Not necessarily optimal in all situations.
                              What if the problem is best solved top-down
                              (from most general to most specific?)


    rule sets                 User can activate sets of rules at runtime.
                              This handles the problem of adapting to
                              changing problem-solving situations.  
                              Algernon uses a version of this mechanism.

                    Problems: As the application grows large, the 
                              intra-set ordering problem pops up again.


    rule priorities           Priorities can be assigned to rules so that
                              they execute in a certain order.  If priorities
                              are assignable at runtime, this means that
                              the ordering can be optimized for every problem
                              and can change in response to problem-solving
                              needs.  This solves most of the problems
                              described above.

                    Problems: It is actually rule activations that need
                              to be ordered, not rules.  For example,
                              a "Travel" rule might have a high priority,
                              but the activation "Travel to Disneyland" 
                              should be rated higher than "Travel to El Paso".

                              In Algernon, before we do a query we want to
                              execute all related if-needed rules.  How do
                              we guarantee that all of them will have a
                              higher priority than the query?
                              

    dynamic prioritization    All rule activations are assigned a 
                              priority at runtime based on their
                              applicability to the current problem-solving
                              state.  This is used in blackboard systems
                              to achieve "opportunistic" reasoning.

                              In the full implementation, prioritization
                              is based on "control knowledge" that can
                              be changed at runtime, providing a fully
                              adaptable, dynamic inference control mechanism.
                              The more complex the problem being solved,
                              the more dynamic the control needs to be.

                    Problems: Figuring out what action to do next takes
                              time.  Overhead is about 25% in the most
                              efficient implementations.  
  

    The AAM implementation of Algernon has a hook so that the user
    can attach any desired rule ordering scheme, including any of the
    above.


3.  How Algernon works

    Algernon's default mechanism selects rules based on the current
    slot and frame, which is only a partial description of the current
    problem-solving state.  For example the activation clause, 

      (level Lake-Travis  ... ... ...)

    would activate rules related to 'level' and to sets Lake-Travis 
    belongs to.  The activated set of rules is then pruned via
    unification with the activation clause.  For example,

      (level Lake-Travis high ... ...)

    would only unify with (and thus activate) rules related to high
    lake levels, or rules related to all lake levels.  In the examples
    I've run, about 50% of the activated rules are pruned this way.
    Of course this number is very implementation-specific.

    Algernon's rule selection mechanism is thus a mixture of explicit 
    and implicit rule activation control.  For perspicuity, explicit 
    is better, although slower.


4.  Suggestions for Algernon

    Some combination of a default rule set ordering and rule prioritization 
    is probably appropriate for Algernon.  The AAM uses a :SELECT 
    instruction to select the next activation for execution.  The select 
    mechanism has a hook where the user can install a different mechanism
    if necessary.

    Spencer has devised a different rule caching mechanism where
    rules are cached in sets indexed by groups of classes.  For example,
    a dog "Fido" ISA (Things Objects Physical-Objects Mammals Dogs).  Thus,
    all of the rules from the five classes of Fido are grouped in one
    cache, where they are also available to "Rover" and other dogs.

    Rules would need to be ordered within the rule cache, which will
    involve some extra reasoning.  In fact, there might be a problem with
    that since at the highest level of the taxonomy, everything ISA
    everything else.  Objects ISA Sets ISA Things ISA Sets ISa Things ISA ...

    Handling new rules is easy assuming that each set has a pointer
    to every cache that it is a member of.  New rules are simply 
    propagated to the cache(s) and somehow inserted in the correct order.

    Rule deletion is very simple - visit every cache and delete the 
    rule, if it appears.

    New frames use an existing cache if possible.  If none exists, a
    rule search is performed and a cache is created.  If a frame
    gets a new ISA relation, the cache it points to is either changed
    or a new one is created.

    Slots have their own pointers to caches constructed in a similar
    fashion.

    If we can figure out how to order rules within a cache, this
    seems like a good solution.
