An interesting corrolary: the deeper down the deck you go, the less number of paths are actually available. For example, if you have 10 cards on the first row, then there are at most 10 paths to the end, but those can merge. So if you have many cards, paths will merge and you might just end up with one path.
So most cards towards the end of the deck are totally unreachable! For example the next to last card is most likely not reachable through this walking algorithm in most distributions.
I'm not sure of the implications but it sure feels important for things like randomly generated worlds or whatnot.
[0]: http://faculty.uml.edu/rmontenegro/research/kruskal_count/in...
In fact they must converge, suppose that the first card on the first row is less than 10, then it will merge with another path on the first move (because it will land on the first row), so it must be 10 to have no merging paths. The next card will merge with another path on the first row if it's less than 9, but if it's 9 it will merge with the first path, so it too must be 10. Same reasoning goes for the third, fourth and fifth card, however there are only 4 cards with value 10, so at least two of the paths on the first row merge within one move.
Of course with the standard 52-pack you'll end up with a high degree of merging. I just think it's important to say that the necessity of merging is really dependent on the instruction set, so to speak.
Are you sure? Is this board not a counter-example if A starts on the right-most column and B starts on the second from the right:
x x x x x x x 8 9
x x x x x x 8 x 9
x x x x x 8 x x 9
x x x x 7 x x x 9
x x 7 x x x x x A
B x x x x x xPretty sure I first heard about avalanching from Bob Jenkins' hash functions. (http://burtleburtle.net/bob/hash/doobs.html)
Intuitively anything that makes you take shorter steps should increase the chance of merging with another path.
The idea is to make a function that maps hash values back to password-like strings. With that function chains like this are built:
I=initial password guess
P=new password-like string
V=hash value
H()=hash function
U()=unhash function (converts V to a new P)
I -> V0=H(I0) -> P0=U(V0) -> V1=H(P0) -> P1=U(V1) -> ... -> Vfinal
Re-creating the chain from the chain of hashes from our known initial value, we discover a string that might not be the actual password, but is a string that hashes to the same value. With modern cryptographic hashes, collisions are unlikely, but rainbow tables were invented when passwords used very poor hashes.
Just clarifying if how I counted was correct..
5 x x x x 9
Did this, but did not work for me.
I followed the rules just as you illustrated.
0: http://faculty.uml.edu/rmontenegro/research/kruskal_count/in...
You start at the first card and progress until you would fall off the end on the next step. That card you're on is what you pick as the trap.