the rule x y+1 = x · x y , which is implemented by means of cumulative multiplication, using box m1 as a counter.

It should now be clear that the initial restriction to two elementary sorts of acts, n+ and n−, does not prevent us from computing fairly complex functions, including all the functions in the series that begins sum, product, power, . . . , and where the n + 1st member is obtained by iterating the nth member. This is considerably further than we got with Turing machines in the preceding chapters.

5.2 Simulating Abacus Machines by Turing Machines

We now show that, despite the ostensible greater flexibility of abacus machines, all abacus-computable functions are Turing computable. Before we can describe a method for transforming abacus flow charts into equivalent Turing-machine flow charts, we need to standardize certain features of abacus computations, as we did earlier for Turing computations with our official definition of Turing computability. We must know where to place the arguments, initially, and where to look, finally, for values. The following conventions will do as well as any, for a function f of r arguments x1, . . . , xr :

(a)Initially, the arguments are the numbers of stones in the first r boxes, and all other boxes to be used in the computation are empty. Thus, x1 = [1], . . . , xr = [r],

0 = [r + 1] = [r + 2] = · · · .

(b)Finally, the value of the function is the number of stones is some previously specified box n (which may but need not be one of the first r). Thus,

f (x1, . . . , xr ) = [n] when the computation halts, that is, when we come to an arrow in the flow chart that terminates in no node.

(c)If the computation never halts, f (x1, . . . , xr ) is undefined.

The computation routines for addition, multiplication, and exponentiation in the preceding section were essentially in this form, with r = 2 in each case. They were formulated in a general way, so as to leave open the question of just which boxes are to contain the arguments and value. For example, in the adder we only specified that the arguments are to be stored in distinct boxes numbered m and n, that the sum will be found in box x, and that a third box, numbered p and initially empty, will be used as an auxiliary in the course of the computation. But now we must specify m, n, and p subject to the restriction that m and n must be 1 and 2, and p must be some number greater than 2. Then we might settle on n = 1, m = 2, p = 3, to get a particular program for addition in the standard format, as in Figure 5-7.

The standard format associates a definite function from natural numbers to natural numbers with each abacus, once we specify the number r of arguments and the number n of the box in which the values will appear. Similarly, the standard format for Turing-machine computations associates a definite function from natural numbers to natural numbers (originally, from positive integers to positive integers, but we have modified that above) with each Turing machine, once we specify the number r of arguments. Observe that once we have specified the chart of an abacus

Figure 5-7. Addition in standard format.

machine A in standard form, then for each register n that we might specify as holding the result of the computation there are infinitely many functions Arn that we have specified as computed by the abacus: one function for each possible number r of arguments. Thus if A is determined by the simplest chart for addition, as in Example 5.2, with n = 1 and m = 2, we have

A21(x, y) = x + y

for all natural numbers x and y, but we also have the identity function A11(x) = x of one argument, and for three or more arguments we have Ar1(x1, . . . , xr ) = x1 + x2. Indeed, for r = 0 arguments we may think of A as computing a ‘function’ of a sort, namely, the number A01 = 0 of strokes in box 1 when the computation halts, having been started with all boxes (‘except the first r’) empty. Of course, the case is entirely parallel for Turing machines, each of which computes a function of r arguments in standard format for each r = 0, 1, 2, . . . , the value for 0 being what we called the productivity of the machine in the preceding chapter.

Having settled on standard formats for the two kinds of computation, we can turn to the problem of designing a method for converting the flow chart of an abacus An , with n designated as the box in which the values will appear, into the chart of a Turing machine that computes the same functions: for each r, the Turing machine will compute the same function Arn of r arguments that the abacus computes. Our method will specify a Turing-machine flow chart that is to replace each node of type n+ with its exiting arrow (as on the left in Figure 5-1, but without the entering arrow) in the abacus flow chart; a Turing-machine flow chart that is to replace each node of type n− with its two exiting arrows (as on the right in Figure 5-1, again without the entering arrow); and a mop-up Turing-machine flow chart that, at the end, makes the machine erase all but the nth block of strokes on the tape and halt, scanning the leftmost of the remaining strokes.

It is important to be clear about the relationship between boxes of the abacus and corresponding parts of the Turing machine’s tape. For example, in computing A4n (0, 2, 1, 0), the initial tape and box configurations would be as shown in Figure 5-8. Boxes containing one or two or . . . stones are represented by blocks of two or three or . . . strokes on the tape. Single blanks separate portions of the tape corresponding to successive boxes. Empty boxes are always represented by single squares, which may be blank (as with R5, R6, R7, . . . in the figure) or contain a single 1 (as with R1 and

Figure 5-8. Correspondence between boxes and tape.

R4 in the figure). The 1 is mandatory if there are any strokes further to the right on the tape, and is mandatory initially for empty argument boxes. The blank is mandatory initially for Rr+1, Rr+2, . . . . Then at any stage of the computation we can be sure that when in moving to the right or left we encounter two successive blanks, there are no further strokes to be found anywhere to the right or left (as the case may be) on the tape. The exact portion of the tape that represents a box will wax and wane with the contents of that box as the execution of the program progresses, and will shift to the right or left on the tape as stones are added to or removed from lower-numbered boxes.

