Talk:Wire-crossing problem

Conway's Game of Life has been shown to be Turing-complete: http://en.wikipedia.org/wiki/Conway%27s_Game_of_Life.

Can we not describe every GoL program as a planar graph by definition, thinking of each cell as connected to its 8 neighbors?

No wait, my bad. The grid is in a plane - but the graph (at least sufficiently large) is nonplanar when you think of all those crossing diagonals.

Submitting this discussion as a testament to my own impulsiveness.

--jhw 19:23, 20 Dec 2006 (GMT)

Aha.

There are other elementary cellular automata which are trivially planar. See Rule 110 under http://en.wikipedia.org/wiki/Elementary_cellular_automaton. I believe this scuppers the Strong Hypothesis for the Wire-Crossing Problem: Rule 110 can solve all languages solved by any other Turing Machine can solve, and yet Rule 110 forbids the construction of programs which are non-planar graphs.

Or is there something about cellular automata which violates the (admittedly vague) assumptions in the Wire-Crossing Problem?

--jhw 19:36, 20 Dec 2006 (GMT)

Consider this: http://www.kongregate.com/games/PleasingFungus/manufactoria

in this 'planar' language its posible to implement BCT WITHOUT brigding. and as bct is Turing complete the strong claim is thus proofen to be wrong. Stfu&amp;thnk 15:59, 18 December 2010 (UTC)

Possible proof of planarity turing completeness?
I might be missing something here, but I feel it should be pretty easy to show any non-planar Turing machine can be represented by a planar one. Suppose we have a non-planar Turing machine M, and we embed it in the plane such that any time we have an intersection of edges, we only have two edges cross at that point. At each such intersection, add in a new state for that intersection. We also add two values to our tape alphabet. When we follow a transition into such an intersection state, we record which state we came from. Let's call the source states L and R. Then once we get to the intersection state, we check whether we wrote the symbol indicating we came from state L or state R, and move along the corresponding output transition. Thus we just add basically a 'bridge' state that keeps track of where we came from, which limits where we can go to. Then there should be a couple minor details on implementation. Additionally, if we have more than two edges intersect, we simply switch from an L state and an R state to more than two input states.