Push Redux

I found some time since the last meeting to start a new repo to experiment with Pelican and the Push Redux. All pages are written in Markdown (just like here!) and Pelican converts them to static HTML files. No back-end needed.

It is hosted with GitHub Pages. You can see what Push Redux looks like here:

Much of the content is missing, and all of the content is taken from the Pysh documentation and should be tweaked to be less implementation specific.

I would like to hear what people think about this approach.

I think the big pros are:

  1. GiHub Pages is free!

  2. Doing things this way would allow anyone to make changes to the Push Redux through pull requests which could be reviewed before being accepted. I wrote a quick guide to making changes here which hopefully will give a sense of how easy it is to work with.

  3. Usually no coding is needed. Unless you count Markdown and Git. On the other hand, all source files for the site are able to by modified if anyone wants to post a fancy javascript thing they made, or various forms of media, etc.

1 Like

I’m not sure I understand your entire process/plan completely, but I like what I see and the features of the approach that you describe. So unless someone sees a problem that we don’t, I’d say full steam ahead!

I’ve never used Pelican, but I’ve used Jekyll, which is a pretty similar tool that uses Ruby instead of Python as its underlying language. I quite like Jekyll, and it looks like Pelican would be equally easy to work with once you figure out the structure and setup.


Just finished my first pass at the Genetic Operators page. Feedback welcome.

1 Like

Also, I made @lspector’s suggestions from the Pysh thread and finished the Programs and Genomes page. Let me know what should be explained better.

1 Like

Looks good to me, at least for version 1.0 of the redux, but one little thing I’d fix would be to remove “(sometimes called “subtree crossover”),” since you’re describing an operation on a linear genome, not on a tree, and the operation you describe will only sometimes have a “subtree crossover-like” effect on the equivalent tree.


I filled out the input instructions page. Now I have a couple of questions:

  1. What should be put on the output instructions page? Is there anything beyond the printing instructions?

  2. I started on the general instructions page. Should the Clojush/Pysh instruction set be listed out here? Is that confusing information because not all actively maintained push implementations use the same instruction set.

1 Like

On the input instructions page, you don’t say explicitly whether the indices are 0-based or 1-based, but it looks from the example like they’re 0-based. In Clojush I think they are 1-based! Not sure if we should bother to make the implementations consistent, but I think you should be explicit here and if Pysh and Clojush differ then maybe say that.

A little thing, but I think the relation of the history to the current practice could be more clear. I’d:

  • After “and had to be revisited for each new problem.” add “The ‘input stack’ was developed to provide a consistent way to do this across problems.”

  • Change “The most common way to implement” to “Currently, the most common way to implement”.

On output instructions, aside from printing instructions I guess it should also say that quite often outputs are simply taken from the tops of stacks at the end of Push program execution, so explicit output instructions are not necessary. But sometimes there are reasons to use output instructions, and the print instructions can be used for that.

On your question about whether Clojush/Pysh instruction sets should be listed on the general instructions page… I don’t know. I do think it would be good to have these lists somewhere! I’m not sure where/how to handle this…

Incidentally, I’m having a bit of a hard time checking/thinking about this because the pages to which you linked don’t have up/out links to the enclosing section of the documentation… Is that something you can add?

1 Like

I assume Clojush is only 1-based when it comes to input instructions, right? I just ran ("a" "b" "c" 0 string_yankdup) in Clojush and it duplicated the "c". I also tested ("a" "b" "c" 1 string_yankdup) and it duplicated the "b".

I have the input instructions 0-based to be consistent with other push instructions. Is there a reason why in Clojush the input instructions are 1-based? Otherwise, I agree that we shouldn’t bother and I will just make a note of the difference.

Sounds good.

Good idea, I will look into it.

1 Like

Yes. Indexing performed by instructions is 0-based, for things that index into stacks (like yankdup instructions) and things that index into sequential data (like nth instructions). But the names of input instructions start with in1 and then go to in2 etc. I believe this was @thelmuth’s decision, and maybe he had a good reason? :slight_smile:

Let’s hear if @thelmuth or others have opinions on this. I see pros/cons both ways.

I don’t remember exactly. My guess is that it is a historical artifact – when I was adopting this procedure to problems that had multiple inputs, I think some problems already had in1, in2, ..., inN. So, I stuck with those for the automatic system. I don’t think it would be a problem to go to 0-indexed in Pysh. We could also do it in Clojush, but we’d have to be aware that it would break backward comparability with previously evolved programs.

1 Like

In light of this, and the fact that 0-based indexing is more consistent with the rest of Push, I suggest that that Pysh use 0-based input instruction numbering, that the Push Redux includes (for now) a little note that it’s 1-based in Clojush, and that we change Clojush (and remove the note from Push Redux, and ensure that all problem files in the repo are adjusted) if/when somebody has the time and interest.


I’m now returning to this now that GECCO submissions are done.

Looking back at the content that is already written, there doesn’t seem to be too much left to write. I just pushed a page on output instructions. I think this is where we are at:

  • The page on simplification has not been written yet.
  • The page on autoconstruction has not been written yet.
  • The page listing all the different implementations has not been written yet.

And IIRC will be all of the initial content we hoped to put in there, unless anyone has any other ideas.

My hope is that this will be something everyone in this group makes contributions to as Push(GP) evolves … er … develops over time. Maybe someone would like to make an attempt at adding some content and let me know if the static site generator is easy enough to use? My guide for contributing is here.


This is still on my list to do. Hasn’t quite bubbled to the top yet, but I’m hoping it will soon.

I’d like to do a major restructuring of the Orientation category, in particular condensing/replacing some of the real “Orientation” stuff for newcomers, and moving some meta discussions to meta or software or something like that.

