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
