# Given a PRAM may use arbitrarily many processors, why is Hamiltonian Cycle not in NC?

In my parallel algorithms class, the PRAM model is described as having an "arbitrary number of processors, bounded by some polynomial in the input size."

I think that this may be missing a constraint. For example, this would imply that finding a Hamiltonian cycle is in NC:

If I give all of the permutations of the vertices of a graph as input, then I can assign a processor to each permutation, and each processor can then check for the appropriate edges in O(|E|) time, which would mean that finding a Hamiltonian cycle would be in NC.

So is there some constraint that is missing from the definition we are using in class, or am I missing something else?

# Edit

For clarification: Consider a classical TM, which accepts as input a sane representation of a graph, followed by all of the permutations of a graph's vertices. It then performs the best currently known algorithm for finding Hamiltonian Cycles, and as output writes out a permutation of the vertices describing such a cycle.

The algorithm would perform in time linear in the input size, but in time factorial in the order of the input graph. (The extra inputs don't seem to count as computations for a classic TM.)

In the PRAM model (as I have described it), the algorithm would perform in time linear in both the input size, and in the order of the graph. (The extra inputs seem to count as computations for the PRAM model... Which makes me think that "computation" means something subtly different here...)

If this is the way it is supposed to work: awesome. If not, than am I missing some constraints on what the allowed inputs are?

• NC is famously broken in more than one regard. This is not one of them, though. – Raphael Feb 23 '15 at 22:30

If I give all of the permutations of the vertices of a graph as input

That's not the input for Hamiltonian Cycle; you only get the graph.

then I can assign a processor to each permutation

Since there are $n! \in \omega(c^k)$ many permutations, you don't have that many processors.

Here's the twist: if you were allowed to use all permutations as input, you'd of course have polynomially many processors in $n!$ at your disposal. But since your input is the graph you only get polynomially many in $n$.

• Why is the input "the graph" and not "all permutations of the graph"? I want the specific rule that describes what is or is not allowed as input. – Real John Connor Feb 23 '15 at 22:39
• @RealJohnConnor That is the definition of the Hamiltonian Circuit problem. "Given a graph $G$, decide ..." You propose a PRAM algorithm for a different problem so you don't learn anything about Hamiltonian Circuit. – Raphael Feb 24 '15 at 6:35
• I'm not trying to be dense, or pedantic, but why does "given a graph $G$" mean that the representation of the graph you are given does not contain all permutation of the graph's vertices? ... But I think I can put the problem in another way, and so I will add to my original question... – Real John Connor Feb 24 '15 at 21:44
• @RealJohnConnor Because that would be "Given a graph $G$ and all permutations of its vertices." Normally, we aren't too precise about exactly what the input to a problem is because all the natural encodings of the same object (e.g., graph as adjacency matrix vs adjacency list) differ by only polynomial amounts. But adding all the permutations is tagging on an exponentially larger amount of data, which massively affects the complexity. – David Richerby Feb 24 '15 at 22:04
• @RealJohnConnor To add to what David wrote, the usual implicit assumption a meaningful encoding, i.e. not wasteful. Carrying around all permutations of nodes may be useful for HC, but certainly not for other problems (SSSPP, VC, ...) so you have lots of waste. See also this question about unary encoding. – Raphael Feb 24 '15 at 22:28