Nil, > 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.
yes... The Pattern Miner contains one such scheme for going from T to T1, which is hard-wired into its C++ code... In the proposed refactoring I'm suggesting, this code would be abstracted so that the basic "incremental growth of an ensemble of sub-hypergraphs" process can be done according to any specified scheme for going from T to T1 ... and indeed such a scheme should ideally be represented in Atomese as well... > It was [never] 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? Yeah, for some fitness functions, subtree-level memoization or other Atomspacey tricks could speed up MOSES evaluation ... and for others, the raw speed increase of VertexTrees over the Atomspace will be dominant ... I would imagine that for numerical-data-analysis type applications, e.g. financial prediction, the current MOSES would be faster, because memoization probably isn't going to get you that far in that context, and ultimately you just want to evaluate a wide variety of different Boolean combinations on a wide variety of datasets really fast... However, for applications involving more abstract programming constructs, a smarter Reduct is what's going to give huge improvements, and we'd rather implement that in OpenCog ... Obviously we will just need to implement the Pattern Miner-y version of MOSES and then profile it on different types of problems, and look at the best routes to optimization when we get there... premature optimization yadda yadda .... As the Atomspace is not *that* inefficient now, I don't think the Pattern Miner-y MOSES is gonna be so slow as to be a non-starter... -- 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+unsubscr...@googlegroups.com. To post to this group, send email to opencog@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/CACYTDBe%3DVUzYyTWiksVqg9Ca8MhA9J0Wp51UeYbYC8atx6Hkkw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
