Sunday, February 6, 2011

Instructions vs Expression Trees

There are many evolutionary algorithms that evolve programs- GP, LGP, GPM, GEP, and many variations of each. some of these are evolving general tree structures, while others are intended for evolving instructions or a compilable program. In particular it seems like LGP is often used to evolve instructions for some abstract machine, and the instructions take the form of an assembly-like language. DGP and GPM deal with the concept of compiling the result of editing an individuals genetic material, and is clearly intended to deal with the complexity of a programming language.
In contrast, techniques like GEP and sometimes GP evolve a tree structure, which often happens to encode the abstract syntax tree of an expression in some language (indeed GE can evolve an expression tree in any context free grammar supplied by the user). In RGEP I plan on making this distinction clear- RGEP individuals encode an expression tree whose result after evaluation is an object whose fitness can be determined. This object can be a compiled program, or a tree (build from evaluating the postfix expression), or a function f(x) = y for some y, or anything else. This distinction is important for several reasons: it allows RGEP to be used in a large class of possible problems (those whose answers are expressible as the result of evaluating a tree structure), it is in the spirit of "robustness" in that it does not assume very much about the problem to be solved, it allows us to use general stack operators (which appear to improve fitness and promote the reuse of subexpressions, and allows me to specify the evaluation operation for all possible RGEP implementation, saying that the result of the evaluation is generic but the way it is arrived at is always the same.
This is also part of the link between PGEP, RGEP, and functional programming. It is a loose connection, but I think there is some sense in which PGEP and RGEP are more in the traditional of function or even declarative programming in general in that they describe the computation that they want to perform, rather then give explicit instructions (as in the case of LGP especially) on how to perform that computation. The actual operators and terminals supplied to RGEP determine what computation is described.
GPM has more then one derivative method- there is DGPs and GE. It is interesting that GPM, DGP and GE are all fairly complex and often deal with imperative style programs, while GEP is intended to simplify GPM and it is more declarative. PGEP and now RGEP are both intended to simplify GEP as well, so it seems like this whole area of research is focused on simplicity as well as effectiveness, which gives RGEP a nice place in GEP literature- an explicit attempt at simplicity with nearly no other design criteria.

No comments:

Post a Comment