[Push] Wondering about Code

[Lee Spector]

On May 4, 2010, at 8:01 PM, Erik Max Francis wrote:
>> For example the last two systems I've made (schush and clojush) deal with configuration in a totally different way from the spec and have omitted the NAME type (just because I didn't think I'd need it and didn't have the time).
> 
> What did you use instead of it, arbitrary integers on a special stack? Or did you just not need the equivalent of ADFs for what you were doing?

In these two systems I've just not implemented the NAME type -- I haven't added anything to compensate. But does this mean you can't get "the equivalent" of ADFs? It's true that you can't have NAMED functions, but you can still have functions. That is, by using EXEC/CODE instructions you can copy a piece of code and apply it to multiple inputs, and you can do even more by modifying copies or combining them with combinators (EXEC.Y, EXEC.K, EXEC.S) or even things like CODE.APPEND, etc. It's just that these pieces of code don't have names, but they're still basically functions.

It does seem to me that NAMEs should be handy, and that having the ability to name functions should help in some cases. But in point of fact I've never been able to demonstrate that. On a couple of occasions I've tried explicitly to do this, by devising a problem for which NAMEs would seem to be helpful and doing lots of runs. But PushGP always found ways to do things without NAMEs, and very rarely found anything using NAMEs. I even tried removing the instructions that it was using to produce NAMEless solutions, but never found a satisfying case for NAMEs in practice.

Since NAMEs are also a bit less elegant than the other features of Push -- e.g. allowing for an unbounded set of ephemeral random names is a bit awkward, and even with Push3's improvements there's still a difference between the first and subsequent uses of a NAME (which could be eliminated but only at the cost of making an initial definition harder to produce) -- I haven't bothered with them in my latest implementations.

I would LOVE to be proven wrong about this, however, or to see an alternative version of the NAME concept that makes NAME-containing programs easier to evolve and more useful in general.

>> And instruction names are changed a bunch in clojush because of Clojure/Java naming restrictions. Still, it'd be nice to impose some order on all of this diversity, but I'm not sure how.
> 
> Some minimum spec and number of operators that should be supported to have a "real" Push system, perhaps?


Well that sounds good but I suspect the devil will be in the details. And I think it'd also be nice if it allowed one to document the non-core things that are in a particular implementation in a somewhat-standard way.

I would be very happy to provide feedback to any such efforts, and I suspect a few others on this list would be too.

 -Lee

--
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/