[Push] Input stack (from Psh)

[Lee Spector]

You're probably right that input handling isn't the main issue here, but FWIW the presence/absence of an input instruction will change the topology of the whole search space, so the fact that there's a relatively compact solution doesn't necessarily mean that it'll be easy. To know that you'd have to know what's near it in "program space"  (with plausible mutations etc) and how fit those things are. Generally we can't know that, so we don't know which representation is best, but it's worth keeping in mind that representations can matter in non-obvious ways.

Trying your problem in clojush using the "sextic" example and just changing the target function (leaving all of the other parameters the same, which turns out to be bad, and including an input instruction) it starts with an error of 9.something and goes down to 1.something in a couple dozen generations, but by then (with these parameters! and just in two quick runs) programs have bloated to the maximum size (which is just 50 here) and it gets stuck, presumably needing to adjust some constants but not having the room to muck with the code enough. A variety of measures might counteract this and allow for better solutions (larger program limits? higher rate for the simplification operator? etc.). In one quick run WITHOUT the input instruction I got stuck earlier, with error of 3.something. So maybe (but it's WAY too few runs to know for sure) the input instruction helps.

Looking at the parameters I see I have a particularly silly ephemeral random float in there, which can only generate -10.0, -9.0, -8.0... 10.0 -- that is, no non-integral floats. Makes it hard to get things like 5.4. I could change that to a full range of floats, but for kicks I tried changing it so that it produces floats from -10.0 to +10.0 in increments of 0.1, and while it still bloats it gets to an error of less than 0.2 in something like 50 generations. That's WITHOUT the input instruction (just one run! so it may not mean much). WITH the input instruction it seems to be a little better, but the bloat is still a problem here.

Anyway, maybe it helps to see how this other implementation performs with badly chosen parameters :-)

 -Lee


 

On Jun 25, 2010, at 6:36 PM, PerPlex Ed wrote:

> Currently I'm trying to make my implementation find an equivalent program for
> 
> 1.5*x^2 + 0.3*x + 5.4
> 
> In Push it can be written as 
> 
> (
>                Float.Dup
>                Float.Dup
>                Float.Mul
>                1.5
>                Float.Mul
>                1
>                Float.Yank
>                0.3
>                Float.Mul
>                Float.Add
>                5.4
>                Float.Add
> )
> 
> which shows what you mean by "will often have to dup the value a lot and do a lot of stack 
> manipulation" but it's still quite simple and short.
> 
> I'm failing at producing anything close to a decent result but I guess the main reasons are my simple evolution agent, several implementation details that I'm fixing (like I was using RMS *relative* error on a sample set as a part of the fitness, which apparently is dumb) and my lack of experience.
> 
> I count on input not being a major factor in this case but I'll take it into account later. Thanks.
> 
> Lee said:
> 
>> Even for symbolic regression you might want to use an instruction that pushes the input value, rather than relying on a single push before program execution. While it's possible for a correct program to work from only that initial push, such a program will often have to dup the value a lot and do a lot of stack manipulation to get the copies into the right places. Defining an input instruction (manually, if necessary, although I think Tom will be able to tell you how to do it in Psh) that re-pushes the value whenever it is called can make it a lot easier to express a correct program.
> 
> 
> 
> 
> _______________________________________________
> 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/