CAUTION: This wiki page describes code that is obsolete and no longer exists. The general ideas described here may still be current; and so this page is kept as a reference. The overall thinking and design has moved on a bit, since this point.
In this brief chapter we delve into the details of the Combo tree evaluation process. This is somewhat of a "mechanical," implementation-level topic, yet it also involves some basic conceptual points, on which OCP as an AGI design does procedure evaluation fundamentally differently from narrow-AI systems or conventional programming language interpreters. Basically, what makes OCP Combo tree evaluation somewhat subtle due to the interfacing between the Combo evaluator itself and the rest of the OCP system.
In the current OCP design, Procedure objects (which contain Combo trees, and are associated with ProcedureNodes) are evaluated by ProcedureEvaluator objects. Different ProcedureEvaluator objects may evaluate the same Combo tree in different ways.
In this chapter we will mention three different ProcedureEvaluators: the
- OpenCogPrime:EffortBasedComboTreeEvaluator, which is more complex but is required for integration of inference with procedure evaluation (a prototype of this approach was developed within the Novamente Cognition Engine, and porting to OCP would be conceptually straightforward)
- AdaptiveEvaluationOrderComboTreeEvaluator, which is necessary for robust general intelligence but has not been implemented nor designed in detail
In the following section we will delve more thoroughly into the interactions between inference and procedure evaluation.
Another issue related to procedure execution, which rose to the fore in the previous chapter, is the modularization of procedures. This issue however is actually orthogonal to the distinction between the three ProcedureEvaluators mentioned above. Modularity simply requires that particular nodes within a Combo tree be marked as "module roots", so that they may be extracted from the Combo tree as a whole and treated as separate modules, if the ExecutionManager judges this appropriate.
The SimpleComboTreeEvaluator simply does Combo tree evaluation as described earlier. When an NMAtom is encountered, it looks into the AtomTable to evaluate the object.
In the case that an NMSchema refers to an ungrounded SchemaNode, and an appropriate EvaluationLink value isn't in the AtomTable, there's an evaluation failure, and the whole procedure evaluation returns the truth value (.5,0): i.e., a zero-weight-of-evidence truth value, which is equivalent essentially to returning no value.
In the case that an NMPredicate refers to an ungrounded PredicateNode, and an appropriate EvaluationLink isn't in the AtomTable, then some very simple "default thinking" is done, and it is assigned the truth value of the predicate on the given arguments to be the TruthValue of the corresponding PredicateNode (which is defined as the mean truth value of the predicate across all arguments known to OCP)
The next step is to introduce the notion of 'effort' ' the amount of effort that the OCP system must undertake in order to carry out a procedure evaluation. The notion of effort is encapsulated in Effort objects, which may take various forms. The simplest Effort objects measure only elapsed processing time; more advanced Effort objects take into consideration other factors such as memory usage.
An effort-based Combo tree evaluator keeps a running total of the effort used in evaluating the Combo tree. This is necessary if inference is to be used to evaluate NMPredicates, NMSchema, NMArguments, etc. Without some control of effort expenditure, the system could do an arbitrarily large amount of inference to evaluate a single NMAtom.
The matter of evaluation effort is nontrivial because in many cases a given node of a Combo tree may be evaluated in more than one way, with a significant effort differential between the different methodologies. If a Combo tree Node refers to a predicate or schema that is very costly to evaluate, then the ProcedureEvaluator managing the evaluation of the Combo tree must decide whether to evaluate it directly (expensive) or estimate the result using inference (cheaper but less accurate). This decision depends on how much effort the ProcedureEvaluator has to play with, and what percentage of this effort it finds judicious to apply to the particular Combo tree Node in question.
In the relevant prototypes we built within the NCE, this kind of decision was made based on some simple heuristics inside ProcedureEvaluator objects. However, it's clear that, in general, more powerful intelligence must be applied here, so that one needs to have ProcedureEvaluators that — in cases of sub-procedures that are both important and highly expensive — use PLN inference to figure out how much effort to assign to a given subproblem.
The simplest useful kind of effort-based Combo tree evaluator is the EffortIntervalComboTreeEvaluator, which utilizes an Effort object that contains three numbers (yes, no, max). The yes parameter tells it how much effort should be expended to evaluate an NMAtom if there is a ready answer in the AtomTable. The no parameter tells it how much effort should be expended in the case that there is not a ready answer in the AtomTable. The max parameter tells it how much effort should be expended, at maximum, to evaluate all the NMAtoms in the Combo tree, before giving up. Zero effort is defined as simply looking into the AtomTable.
Quantification of amounts of effort is nontrivial, but a simple heuristic guideline is to assign one unit of effort for each inference step. Thus, for instance,
- (yes, no, max) = (0,5,1000) means that if an NMAtom can be evaluated by AtomTable lookup, this is done, but if AtomTable lookup fails, a minimum of 5 inference steps are done to try to do the evaluation. It also says that no more than 1000 evaluations will be done in the course of evaluating the Combo tree.
- (yes, no, max) = (3,5,1000) says the same thing, but with the change that even if evaluation could be done by direct AtomTable lookup, 3 inference steps are tried anyway, to try to improve the quality of the evaluation.
While tracking effort enables the practical use of inference within Combo tree evaluation, if one has truly complex Combo trees, then a higher degree of intelligence is necessary to guide the evaluation process appropriately. The order of evaluation of a Combo tree may be determined adaptively, based on up to three things:
- The history of evaluation of the Combo tree
- Past history of evaluation of other Combo tree's, as stored in a special AtomTable consisting only of relationships about Combo tree-evaluation-order probabilities
- New information entering into OCP's primary AtomTable during the course of evaluation
ProcedureEvaluator objects may be selected at runtime by cognitive schemata, and they may also utilize schemata and MindAgents internally. The AdaptiveEvaluationOrderComboTreeEvaluator is more complex than the other ProcedureEvaluators discussed, and will involve various calls to OCP MindAgents, particularly those concerned with PLN inference.