I’d like the Push Redux to play a major role in the new arrangement, maybe pinned at the top of Orientation.

However, I see a few things that should be touched up before I do that, including:

  • spellchecking, e.g. breif -> brief

  • A little more linking, like the heading for implementations should (at least for now) point into the Push project page which has a list: http://faculty.hampshire.edu/lspector/push.html

  • Maybe removing the blog, since I’m not sure what that would involve that’s distinct from Discourse… what am I missing there?

Etc. @erp12, what do you think of me editing the Redux directly? (Or maybe I already can? If so, I don’t recall how.)


First off, I thing you editing the Redux directly is great. I am very eager to hear if you and the rest of the group are agreeable to creating the redux with these tools. I wrote a guide that should help most people figure out how to contribute.

You don’t actually need to fork the repo because I added you as a collaborator. You should be able to clone the repo and push directly to it. To figure out how to add content (in markdown), preview changes (build html locally) and then push changes in a way that goes live on the Github Pages, focus on this section.

Let me know if there is any trouble at all, or if you hate this workflow tell me that too :slight_smile:

I totally agree, and just replaced all references to the Blog with links to the Discourse. Pelican (which is what is used to convert the markdown to HTML) is designed mainly with blogs in mind, so the main reason why I had a blog there is because it already existed from the beginning. I don’t see a reason to keep it around.

I also took care of the other two changes you recommended.


Yeah, so I’m stupidly late to this game, but…

I think this points to a very important and tricky part of all this that I was thinking about when talking with @lspector about the GECCO tutorial.

There’s Push as a semi-abstract concept: Typed stacks, linear sequences of instructions, instructions reverting to NOOPs when they don’t work, timeouts or some such to catch infinite loops, answers taking from “appropriate” stack. There’s PushGP as a semi-abstract concept: Evolve linear sequences of instructions, possibly with a genome if we need to manage things like blocks or want to support things like gene silencing.

And then there’s the reality of Clojush, which is pretty much every random thought @lspector’s had in the last decade, or Klaupacius, which is pretty much every random thought @bill’s had in the last decade, but with tests. :stuck_out_tongue_winking_eye: (And now there’s Pysh…you can fill in the blanks.)

If part of the goal of Push Redux is to bring new people into the community, then I think we need to be clear about the difference between those things, and help new visitors be clear about them as well. It’s easy to conflate Push and Clojush, and we tend to do that a lot without really thinking much about it, and one of the nice things about tools like Klaupacius and Pysh (and Ellen, etc.) is they help highlight those assumptions.

So I think we should be very explicit on something like Push Redux about what we think is really important about the ideas of Push, and what’s more “stuff that we implemented once and may or may not use much”.

Coming back to the questions of instructions, my first thought was that “Clojush instructions should be documented on the Clojush site, and Klaupacius instructions should be documented on the Klaupacius site, etc.” so we separate the big picture concepts and the implementation details.

My second thought was that maybe we should list at least the (Clojush) instructions that we have evidence matter. We could go through the zillion results files from @thelmuth’s dissertation (and there are probably similar files for @williamlacava) and pull out all instructions used in the simplified programs for winning individuals. We could then do frequency counts on those, and then highlight on Push Redux the instructions that seemed to come up fairly often in solutions across large numbers of problems. This would not be to suggest that those are the only instructions you need, or that other instructions in the current systems might not be useful (esp. for certain problems), or that there might be instructions we’ve never imagined (or implemented outside of Klaupacius, which has everything). But it would mean that every instruction we bother saying something about is an instruction that is demonstrably valuable.

That would require some work, but it would be useful work, and might ultimately turn into a paper or a note. (Maybe a student project and a student workshop paper?) I could imagine that a fancy job of this might introduce some useful clustering on instructions that tend to appear together, and then we could use something like SMAC to try to “tune” clusters of instructions to use on a problem.

Looking at it, though, there seem to still be several blanks in and amongst all the excellent work that’s been done there. Would it be useful to have a TODOs page that lists the known gaps so someone looking to contribute a little could look there. Or that can be handled using Github issues if people think that would be preferable.

There might be a reason to keep this, but I would agree that we want to remove it if it’s not likely to be used. The reason I’m thinking of is that most of Discourse is hidden from the public, and I there are times when I think we discover something that might be interest to a broader community but doesn’t necessarily rise to the level of a paper. If there was a blog here, though, then we could use that to share these “notes” (perhaps after working out the basics here on Discourse). For example, I could see a blog post about the fact adding the new-ish dup_… instructions changed performance on the software synthesis problems since that’s not likely to rise to the level of a paper but might be interesting to others.


No more than 20%. Trust me.

But yes, I agree 100%: There is some kind of Ur-Push (probably Push3), and all the more recent exemplars have diverged one way or another from that. I think there is a “core” language specification for all of them, which as @mcphee says is something like “typed stacks and the five basic food groups of :integer, :float, :boolean, :string and :char.” Things like vectors and maps and all the various argument modalities are not fixed, and apparently never have been, except that somehow a reference to an input variable needs to be able to appear in a program.

I’ve been working on the Klapaucius docs in a private branch, and that will be done relatively soon (probably before mid-May, remarkably). Also I’ve been finishing up the cloud-based AWS Lambda-based search system, which is also something I will share in mid-May.


Great points. Also, these blog posts could include html/javascript elements that are visual and/or interactive. We don’t get that on Discourse. I think it is a great idea to keep in mind for the future.

Will do!


This certainly sounds like an interesting and potentially informative thing to do! I could imagine it giving more data for things we’ve hypothesized, such as exec_y being dangerous and rarely useful in practice.

Now, we just need to convince someone to do it!