On 12/09/2016 08:26 PM, Ben Goertzel wrote:
EXPANDED PATTERN MINER ALGORITHM Incorporating these ideas, the unified/expanded pattern miner algorithm would look like: * Start with an ensemble of simple hypergraphs, constructed according to template T (which is itself represented as a hypergraph) * Iterate through the hypergraphs H in the ensemble, expanding each hypergraph H into a set of larger hypergraphs, by applying an expansion template T1 to some Atoms within H. T1 is a pattern with variables, and some of the variables in T1 are bound to Atoms in H whereas others are bound to other Atoms not in H.
Interesting. So the way I see it is that you start from a general pattern T. You find atoms that meet that pattern, based on these atoms you refine T into T1, or perhaps rather an ensemble of T1s, right?
You do need a scheme that defines how you go from T to T1 though, what is called knob/representation building in MOSES, right? Would be cool if such scheme can be coded as a BindLink or something like that.
EFFICIENCY OPTIMIZATION The “plumbing” of this MOSES implementation would be slower than that of the current MOSES, because the evaluation of each program-tree (each pattern) would use the Atom formalism. However, this could be optimized, as a later implementation step, if it appears necessary. The way to optimize it would be to maintain a faster, non-Atom-based version of the H-Graph, which is optimized for rapid evaluation of the sub-hypergraphs in the H-Graph. When an expanded pattern is added to the H-Graph, a corresponding expanded pattern must be added to the optimized H-Graph. There would be some overhead in this scheme, but if the fitness function involved (e.g.) repeated execution of patterns against some dataset, the overhead would be worth it. The formalism of linking executable subhypergraphs of the Atomspace to optimized versions would be more broadly useful. (Possibly, the optimized H-Graph structure could simply be built using the VertexTrees used in the current MOSES implementation.)
It was clear to me whether using the AtomSpace as working DB for the evolving trees would speed up or slow down MOSES. One thing that could speed it up is enabling memoization at the subtree level, as opposed to the tree level as in MOSES. Seemingly ProtoAtoms could be used as a cache memory over subtrees. Who knows what kind of speed up that may yield?
Nil -- 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/5c06cb1a-e1b6-909c-a553-35a8934a9b7d%40gmail.com. For more options, visit https://groups.google.com/d/optout.
