A little of coordination for Rosettacode

[bearophile]

Jos van Uden:

> I've split the tape in left and right. It does make the code a 
> bit harder to understand and debug.

You have used three tapes and a unsigned position, while I think 
a signed position and two tapes is enough:

static struct TapeHead {
     immutable Symbol blank;
     Symbol[] tape, left, right;
     size_t position;


The code becoming a little longer and a little less easy to 
understand was expected. But is it worth doing it for this 
Rosettacode Task? I think it's not worth making the code more 
complex.


With the tm3 the new code prints the last two states:

0111111222222220
  ^
0111111222222220
  ^


While the older code prints something different and probably more 
correct:

0111111222222220
^
0111111222222220
  ^


> A linkedlist would have been more elegant, but slower I guess.

On modern CPUs 99% of the times linked lists are the wrong data 
structure to use. They have low data density and incur in high 
cache misses. Benchmarks shows that in some cases arrays need to 
be preferred even when deletions in the middle are not so common.

Linked lists are better when you have to insert and remove many 
items randomly in the middle of the sequence and you don't have 
to transverse all the sequence often. This double condition is 
not so common.


> The stress test that was posted on the talk page, I've also 
> added.

Good. It's better to add it to the precedent version of the UTM.


> Our UTM produces the correct result but with redundant blanks on
> both sides.
>
> 0111111222222220
>  ^

A Turning Machine is supposed to have a tape that is infinite in 
both directions, so when you print the tape you trim the blanks 
away at both ends.

So a better printing is:

...11111122222222...


Or:

Incrementer:
...111...
    ^
...111...
     ^
...111...
      ^
...1110...
       ^
...1111...
      ^

Bye,
bearophile