The Ackermann function in the chemlambda gui

UPDATE: The Ackermann function, the video:


I put this stuff on G+  some days ago and now I can find it only if I look for it on purpose. Older and newer posts, those I can see. I can see colored lobsters, funny nerd jokes, propaganda pro and con legacy publishing, propaganda hidden behind granpa’s way of communicating science, half baked philosophical ideas,  but not my post which I made only two days ago. On my page, I mean, not elsewhere.

Thank you G+ for this, once again. (Note not for humans: this was ironic.)  Don’t forget to draw another box next time when you think about a new algorithm.

A non-ironic thanks though for the very rare occasions when I did met very interesting people and very interesting ideas there.

OK, to the matter, now. But really, G+, what kind of algorithm you use which keeps a lobster on my page but deletes a post about the Ackermann function?

UPDATE: The post is back in sight now. Whew!
The post follows, slightly edited (by adding stuff).
The Ackermann function is an example of a total computable function which is not primitive recursive. It is therefore amusing to try to compute it.
The matter is not what is the value of Ack(m,n), because it grows so fast that very soon the problem of computing it is shadowed by the more trivial problem of storing its values. Instead,  more interesting is to see how your computing device handles the computation itself, things like stacks of calls, etc, because here it is manifest the fact that Ack is not primitive recursive.
To simplify it, the funny thing is to see how you can compute Ack(m,n) without any cheat.
I tried to do this with #chemlambda . I know since a long time that it can be done, as explained (very summary, true) in this old post
for GLC, not chemlambda (but since chemlambda does with only local moves what GLC does, it’s the same).
I want to show you some pictures about it.
It is about computing Ack(3,2). Everybody will point that Ack(3,2) = 29 and moreover that Ack(3,n) has an explicit expression, but this would be cheating, because I don’t want to use precomputed stuff.
No, what I want to use is a lambda calculus term for the Ackermann function (and one which is not eta reduced, because chemlambda does not have eta reduction!), and I want to apply it to the arguments 3 and 2 written as lambda terms as well (using the Church encoding). Then I want to see if after the reductions performed by the algorithm I have I get 29 as a Church number as well.
During all the algorithm I use only graph reductions!
After all there are no calls, no functions and during the computation the molecules which appear are not even representing lambda terms.
Indeed, lambda calculus does not have operations or concepts like fanin nodes, or FOE nodes, not reductions like FAN-IN or DIST. That’s the amazing point (or at least one of them), that even if it veers outside lambda calculus, it ends where it should (or better, that’s for another time).
I used the programs which are available at the site of the chemlambda gui
(which is btw online again, after 2 days of server corruption.)Here are some pictures.The first one is a screenshot of the Ack(3,2) “molecule”, i.e. the graph which is to be reduced according to the chemlambda rules and according to the reduction strategy which I call “viral”.
After almost 200 reductions I get 29, see the second figure, where it appears as the molecule which represents 29 as a Church numeral.
ack_3_2_finalWow, it really worked!
You can try it for yourself, I’ll give you the mol file to play with, but first some details about it.
I modified a bit the awk script which does the reductions, in the following place: when it introduces new nodes (after a DIST move) it has to invent new names for the new edges. In the script which is available for download the algorithm takes the max over all all ports names and concatenate it with a word which describes where the edge comes from. It is good for being able to track back where the nodes and edges come, but it results into a growth of the ports name which is exponential in the number of iterations of the reduction algorithm. This leads to very big names of some ports, after 200 iterations.
So I modified this part by choosing a naming procedure which is less helpful for tracking but better in the sense that now the growth of names is linear in the number of iterations. It is a quick fix, after all it is as easy to invent naming procedures which result in a logarithmic or almost constant length wrt the number of iterations.
For the Ackermann function the script which is available is just as good, it works well, only that it has this unpleasant feature of long names which enlarges unnecessarily the json files.
Details over, next now.
In the third picture you see the mol file for the Ack(3,2), i.e. the list of nodes and ports of the Ack(3,2) molecule, in the format used by the reduction program.
Btw, do you see in this screenshot the name of the updated script? Right, is foe_bubbles_09_10.awk, instead of foe_bubbles_06_10.awk which is available for download.
I don’t cheat at all, see?
I made some annotations which helps you to see which part corresponds to the Ackermann function (as a lambda term translated into chemlamda), which parts are the arguments “3” and “2”, and finally which part represents the Ackermann function applied to (3,2).
Soon enough, when I’ll be able to show you animated reductions (instead of the steps of reduction only), I think such an example will be very funny to examine, as it grows and then shrinks back to the result.





Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s