Atomspace-MOSES -- planning

[Ben Goertzel]

Nil,

I'm thinking about moving forward with creating an Atomspace-based
version of MOSES, with the work perhaps being split between Alexey's
team in St. Petersburg and Kasim and Yidne's team in Addis Ababa...

You are of course aware that Yidne has been working on porting Reduct
to the URE ... which is in a way the "hard part" of porting MOSES to
Atomspace

As I mentioned before, the general design I'm thinking of is

-- make a MOSES version where each MOSES deme is an Atomspace

-- keep the rest of MOSES as-is ... i.e. the deme management, the
feature selection, etc. etc.

So basically the actual collection of program trees being grown inside
a deme (extending an exemplar) would live in an Atomspace....

For a given MOSES "run", one could perhaps have one central Atomspace
accumulating the top N programs from each of the peripheral
Atomspaces, where each deme is a peripheral Atomspace....

Fitness evaluation should not be tricky here, basically a fitness
function can be a GroundedSchemaNode

Nil, my basic idea here (as we discussed once before) is that the
growth of an exemplar program into various "derived" programs (as
occurs within a MOSES deme) should be executable using a URE rule (or
a small number of URE rules) ....

I am thinking that your recent work on the URE Pattern Miner, should
put you in a position where you can clearly articulate how to use the
URE to implement the growth of a population (deme) of programs from an
exemplar program...

(Obviously the big intended payoff here is a return to the roots of
MOSES, i.e. the use of probabilistic analysis to find patterns
regarding which program-trees in a deme are successful. I would like
to be able to use pattern mining and PLN to help with this, and this
will be much easier to experiment with once the MOSES program trees
are in the Atomspace.... But I'm not looking to implement/design the
details of this aspect yet; first I want to just deal with the
"mechanics" of getting a MOSES deme to be an Atomspace...)

Anyway what I am hoping is that you can write a sort of spec for "how
to use the URE to implement the growth of programs from the exemplar
in a MOSES deme" .... if you can viably do this before we meet F2F
in HK in March that would be ideal for spurring discussions and moving
the idea to the next stage...

