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
On 02/11/2018 05:29 AM, Ben Goertzel wrote:
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 <[email protected]> wrote:
On Sat, Feb 10, 2018 at 8:55 AM, Ben Goertzel <[email protected]> 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
--
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 [email protected].
To post to this group, send email to [email protected].
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.
--
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 [email protected].
To post to this group, send email to [email protected].
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/b802300a-843e-d46f-d06c-bf11d460cf89%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
