AtomSpace MOSES port (part II)

[ngeiswei]

Overview

This is a continuation of opencog#3. In this part we will tackle the following tasks:

• Store deme populations on AtomSpaces.
• Port remaining (beside logical_bscore) fitness functions to
  Atomese.
• Port unit tests to cover the ported fitness functions.

Population as AtomSpace

Motivation

Let's first recall why we want that:

1. Avoid duplicates of sub-programs, due to Atoms being uniquely
   represented in the AtomSpace. This may save some RAM.

2. Avoid re-evaluating sub-programs, by using memoization as described
   in issue Subprogram Memoizer opencog/asmoses#17. This may
   save some CPU (at the expense of the lot of RAM due to storing
   intermediary results).

3. Longer term, yet worth recalling. Mine patterns, or generally apply
   OpenCog cognitive processes over program populations (and
   meta-populations) to discover goodness of fit patterns. MOSES
   traces could eventually stored as well to discover patterns to
   guide MOSES in various manners but that another issue.

Plan

The type deme_t defined in

https://github.com/singnet/as-moses/blob/master/moses/moses/optimization/optimization.h#L170

and used in

https://github.com/singnet/as-moses/blob/master/moses/moses/optimization/hill-climbing.cc#L231

actually defines deme of instances, that is vectors of knob
settings. While what we want are demes of atomese programs. For
simplicity I suggest to locate such AtomSpace within the fitness
function itself, more specifically in atomese_based_scorer. So the
steps would be

• Add AtomSpace member to atomese_based_scorer.
• In atomese_based_scorer::operator(), before evaluating the
  program via calling _cscorer.get_cscore(handle), add it in the
  atomspace.

The reason it should be added before evaluation is to take advantage
of the memoization mechanism implemented in the customed atomese
interpreter and thus, a fortiori, in get_cscore.

In addition

• A MOSES flag (documented in moses --help) should be added to
  enable or disable storing programs in the atomspace of
  atomese_based_scorer, to easily compare the benefits vs costs
  of storing candidates in an atomspace.

So for now there will be only one AtomSpace for all demes. We may
revise that in the future, or perhaps associate demes to program
candidates which could be useful to find patterns for isolated demes
or such.

Port remaining fitness functions to Atomese

Motivation

At this stage we would want to experiment with most, if not all,
fitness functions to compare Atomese vs Combo. To see if everything
rolls well and compare the efficiency of the Atomese port so far.

Plan

You'll have to search for all classes inheriting bscore_base and
overload behavioral_score operator() to support Handle like you
did with logical_bscore. Do not hesitate to refactor the fitness
code to avoid redundancies when possible.

Port unit tests

Motivation

To quote egervari: "you don't have to spend every night coding to 11pm"

(if you're curious, see
https://stackoverflow.com/questions/2760348/unit-testing-and-motivation-to-do-so#2760376
for his full answer.)

Plan

For all ported fitness functions, corresponding unit tests should be
created. Since MOSES is fairly well tested/covered, most of the time
you'll only need to duplicate some existing unit tests.

Under

<AS-MOSES-ROOT>/tests/moses

look for the function calls

• moses_test_score
• moses_test_good_enough_score
• moses_test_combo
• cheap_moses_test_combo,
• moses_test_scored_combo_trees
  It is likely you'll have to port all unit tests that call one of
  these.

For instance, in MOSESUTest.cxxtest, the following

    void test_2_parity() {
        cout << BOOST_CURRENT_FUNCTION << endl;
        moses_test_score({"-Hpa", "-k2"});
    }

should be complemented with

    void test_2_parity_as() {
        cout << BOOST_CURRENT_FUNCTION << endl;
        moses_test_score({"-Hpa", "-k2", "--atomspace=1"});
    }

where --atomspace=1 would be an option in the moses executable that
enables all ported code, including outputting program candidates in
Atomese by default.

Note that the following functions

• moses_test_combo
• cheap_moses_test_combo
• moses_test_scored_combo_trees
  should also be ported/complemented as
• moses_test_atomese
• cheap_moses_test_atomese
• moses_test_scored_atomeses.