Input instructions

How can inputs be provided for Push programs?

When Push was first being developed, the idea was that you would preload inputs onto stacks, then run your program, and then find outputs on stacks after the program terminates. This was modeled roughly on how we thought of push-down automata being used in formal language theory.

However, Hampshire student Alan Robinson soon discovered, and documented in his Division III thesis, the fact that it can be more helpful to define instructions that can be called to re-push inputs on demand, possibly multiple times during the execution of a program. This seems obvious in retrospect, since the original scheme provided only one copy of each input and required a program to duplicate it and keep track of copies on stacks if the inputs would be needed in multiple parts of a program.

It then became common practice to define input instructions for each problem, and each implementation of Push provided some way to do this, although the details for implementing these varied from implementation to implementation and had to be revisited for each new problem.

In Clojush, @thelmuth implemented a problem-independent method (implemented here) that uses a new component of a Push interpreter state (implemented in Clojush just as another stack) called :input. Special instructions called in1, in2, etc. can be used in programs to refer to the 1st, 2nd, etc. items in the :input component. In order for these to work correctly, the input values must be added to the :input component (in Clojush, pushed onto the :input stack) prior to execution. For conducting pushgp runs in Clojush, this adding should occur prior to execution in the error function, and the relevant input instructions should be included in :atom-generators. No instructions are provided for :input aside from in1, in2, etc.; it is not intended for data processing, but only as a source of data for the input instructions.


I realize that it’s common practice to call that a stack, but it really isn’t a stack in any useful sense of the word, and that seems to conflate an important concept (giving inputs names so they can be accessed at will) with a much less important implementation detail.

1 Like

First I agreed, and was composing a revision with something like “component of a Push interpreter state” instead of “stack,” when I realized that the subsequent language about pushing items onto the “stack” actually reflects the code-level interface in Clojush, where we use push-item to push inputs onto the :input stack, etc. Muddies the water, at least, for me. Maybe it’s cleanest to stick to explaining it as a static stack? It’s also fewer words :wink:

Added: But yeah, I agree again. We can keep this more implementation neutral (except maybe in parentheses like this). Will update.

Done – better?

1 Like

Definitely. :sunglasses::heart_eyes::sunglasses:

1 Like