In a previous article we saw that writing the HALT program is a logical impossibility, but what about more straightforward calculating tasks? Our simple computing model has stood up to the challenge of the hyper-exponential growth generated by the ultra-recursive Ackermann function. But how will it go playing the Busy Beaver game, invented by Tibor Radó in 1962?

The Busy Beaver game

To understand the Busy Beaver game we must return to our idealised model of computation, and add a few more details. Firstly, we have to specify the nature of the input and output of our computing machine. We will use an infinite tape of discrete cells, each of which contains either a 0 or a 1, and each able to be read by a program and overwritten. Secondly, we will model a program as a set of cards, operating on a currently active cell. Each card consists of two rules, one to apply if the active cell contains a 0, and another if it contains a 1. The rules tell the machine to write a new symbol into the cell (it may be the same symbol as is currently there), make either the next left or next right cell the new active cell, and then load a new card (or HALT). The size of the program, or equivalently the size of the machine, is simply the number of cards.

This model might seem too simple, but it turns out that any calculation a more complex machine can perform can also be computed under this simple model. In fact, any computer program you can think of can be implemented on such a machine, which, by the way, is called a Turing machine.

Representing the rules as a triple (new symbol, shift L or R, new card), here is an example two-card machine.

Starting with card 1 and a tape initialised with 0 in every position, running this machine proceeds as in the following table.

We see that this machine runs through six card transitions (steps), writes four 1s onto the tape, and then halts. A different machine with different instructions written on the two cards might of course run on for longer than six steps. This raises a question: out of all the halting machines running a two-card program and set to start on a tape with all 0s, which one runs the longest?

Radó calls this busiest machine a Busy Beaver. You can also define a busy beaver for machines running with three cards, four cards, or any number of cards. The process of finding the maximum number of steps executed by a busy beaver of size is called the Busy Beaver Game. The first couple of numbers are easy to determine. For cards there can be no steps, hence . For card, all that can be done is an immediate transition to the HALT state, hence . It is far from obvious, but there is no two card machine busier than our example above, and so .

So far these numbers do not look particularly exciting. It took some years to prove, but the next couple of values are , and . But, to this day, no other values of the function are known. The busiest five card machine found so far is

This machine runs for steps, writing 1s, and then halts. So is at least . Adding just one additional state, the busiest six card machine known is

that writes 1s in steps. It is worth pausing to let this sink in—despite just having six cards to switch between, this machine runs for that’s a 1 followed by zeroes, steps and then stops!

It is clear that the Busy Beaver function grows very rapidly. Indeed, the Busy Beaver candidate machines are similar to the extremely rapidly growing functions we considered in part II of this article—they implement the calculation of some super-exponential function , needing only a few states for small . Writing Graham's number using Knuth's up-arrow notation or Ackermann's function (see part II of this article) requires many lines. Yet it is believed that is greater than Graham's number, so the Busy Beaver function appears to grow much faster than Ackermann's function. Can any computer calculate the values for all ?

The crucial insight comes from assuming the answer is yes, and supposing we have the function . We could then implement the HALT function as:

That is, if we can calculate , we can solve the halting problem by converting the input program to a machine of the required type and determining its size , calculating and running the machine. If it runs more than steps, then, by definition, it must run forever. But we’ve already determined that it is logically impossible to solve the halting problem, hence it is similarly logically impossible to write a program that calculates for all

The Busy Beaver function, , despite being well-defined and indeed quite simple to describe, is intrinsically non-computable. In fact, it grows faster than any computable function, since otherwise we could use the faster growing, computable function to calculate an upper bound on that we could then use in the implementation of HALT above. It’s not just a matter of running time and storage space, but it defies the very notion of computability.

The Busy Beaver numbers are interesting and important tools for studying the nature and limits of computation, but a further use of more general appeal is wonderfully described by Scott Aaronson in Who can name the biggest number?—if you want to win at Who can name the biggest number? the Busy Beaver numbers are hard to go past.

About the author

Ken Wessen has PhDs in Theoretical Physics and Human Biology, and a Graduate Diploma in Secondary Mathematics Education. He has taught both at university and in high schools, but most of his working life has been in investment banking, developing algorithms for automated trading of equities and foreign exchange. In his spare time he writes free software and develops online activities for mathematics learning at The Mathenaeum.