(A note to others: It is clear that the mechanics of MOSES program
execution will be slower in the (current version of the) Atomspace
than in the current version of MOSES. However, the Atomspace brings
with it other possibilities, including the caching of partially
evaluated results, as well as easier probabilistic modeling as
mentioned above.... And of course we can cook up various schemes for
accelerating Atomspace program execution if we want to. Generally
though I am thinking the value-add of Atomspace-MOSES will occur
mostly for cases where fitness evaluation is highly expensive for
reasons other than having a large number of simple operations carried
out in the program tree, e.g. where the bulk of time that the program
spends is in manipulation of Atoms or manipulation of external data,
in which cases the slower mechanics of program tree evaluation in
Atomspace as opposed to VertexTrees doesn't matter...)

thanks
Ben

thanks
Ben



--
Ben Goertzel, PhD
http://goertzel.org

"In the province of the mind, what one believes to be true is true or
becomes true, within certain limits to be found experientially and
experimentally. These limits are further beliefs to be transcended. In
the mind, there are no limits.... In the province of connected minds,
what the network believes to be true, either is true or becomes true
within certain limits to be found experientially and experimentally.
These limits are further beliefs to be transcended. In the network's
mind there are no limits." -- John Lilly

[Linas Vepstas]

On Sat, Feb 10, 2018 at 8:55 AM, Ben Goertzel <b...@goertzel.org> wrote:

You are of course aware that Yidne has been working on porting Reduct
to the URE

? There does not seem to be any activity on github that would suggest
such work is underway.  I strongly urge that work not be carried out in

some private corner, and then revealed to the world as a fait-accompli.

 

Fitness evaluation should not be tricky here, basically a fitness
function can be a GroundedSchemaNode

Umm, fitness evaluation is "trickier" than reduct.  It is the the primary
bottleneck in moses. Moshe created a lot of technology to make this
go fast. Nil also devoted a huge amount of time and attention on this.

Reduct might feel difficult, because if you just glance at the code, it

obviously looks arcane.  The fitness evaluation code looks like it's

easy by comparison.  This is highly misleading.  Computer software

has a kind of inversion effect, where often it is the easiest-looking
things that are the hardest.  Do not be fooled about where the actual

complexity lies.

 

(Obviously the big intended payoff here is a return to the roots of
MOSES, i.e. the use of probabilistic analysis to find patterns
regarding which program-trees in a deme are successful. 

Well,some caution is needed to visualize what is really happening here.

You have that probabilistic analysis already available now: you can

easily extract a measure from a collection of program trees, in several
different ways. That measure is fractal;  don't imagine that its smooth.

I just now wrote, and then deleted a long email on the actual technicalities

and experience of doing this by hand.  The general upshot is that its a lot

more subtle than what one might imagine.  The notion of "returning to the
roots of MOSES", is I feel, exactly the wrong direction to go in: we moved

away from those roots for a reason, and got a much stronger, faster and
more robust system as a result.

Let me put it this way: asking "which program-trees in a deme are successful"

is kind of like asking "which neurons in a neural net are successful", or "who
are the John Galts of society"  This is like focusing on the point dynamics
in a fractal -- it identifies a set of measure zero, giving a completely faulty
understanding of the fractal (dynamical system)  The system dynamics is
governed by measures, not by individuals.  The individuals are the exception.

MOSES is more accurate, the larger the population. Having 1000 exemplars

will give you far more accurate answers, than what you'd get if you tried to

trim this to the top-10 most successful.    Put another way: ten super-accurate,

highly-evolved expert trees are less accurate than the democratic vote of
1000 simple-minded average joes,  when yo just want an answer for a "typical"
dataset.

Linas.

--

cassette tapes - analog TV - film cameras - you

[Ben Goertzel]

Hi,

***

? There does not seem to be any activity on github that would suggest
such work is underway. I strongly urge that work not be carried out in
some private corner, and then revealed to the world as a fait-accompli.

***

Yidne has been working closely with Nil on this, e.g. see

https://github.com/Yidnekachew/atomspace/tree/implement-involution-reduction-using-ure

Basically what he's done so far is get the involution reduct rule
working in Atomspace...

Most of the work involved Yidne learning to make tweaks to PM and URE ...

We are taking the approach suggested by Nil long ago, of making the
Reduct rules correspond
to algebraic properties rather than to operators, e.g. there's a
commutation Reduct rule,
an involution Reduct rule, an association Reduct rule, etc.

You can discuss w/ Nil in depth obviously...

-- Ben

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/CAHrUA36Qu8SR55YZGKu460c2QZnJDOC3tMyYZ%3D1g%3DSPZvSBG6g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Ben Goertzel]

Hey,

***

Let me put it this way: asking "which program-trees in a deme are successful"
is kind of like asking "which neurons in a neural net are successful", or "who
are the John Galts of society" This is like focusing on the point dynamics
in a fractal -- it identifies a set of measure zero, giving a completely faulty
understanding of the fractal (dynamical system) The system dynamics is
governed by measures, not by individuals. The individuals are the exception.

MOSES is more accurate, the larger the population. Having 1000 exemplars
will give you far more accurate answers, than what you'd get if you tried to
trim this to the top-10 most successful. Put another way: ten super-accurate,
highly-evolved expert trees are less accurate than the democratic vote of
1000 simple-minded average joes, when yo just want an answer for a "typical"
dataset.

***

yes, I'm certainly all in favor of ensemble methods... as you'll
recall that's what
we are doing with our current practical applications of MOSES (to genomic
data analysis), and also what we were doing in our prior applications of MOSES
to financial prediction...

I was typing late at night while exhausted -- in hindsight,
a better phrasing would have been not "which program-trees in a deme
are successful" but rather "which patterns of dependency characterize
the program trees in a deme that are major contributors to the program
tree ensemble"

I would add though, this ensemble business is trickier when the programs are
doing stuff like, say, sorting lists or controlling movements of a
robot, rather than
say making classification judgments. It's easy to let a bunch of
programs vote
on whether patient 55's DNA is in Cancer or Control, but trickier to let a bunch
of navigation programs vote on what direction a robot should move next....
(Because some programs might have a misconception about how or why
the robot got to its current interim location, guided there by other programs
in the ensemble...)...

So there is an awful lot still to be experimented with, but I would
rather have this
experimentation happen in the Atomspace than in a standalone MOSES codebase
(and I note that this experimentation has *not* really been happening
in the standalone
MOSES codebase... since Aidyia stopped doing MOSES R&D, there hasn't been
any innovation happening in the guts of MOSES, though we have been using MOSES
for bio analytics and other stuff....) ....

-- Ben


On Sun, Feb 11, 2018 at 2:33 AM, Linas Vepstas <linasv...@gmail.com> wrote:
>
>

> --
> You received this message because you are subscribed to the Google Groups
> "opencog" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to opencog+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> Visit this group at https://groups.google.com/group/opencog.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/opencog/CAHrUA36Qu8SR55YZGKu460c2QZnJDOC3tMyYZ%3D1g%3DSPZvSBG6g%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Nil Geisweiller]

Yeah, "returning to the roots with probabilistic analysis" can be very
promising if done well, like taking into account

1. uncertainty in model building
2. background knowledge

also enabling cross-deme (ultimately cross-problem) modeling.

That doesn't mean we have to scratch all the goodies of existing MOSES,
like stochastic hill-climbing and cross-over/merging.

Maybe attempting to take a more modular approach, a la cogistry, to
enable a finer level of meta-learning could be good as well.

Anyway, lots to explore.

Nil

[Nil Geisweiller]

On 02/10/2018 04:55 PM, Ben Goertzel wrote:
> Nil, my basic idea here (as we discussed once before) is that the
> growth of an exemplar program into various "derived" programs (as
> occurs within a MOSES deme) should be executable using a URE rule (or
> a small number of URE rules) ....
>
> I am thinking that your recent work on the URE Pattern Miner, should
> put you in a position where you can clearly articulate how to use the
> URE to implement the growth of a population (deme) of programs from an
> exemplar program...

I see. It seems composing the exemplar with codelets (if that's the
right term, I mean small pieces of code) via PutLink, like for the URE
pattern miner, would work.

It would be cool if candidate growth can be seen as proof of its fitness
estimation, which I think might come out naturally of that approach.

> Anyway what I am hoping is that you can write a sort of spec for "how
> to use the URE to implement the growth of programs from the exemplar
> in a MOSES deme" .... if you can viably do this before we meet F2F
> in HK in March that would be ideal for spurring discussions and moving
> the idea to the next stage...

Sure. Maybe I should prepare a few slides as well, about the URE, its
inference control so far, the URE pattern miner so far, and MOSES
as-it-could-be.

Nil

[Ben Goertzel]

>> I am thinking that your recent work on the URE Pattern Miner, should
>> put you in a position where you can clearly articulate how to use the
>> URE to implement the growth of a population (deme) of programs from an
>> exemplar program...
>
>
> I see. It seems composing the exemplar with codelets (if that's the right
> term, I mean small pieces of code) via PutLink, like for the URE pattern
> miner, would work.

Yes ...

> It would be cool if candidate growth can be seen as proof of its fitness
> estimation, which I think might come out naturally of that approach.

Interesting...

>> Anyway what I am hoping is that you can write a sort of spec for "how
>> to use the URE to implement the growth of programs from the exemplar
>> in a MOSES deme" .... if you can viably do this before we meet F2F
>> in HK in March that would be ideal for spurring discussions and moving
>> the idea to the next stage...
>
>
> Sure. Maybe I should prepare a few slides as well, about the URE, its
> inference control so far, the URE pattern miner so far, and MOSES
> as-it-could-be.

Yes, makes sense...

thx
ben

[Racer Rob]

Is there documentation on where Aidyia left off with MOSES R&D?

Nil,
Your presentation on URE and MOSES would be very interesting.

Rob