The first step in our method for converting abacus flow charts into equivalent Turing-machine flow charts can now be specified: replace each s+ node (consisting of a node marked s+ and the arrow leading from it) by a copy of the s+ flow chart shown in Figure 5-9.

Figure 5-9. The s+ flow chart.

The first 2(s − 1) nodes of the s+ chart simply take the Turing machine across the first s − 1 blocks of strokes. In the course of seeking the sth block, the machine substitutes the 1-representation for the B-representation of any empty boxes encountered along the way.

When it enters the node sa, the Turing machine has arrived at the sth block. Then again substitutes the 1-representation for the B-representation of that box, if that box is empty. On leaving node sb, the machine writes a stroke, moves 1 square right, and does one thing or another (node x) depending on whether it is then scanning a blank or a stroke.

If it is scanning a blank, there can be no more strokes to the right, and it therefore returns to standard position. But if it is scanning a stroke at that point, it has more work to do before returning to standard position, for there are more blocks of strokes to be dealt with, to the right on the tape. These must be shifted one square rightwards, by erasing the first 1 in each block and filling the blank to the block’s right with a stroke—continuing this routine until it finds a blank to the right of the last blank it has replaced by a stroke. At that point there can be no further strokes to the right, and the machine returns to standard position.

Note that node 1a is needed in case the number r of arguments is 0: in case the ‘function’ that the abacus computes is a number A0n . Note, too, that the first s − 1 pairs of nodes (with their efferent arrows) are identical, while the last pair is different only in that the arrow from node sb to the right is labelled B:1 instead of B:R. What the general s+ flow chart looks like in the case s = 1 is shown in Figure 5-10.

Figure 5-10. The special case s = 1.

The second step in our method of converting abacus flow charts into equivalent Turing machine flow charts can now be specified: replace each s− node (with the two arrows leading from it) by a copy of an s− flow chart having the general pattern shown in Figure 5-11.

Readers may wish to try to fill in the details of the design for themselves, as an exercise. (Our design will be given later.) When the first and second steps of the method have been carried out, the abacus flow chart will have been converted into something that is not quite the flow chart of a Turing machine that computes the same function that the abacus does. The chart will (probably) fall short in two respects, one major and one minor. The minor respect is that if the abacus ever halts, there must be one or more ‘loose’ arrows in the chart: arrows that terminate in no node. This is simply because that is how halting is represented in abacus flow charts: by an arrow leading nowhere. But in Turing-machine flow charts, halting is represented in a different way, by a node with no arrows leading from it. The major respect is that in computing Arn (x1, . . . , xr ) the Turing machine would halt scanning the leftmost 1 on the tape, but the value of the function would be represented by the nth block of strokes on the tape. Even if n = 1, we cannot depend on there being no strokes on the tape after the first block, so our method requires one more step.

The third step: after completing the first two steps, redraw all loose arrows so they terminate in the input node of a mop-up chart, which makes the machine (which will be scanning the leftmost 1 on the tape at the beginning of this routine) erase all but the first block of strokes if n = 1, and halt scanning the leftmost of the remaining strokes. But if n = 1, it erases everything on the tape except for both the leftmost

Figure 5-11. Abbreviated s− flow chart.

1 on the tape and the nth block, repositions all strokes but the rightmost in the nth block immediately to the right of the leftmost 1, erases the rightmost 1, and then halts scanning the leftmost 1. In both cases, the effect is to place the leftmost 1 in the block representing the value just where the leftmost 1 was initially. Again readers may wish to try to fill in the details of the design for themselves, as an exercise. (Our design will be given shortly.)

The proof that all abacus-computable functions are Turing computable is now finished, except for the two steps that we have invited readers to try as exercises. For the sake of completeness, we now present our own solutions to these exercises: our own designs for the second and third stages of the construction reducing an abacus computation to a Turing computation.

For the second stage, we describe what goes into the boxes in Figure 5-11. The top block of the diagram contains a chart identical with the material from node 1a to sa (inclusive) of the s+ flow chart. The arrow labelled 1:R from the bottom of this block corresponds to the one that goes right from node sa in the s+ flow chart.

The ‘Is [s] = 0?’ box contains nothing but the shafts of the two emergent arrows: They originate in the node shown at the top of that block.

Figure 5-12. Detail of the s− flow chart.

The ‘Return to standard position’ blocks contain replicas of the material to the right of node x in the s+ chart: The B:L arrows entering those boxes correspond to the B:L arrow from node x.

The only novelty is in the remaining block: ‘Find and erase the . . . ’ That block contains the chart shown in Figure 5-12.

For the third stage, the mop-up chart, for n = 1, is shown in Figure 5-13.

Figure 5-13. Mop-up chart.

We have proved:

5.6 Theorem. Every abacus-computable function is Turing computable.

We know from the preceding chapter some examples of functions that are not Turing computable. By the foregoing theorem, these functions are also not abacus computable. It is also possible to prove directly the existence of functions that are not abacus computable, by arguments parallel to those used for Turing computability in the preceding chapter.