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
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
in2, etc.; it is not intended for data processing, but only as a source of data for the input instructions.