make examples fails for target trap-uni

[gl-yziquel]

I guess this is an instance of bit rot.

mini-me@virtucon ~/h/c/m/build (master)> make examples
Consolidate compiler generated dependencies of target trap-uni
[93%] Building CXX object examples/example-progs/CMakeFiles/trap-uni.dir/trap-uni.cc.o
/home/mini-me/home/cellar/moses/examples/example-progs/trap-uni.cc:97:44: error: ‘_1’ was not declared in this scope
   97 |                     bind(&trap::vee, this, _1)),
make[6]: *** [examples/example-progs/CMakeFiles/trap-uni.dir/build.make:76: examples/example-progs/CMakeFiles/trap-uni.dir/trap-uni.cc.o] Error 1
make[5]: *** [CMakeFiles/Makefile2:3159: examples/example-progs/CMakeFiles/trap-uni.dir/all] Error 2
make[4]: *** [Makefile:156: all] Error 2
make[3]: *** [CMakeFiles/examples.dir/build.make:71: CMakeFiles/examples] Error 2
make[2]: *** [CMakeFiles/Makefile2:982: CMakeFiles/examples.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:989: CMakeFiles/examples.dir/rule] Error 2
make: *** [Makefile:228: examples] Error 2
mini-me@virtucon ~/h/c/m/build (master) [2]>

[linas]

Yes. It is fairly easy to fix: use #include <boost/bind/bind.hpp> instead of #include <boost/bind.hpp> and then write boost::placeholders::_1 instead of the naked _1

However, I'm not fixing this: I see other warnings during the compile, and I'm not ready to single-handedly maintain this. Anyway, more or less everything in MOSES is now in as-moses, which is still maintainable. So MOSES should now be considered deprecated/obsolete.

I'll merge pull reqs, though, if you provide them.

[gl-yziquel]

Thanks.

I'll see if I find time to provide such pull requests. Unlikely, but nonetheless possible. Depends.

[gl-yziquel]

Hmmmh.... not quite: it seems that my code is reference boost/mpl/bind.hpp. gcc -H seems to tell me that this is pulled via opencog/util/functional.h, itself pulled by opencog/util/selection.h.

I wouldn't be too surprised if this were due to cogutil having evolved over time away from the runtime boost bind to the compile time boost mpl bind.

[linas]

I've cleaned up many of the problems in pull req #107

However, I suggest focusing on as-moses, as that is the next-gen version of this code base.

[linas]

Works for me.

[gl-yziquel]

I confirm that this fixes the issue.

It's been a few times you told me to switch to asmoses. So I'll address the implicit assumption behind that:

I am interested in moses because I am reading the documentation of various opencog stuff in a historical perspective, much like I do for many other things. I therefore wish to have handy the softwares that are referenced in the old docs of opencog. For instance, I need to understand how the AtomSpace developed from the AtomTable and Combo. So I'll keep working on these old pieces of code for various reasons such as this one.

I'm not asking you to maintain them.

When I'll be able to fix something, I'll try.

But, for the moment, given the complexity of entering into the opencog codebase, I do not consider it dumb or heretical to try to get old code to resurrect if that is what is needed to get some perspective.

If I'd need to compile some SNOBOL4, I'd compile some SNOBOL4.

[linas]

Well, if you want to ask questions, I can act as a guide. Yes, the codebase is complex; but the general basic principles are not that hard. Let me try an informal summary here, for MOSES.

• Reading through Moshe Looks PhD thesis is worthwhile, and not that hard.
• The core idea is that, given a table of inputs and an output column, one can train a collection of https://en.wikipedia.org/wiki/Abstract_syntax_tree AST that couple together the input columns to generate the data in the output column.
• The general idea, and it's efficiency, and accuracy etc. is very similar to what are called "random forest models" in AI textbooks. The "forest" is just a collection of AST's.
• What makes MOSES different from other implementations of the random-forest model are the details of the implementation. Those details are worth understanding, if you're going to use the system, apply it in some problem. However, reading the actual code base ... phew. Standard laws of software apply, which includes avoiding obsolete code.

That's it. If you don't know what "random forest models" are, you should look at that topic.

• MOSES represented the AST as "combo trees" using a lisp-like syntax. Which is a generic idea in lisp. And in compiler internals. For example, gcc uses an "intermediate language" deep inside its guts, that looks like lisp (because its an abstract syntax tree) but is assembly language-like (because it will be compiled down to assembly.)
• The problem is that more exactly zero existing systems provide generic AST manipulation tools. All LISP's hide the implementation details. GCC hides it and custom-tailors it for compiling. Anti-virus tools have disassemblers, but they are custom-tailored. None of allow an AST to be saved to disk, to be restored, to be searched for.
• Thus, Moshe had to invent his own: he called it "combo".
• At the same time, AtomSpace was being developed: it provides generic AST tools. (Beats the heck out of me where you found AtomTable: its freakin pre-historic, and all references to it should be nuked.)

And so, here we are, in modern times:

• The idea of as-moses was to surgically remove combo trees, and replace them by atomspace trees. Otherwise, its effectively the same thing. In particular, the unit tests are the same.
• The actual result is a bit Frankensteinian: the as-moses code base still has combo inside it, in parallel to the atomspace. It was never removed. There are other rough edges that never healed from the surgery. But, other than that, it really is "the same thing".

As to the future:

• I am very interested in splitting up as-moses into 3 or 4 distinct technical pieces, because they are generically useful, outside of the MOSES framework. These are: -- The knob-turning subsystem -- the deme management subsystem -- the reduct subsystem -- The scoring algos, hillclimbing, cross-over etc. code. -- the table I/O code.

• Why? I want to work with non-tabular data. I want other things besides reduct. I want different kinds of scoring. And I want to manage collections of demes, outside of the framework of MOSES.

All that is a generic software maintenance issue: modular code, small, maintainable pieces, each subsystem is easier to understand, but-fix, unit-test, enhance. OpenCog is not magically exempt from standard laws of software development.

Anyway .. there we are...

[linas]

Oh, huh. I lied. I mis-spoke. I just skimmed https://en.wikipedia.org/wiki/Random_forest and ... well, MOSES is not that. There are a lot of similarities between MOSES-style combo trees, for combining inputs, and the "decision trees" used in random forest models. But there are also stark differences. So:

• Combo trees are NOT decision trees! Combo trees combine inputs algebraically. Decision trees give yes/no answers. The effect is similar; the details are quite different.
• Neither MOSES nor AS-moses contain a complete set of forest management tools. Those are elsewhere, in a collection of python scripts. They are (were) great, but have bit-rotted. They need to be re-developed and made generic.