AtomSpace MOSES port (part III)

[ngeiswei]

Overview

This is the last part of the AS-MOSES port before reaching the first milestone. At the end of this iteration the user should be able to run asmoses from begin to end using only Atomese as learning language.

As far as I can tell they are 3 places that still require atomese port

• Reduct
• Metapopulation
• Representation building

Reduct

A related issue has already been created on the opencog/as-moses repo opencog#21 and some work has already started https://github.com/kasimebrahim/as-moses/tree/UREreduct-initial

To sum up/complement that issue

Use ReducedToLink to represent the reduction relationship between a given rule, a candidate and its reduction, as follows

   ReducedTo
     <rule>
     <candidate>
     <reduced-candidate>

where <rule> can be a simple rule like flattening an associative expression, or a complex rule involving combining multiple rules. This way one would be able to build reduction strategy similar to what is
done in combo-reduct, and express consctructs like

Repeat reducing with a given set of rules till a fixed point is reached.

Representing both reduction rules and reduction strategies in that manner should ultimately enable us to learn these.

Possible Intermediary Step (wrapping combo-reduct)

Porting each rule is gonna take a while. In the meantime one could create a few rule wrappers around the existing combo-reduct engine for the main reductors, namely
https://github.com/singnet/as-moses/blob/master/opencog/reduct/reduct/logical_reduction.cc
https://github.com/singnet/as-moses/blob/master/opencog/reduct/reduct/contin_reduction.cc
https://github.com/singnet/as-moses/blob/master/opencog/reduct/reduct/mixed_reduction.cc
https://github.com/singnet/as-moses/blob/master/opencog/reduct/reduct/full_reduction.cc
which would simply convert the atomese program into combo and call regular combo-reduct, convert the reduced combo program back to atomese and create a resulting ReducedToLink.

URE-Reduct Prerequisites

They are about 90 combo reduct rules, and although some of them are redundant can could be replaced by generalization (like considering algebraic properties instead of operators), that still constitute a large number of rules to port.

Porting from C++ rule to the URE should be hopefully simplified by the fact that pattern matching programming paradigm can be used, thanks to the pattern matcher and the unifier. However the URE has some deficiencies we want to address first. For instance GlobNode is not supported https://github.com/opencog/atomspace/issues/2010 which makes writing rules for operators with arbitrary number of arguments (+, *, etc) cumbersome. Likely more deficiencies will be discovered in the process.

Metapopulation

The goal is to have the metapopulation represented in an atomspace.

Ultimately, we want to be able to reason about the probability of success of selecting an exemplar, and thus represent the metapopulation almost entirely as atomspace data. For now however, I suggest to keep the algorithms in charge of storing references of the candidates, such as metapopulation::merge_nondominated and selecting the next exemplar, such as metapopulation::select_exemplar() untouched, and merely port them to support atomese.

So they atomese candidates would be stored in a dedicated C++ structure (the equivalent of metapopulation::_scored_trees for atomese) as well as in an atomspace (probably an attribute of metapopulation such as metapopulation::_as). Although the atomspace will barely be used for now though sub-program memorization may still turn out to be useful at this step), it is good to introduce it now for the subsequent iterations.

Representation Building

An issue #57 has already been defined for that task. I'm just restating it with a slightly different angle and distance.

So the selected exemplar is decorated with knobs, the various combinations of knob settings (knob positions) defines a program subspace surrounding that exemplar. Candidates in that space are represented as sequences of knob settings, called instances, instead of explicit programs. Then instances are turned into programs.

There 2 main steps requiring port

1. Representation building
2. Convert instance into programs

Step one requires requires to overload the class build_knobs to support atomese, including its constructor and subsequent methods. It's not entirely clear to me whether we want to directly overload the constructor and methods, or we want to refactor that code into some base class and 2 derived classes, one for combo, one for atomese. I guess we'll know by doing.

Step two requires to overload the class representation to support atomese, including its constructor and subsequent methods. Again, not entirely sure how to best use object oriented programming paradigm.

Beyond the port

Once this iteration completed, we should be able to start focusing on research, in particular create synergies between learning and reasoning. What will be done exactly remains to be determined but it could involved, among other things, reformulating hard decisions (such as selecting the next exemplar) as atomese knowledge, so that reasoning, or any form of learning that is enabled by OpenCog (including AS-MOSES) can be used to improve the probability estimate of the outcome of such decision. As it is very reminiscent to what inference control is doing, it could probably be framed as an inference control problem.