Go backward to Preference processing.
Go up to Preference processing.
Preference semantics
--------------------
In processing the preferences, the decision procedure assumes that only a
single value can be selected for an augmentation, that is, all values are
mutually exclusive. Only through parallel preferences can multiple values
arise, and then only for non-context slot augmentations. In addition, there
is no implicit transitivity in the semantics of preferences. If A is
indifferent to B, and B is indifferent to C, A and C will not be indifferent
to one another unless there is a preference that A is indifferent to C (or C
and A are both unary indifferent).
The semantics of the preferences are implemented by a series of generators of
candidate selections and a set of filters that remove candidate objects from
consideration. Reconsider is an exception in that it is a signal to run the
decision procedure and has no influence on the outcome. In this section, the
semantics of each type of preference is described, independent of this
process. This is followed by a detailed description of the preference
processing, which is the final word in the meaning of the preferences.
[Reconsider (@)] A reconsider preference states the decision for a
context augmentation should be reconsidered, that is, it should be
recomputed with the available preferences at quiescence. A reconsider
preference is necessary for changing an existing decision for a context
slot, such as terminating an operator or selecting a new problem space.
Reconsider is only meaningful for context slot augmentations.
[Require (!)] A require preference states that the value must be selected if
the goal is to be achieved. If a value has a require preference, it
will be selected unless there is another value with a require
preference, or the same value also has a prohibit preference. In these
latter two cases, a *constraint-failure* impasse arises (see Section
See Impasses and subgoals (syntax) on page *Note Impasses and
subgoals (syntax)::). A production creating a require preference is
included in the traces used by chunking (see Section *Note Determining
conditions and actions:: on page *Note Determining conditions and
actions::).
[Prohibit (~)]
A prohibit preference states that the value cannot be selected if the
goal is to be achieved. If a value has a prohibit preference, it will
not be selected for a value of an augmentation, independent of the other
preferences. It differs from reject in two ways: it can not be
overridden by a require preference, and it will be included in the
production traces built c up for chunking (see Section *Note Determining
conditions and actions:: on page *Note Determining conditions and
actions::). If there is a prohibit preference and require preference
for the same value, a {constraint-failure} impasse arises (see Section
See Impasses and subgoals (syntax) on page *Note Impasses and
subgoals (syntax)::).
[Acceptable (+)] An acceptable preference states that a value is a candidate
for selection. All values, except those with require preferences, must
have an acceptable preference in order to be selected. If there is only
one value with an acceptable preference (and none with a require
preference), that value will be selected as long as it does not also
have a reject or a prohibit preference. If there is more than one value
with an acceptable preference, and no reject or prohibit preferences,
the worse, better, best, worse, parallel, and indifferent preferences
are used to determine the selection. A production creating an
acceptable preference is included in the traces used by chunking (see
Section See Determining conditions and actions on page
See Determining conditions and actions).
[Reject (-)] A reject preference states that the value is not a
candidate for selection. If a value has a reject preference, it will
not be selected unless there is also a require preference for that
value. A reject preference and an acceptable preference do not cause an
impasse; the reject dominates.
[Better (>), Worse (<)] A better or worse preference states, for the
two values involved, that one value should not be selected if the other
value is a candidate. Better and worse allows for the creation of a
partial ordering between candidate values. Better and worse are simple
inverses of each other, so that A better than B is equivalent to B worse
than A. A value will not be selected if it is worse than another
acceptable value that has not been rejected or prohibited (and there are
no require preferences for the given value). If such an acceptable
value is better than a second, and the second is better than the first,
there is a *conflict* impasse. The conflict can be broken by rejecting,
prohibiting or requiring one of the two values. If there is no conflict
and there is a single value that is not worse than some other value,
that value will be selected, independent of any best, worst, parallel,
or indifferent preferences.
[Best (>)] A best preference states that the value is good enough to
select. If a value is best (and not rejected, prohibited, or worse than
another), it will be selected over any other value that is not also best
(or required). If two such values are best, then the remaining
preferences (worst, parallel, indifferent) will be examine to determine
the selection. If a value (that is not rejected or prohibited) is
better than a best value, the better value will be selected. (This
result is counter-intuitive, but allows explicit knowledge about the
relative worth of two values to dominate knowledge of only a single
value. A require preference should be used when a value *must* be
selected for the goal to be achieved.)
[Worst (<)] A worst preference states that the value should be selected
only if there are no alternatives. It allows for a simple type of
default specification. If a value is worst (and not rejected,
prohibited, or worse than another), it will not be selected unless there
are no other similar non-worst (or required) values. If two such values
are worst, then a tie impasse will arise. If a value is both worst and
best, it will be selected over all worsts. If there are other bests that
are not worst, it will not be selected.
[Indifferent (=)] An indifferent preference states that there is
positive knowledge that it does not matter which value is selected. If
the preference is unary, then the value is considered to be indifferent
to all other values with a unary indifferent preference. Its effect is
to break a tie between candidate values that have no other preferences
to distinguish between them. If there are not sufficient indifferent
preference to break such a tie, then a *tie impasse* arises. The exact
mechanism for selecting between indifferent values is determined by the
function user-select (see Section See user-select {X} on page
See user-select {X}).
[Parallel (&)] A binary parallel preference states that two values are
not mutually exclusive. Therefore, if other values do not dominate
these values through additional preferences, they will both become
values of the augmentation. This can be extended to any number of
values, as long as they are all mutually parallel; however, there is no
implicit transitivity of parallelism, so each pair of values must be
parallel. A unary parallel preference states that a value is not
mutually exclusive of any value that also has a unary parallel
preference. Parallel preferences cannot be used for context objects.
The preference semantics has nine filter-like operations (see Figure ?) that
are executed in order to determine the correct values for the working memory
slot. Figure ? should be read starting at the top left where all the values
for a slot are collected and passed to the first filter. Each filter reduces
the number of preferences that need to be considered. If a conflict is found
then an impasse is generated and the filtering process is halted. The impasse
generation is handled as a special exit from a filter and is indicated with a
grey line in Figure ?. Preference semantics requires an input slot, and
produces an impasse, a possibly empty set of conflicting, indifferent or
parallel items and a flag, number. The set of possible values for the slot is
called the candidates. The numberflag is set whenever there is a winning
value, e.g., there is not an impasse. If a single winner is chosen or there
are a set of mutually indifferent winners, numberis 1. If all of the winners
are mutually parallel, then numberis All. This allows the decision procedure
to distinguish a set of mutually parallel candidates that should all be
installed in working memory from a set of mutually indifferent candidates
that should have only one value installed or maintained.
Each filter in Figure ? is described below:
RequireFilter (!)
This filter checks for required candidates in preference memory and also
constraint failure impasses involving require preferences (see Section
See Impasses and subgoals (syntax) on page *Note Impasses and
subgoals (syntax)::).
* If there is exactly one require preference for the slot in memory
and there is no prohibit preference for it in preference memory,
then its value is the winner numberis set to 1 and preference
semantics terminates.
* Otherwise -- If there is more than one required candidate, then a
constraint failure impasse is recognized with all of the required
items in the items set, and preference semantics terminates.
* Otherwise -- If there exists a required value that is also
prohibited, a constraint impasse with the required/prohibited value
is recognized and preference semantics terminates.
* Otherwise -- The candidates are passed to the AcceptableFilter.
AcceptableFilter (+)
This filter removes the candidates that do
not have acceptable preferences in memory.
* If there are no acceptable preferences in memory for the slot then
exit preference semantics with no items picked. This is an
efficiency termination.
* Otherwise -- The candidates are passed to the ProhibitFilter.
ProhibitFilter (~)
This filter removes the candidates that
have prohibit preferences in memory. The rest of the candidates are
passed to the RejectFilter.
RejectFilter (-)
This filter removes the candidates that have
reject preferences in memory. The rest of the candidates are passed to
the BetterWorseFilter.
BetterWorseFilter (>), (<)
This filter checks for better
worse conflicts, and otherwise filters out candidates based on
better/worse preferences.
* If there are better/worse conflicts, set the items to be all of the
candidates involved in the conflicts. Declare a conflict impasse
and terminate preference semantics.
* Otherwise -- It filters out of the candidates the ones that have
another preference that is better, or are worse than another
preference. The resulting candidates are passed to the BestFilter.
BestFilter (>)
This filter removes any candidates that do not have
a best preference in memory. If there are no best preferences in memory
for any of the current candidates, the entire old set of candidates is
passed on to the WorstFilter.
WorstFilter (<)
This filter removes any candidates that have
a worst preference in memory. If all the current candidates have worst
preferences in memory the entire old set of candidates is passed on to
the IndifferentFilter.
IndifferentFilter (=)
This filter returns them as indifferent.
If they are not, and this is a context impasse slot, a tie impasse is
declared and preference semantics terminates.
* If the candidates are all mutually indifferent terminate preference
semantics with all of the candidates in the item set and set
numberto one. The calling routine then selects one of the
indifferent candidates.
* Otherwise -- If the non-mutually indifferent candidates are for
context slots generate a tie impasse, with all of the candidates as
items, not just those that are not mutually indifferent.
* Otherwise --
The candidates are passed to the ParallelFilter.
ParallelFilter (&)
If all of the remaining candidates are mutually
parallel, they're returned as mutually parallel. Otherwise, a tie
impasse is returned. A candidate is mutually parallel to the set of
other candidates if it has a unary parallel preference, or if it has
either of the two possible relative parallels between each candidate.
* If all of the candidates are mutually parallel terminate preference
semantics with all of the candidates in the item set and set
numberto All.
* Otherwise -- Generate a tie impasse with all the non-mutually
parallel candidates in the item set.