[Push] Random code generation

[Lee Spector]

I agree this is another consideration -- you *might*, depending on your application, want to be pushing your own inputs/constants on the stacks ahead of time, and you *might* also want to limit your instruction set in various ways. This latter suggestion is a double-edged sword, however, since PushGP can often find ways to use stuff that you never would have thought to be useful ahead of time... I often take a middle road on this, including more than I think will be necessary but not everything, just to increase the probability that the stuff I *do* think will be useful will appear in a significant number of programs. Ideal, I guess, would be to allow everything to appear but to make the stuff that's probably going to be more useful (possibly including literals) appear more often. The way to do that in the current implementations is just to have the latter stuff appear multiple times in the lists of ingredients, but a fancier system could certainly be provided for this.

 -Lee

On Jun 20, 2010, at 9:26 AM, Thomas Helmuth wrote:

> On Sun, Jun 20, 2010 at 9:00 AM, PerPlex Ed <edperplex at yahoo.com> wrote:
> 
> Since the number of instruction is 2 order of magnitude bigger than
> then number of all possible kinds of ephemeral random constants (which is
> the number of activated "value types"), I get code that will fail in most
> of the cases because the instructions have no inputs on the stack.
> So this can't be the correct procedure. How do I have to read that?
> 
> 
> It sounds like you don't have anything on the stacks at the beginning of your program, which should not be the case. At the bare minimum, both the Exec and Code stacks should contain the program itself, and any other inputs should be pushed onto their respective stacks. For example, if you are running a floating point symbolic regression problem with input x, x should be pushed onto the Float stack before execution.
> 
> Another problem you may be having is that it appears that you are not constraining the instruction set in any way. Though not strictly necessary, it often speeds up the evolutionary process to restrict Push to only instructions that may be necessary during evolution. For example, if you are running a problem that deals with boolean satisfiability, it doesn't help to have float or int instructions in your instruction set. 
> 
> -Tom
> _______________________________________________
> Push mailing list
> Push at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/push

--
Lee Spector, Professor of Computer Science
School of Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438

Check out Genetic Programming and Evolvable Machines:
http://www.springer.com/10710 - http://gpemjournal.blogspot.com/