Well, I wrote this nasty BASIC effort which animates the problem graphically. I regret that I made no attempt to optimise it. So, in order to gather a large enough sample to achieve any kind of useful accuracy, there is no choice other than using beebjit.

Originally, this implementation used a fixed 100 records, but after running it for a while, I started to notice something suspicious.

Turing's observation (three million records implies a mean seek distance of one million) may be summed up as

mean seek distance = N / 3

With 100 records, this predicts a mean seek distance of 33⅓, but that is not quite what is observed. See the "Mean Seek" figure here:

(simulate 100 records, no loop)

This appears to be tending towards a limit of 33⅔, not 33⅓. [i]Was passiert?[/i]

Consider the simplest possible case of a tape containing just two records. In this case, the only seek possible is to alternate from one record to the other, over and over again. The mean seek distance has to be exactly 1, because no other seek distance is possible. Well, that's not what is predicted by the N/3 model, which gives a seek distance of ⅔.

The computer agrees with the thought experiment, of course:

(simulate 2 records, no loop)

What do we get for three records total? It's more complicated, but we can probably do this on paper. There are two possible seeks available from any position.

If we're at record A, then we can go to B (distance 1) or to C (distance 2), with equal probability. The same is true if we are at record C: B is 1 away, and A is 2 away. If we are at record B, though -- the one in the middle -- A and C are accessible, both at a distance of 1. The probabilities start to look like this:

[list]
[*]From A:[list]
  [*]go to B (distance 1, probability ½)
  [*]go to C (distance 2, probability ½)[/list]
B and C are equally likely, so expected distance overall is 1x½ + 2x½ = 1½
[*]From C:[list]
  [*]go to A (distance 2, probability ½)
  [*]go to B (distance 1, probability ½)[/list]
A and B are equally likely, so expected distance overall is again 1x½ + 2x½ = 1½
[*]From B:[list]
  [*]go to A (distance 1, probability ½)
  [*]go to C (distance 1, probability ½)[/list]
A and C are equally likely, so expected distance overall is 1x½ + 1x½ = 1
[/list]

If the probability of starting at any record is equal, then the final expected mean seek distance will be

(1½ + 1½ + 1) / 3 = 1⅓.

1⅓. Once again, this clashes with the N/3 model dreamed up earlier, which would predict a mean seek distance of 3/3 = 1.

The computer agrees with 1⅓:

(simulate 3 records, no loop)

So it looks very much like the N/3 model is wrong, or at least an oversimplification. Based on everything seen so far, the correct seek distance is predicted by (N+1)/3, not N/3.

Conclusion: Turing should have said "one million and one-third records", rather than "one million records". :P

What about the tape loop? My offering supports that, too, with a nice circle to represent the tape instead of a line. Let's look at 100 records again:

(simulate 100 records w/loop)

For the tape loop case, the denominator seems to have increased to /4 rather than /3. That pesky +1 in the numerator persists, as it seems our mean seek distance is now (N+1)/4 rather than (N+1)/3, giving us the above observed value of 100+1/4 = 101/4 = 25¼.