<p>I think I have a deterministic algorithm that finds the exit in $O(n2^{n/2})$ oracle calls.</p>

<p>First, find the labels for all the vertices of distance $n/2$ from the entrance. This takes $O(2^{n/2})$ queries. Then, start from the entrance and walk $n+1$ steps to get to a node $X$ of distance $n+1$ from the entrance. We will try to reach the exit from this node.</p>

<p>We have two options of where to go from $X$, and we wish to choose the one closer to the exit. To do this, pick one of the options arbitrarily, arriving at a node $Y$. Then explore all the $O(2^{n/2})$ ways of walking $n/2$ steps from $Y$. If one of them gives a label of distance $n/2$ from the entrance, we know that going from $X$ to $Y$ was the wrong choice. Otherwise, $Y$ was the right choice. Thus in $O(2^{n/2})$ we found a node $X_2$ of distance $n+2$ from the entrance.</p>

<p>We can keep proceeding this way. To find a node of distance $n+3$ from the entrance, we start at $X_2$ and walk two arbitrary steps. We then explore all options of walking $n/2$ additional steps (while never walking backwards), and check if any of them have distance $n/2$ from the entrance. This will happen if and only if the first step we walked from $X_2$ was wrong.</p>

<p>Getting to the exit requires doing this $n$ times, for a total of $O(n2^{n/2})$ oracle calls. In addition, perhaps surprisingly, this algorithm is deterministic.</p>

<p><strong>Edit:</strong> Just to clarify, to get from $X_t$ to $X_{t+1}$, we walk $t$ arbitrary steps, then run a search of depth $n/2$, for a total of $t+2^{n/2}$ steps. If the first step lead away from the exit, then all the first $t$ steps did, and we therefore find a label of distance $n/2$ from the entrance. This means $t+2^{n/2}$ steps suffice for determining the next single step to take from $X_t$.</p>

CC BY-SA 3.0
2014-07-20T11:31:24.130Z
I don't understand. To find $X_{t+1}$, you would make $t$ arbitrary steps from $X_t$ and then $n/2$ additional steps? Wouldn't this give $2^t2^{n/2}$ steps which is too much?
domotorp
CC BY-SA 3.0
2014-07-20T13:30:46.427Z
I second domotorp's confusion.  Isn't it the case that, the closer you get to the EXIT, the longer the path you're going to need to get to one of the $2^{n/2}$ points that you queried at the beginning?  Still, maybe you could exploit the fact that paths that start close to the EXIT are extremely likely to move left toward the center until they reach it?  (This would add a bit of randomization to your algorithm.)
Scott Aaronson
CC BY-SA 3.0
2014-07-20T14:44:41.660Z
Come to think of it, what if we took advantage of the fact that, from any vertex in the right half of the graph, you have a 1/2 chance of picking a direction that's going to lead you *inexorably* back to the center?  That might be enough to get us n/2 away from the EXIT vertex, which would then allow us to find the EXIT vertex itself with $2^{n/2}$ further queries.
Scott Aaronson
CC BY-SA 3.0
2014-07-20T15:55:21.590Z
To find $X_{t+1}$, make $t$ arbitrary steps from $X_t$, but _only once_. This takes $t$ steps, not $2^t$ steps. Then make $n/2$ steps in _all possible ways_. This takes $2^{n/2}$ steps. The total is $t+2^{n/2}$.

I'm using the fact that if the first of the $t$ steps was wrong, then all $t$ of these steps lead away from the exit (and back towards the entrance). This stops being the case after the first $t$ steps, which is why you need to start an exhaustive search.
Shalev
CC BY-SA 3.0
2014-07-20T17:02:22.407Z
I see, so your algorithm to find $X_{t+1}$ from $X_{t}$ is
1, Go $t$ steps
2, Test whether we are in the center
3, If no, use first step of the $t$ steps to get $X_{t+1}$
4, If yes, use the other edge from $X_{t}$ to get $X_{t+1}$
Nice!
domotorp
CC BY-SA 3.0
2014-07-21T20:03:13.823Z
The idea of starting a search from both ends and leading to a sqrt() improvement over the naive algorithm is known as *bidirectional search* and has been rediscovered independently many times in various contexts e.g. route planning in google maps. The original reference seems to be:


G. B. Dantzig. Linear Programming and Extensions. Princeton University Press, 1962.
Alex Lopez-Ortiz
CC BY-SA 3.0
2014-07-20T04:26:25.690Z
2014-07-20T16:23:22.633Z
2014-07-20T16:23:22.633Z
Shalev
<p>An <a href="http://arxiv.org/pdf/quant-ph/0209131v2.pdf" rel="noreferrer">important 2003 paper by Childs et al.</a> introduced the "conjoined trees problem": a problem admitting an exponential quantum speedup that's unlike just about any other such problem that we know of.  In this problem, we're given an exponentially-large graph like the one pictured below, which consists of two complete binary trees of depth n, whose leaves are connected to each other by a random cycle.  We're supplied with the label of the ENTRANCE vertex.  We're also supplied with an oracle that, given as input the label of any vertex, tells us the labels of its neighbors.  Our goal is to find the EXIT vertex (which can easily be recognized, as the only degree-2 vertex in the graph other than the ENTRANCE vertex).  We can assume that the labels are long random strings, so that with overwhelming probability, the only way to learn the label of <i>any</i> vertex other than the ENTRANCE vertex is to be given it by the oracle.</p>

<p>Childs et al. showed that a quantum walk algorithm is able simply to barrel through this graph, and find the EXIT vertex after poly(n) steps.  By contrast, they also showed that any classical randomized algorithm requires exp(n) steps to find the EXIT vertex with high probability.  They stated their lower bound as &Omega;(2<sup>n/6</sup>), but I believe that a closer examination of their proof yields &Omega;(2<sup>n/2</sup>).  Intuitively, this is because with overwhelming probability, a random walk on the graph (even a self-avoiding walk, etc.) will get stuck in the vast middle region for an exponential amount of time: any time a walker starts heading toward the EXIT, the much larger number of edges pointing away from the EXIT will act as a "repulsive force" that pushes it back toward the middle.</p>

<p>The way they formalized the argument was to show that, until it's visited ~2<sup>n/2</sup> vertices, a randomized algorithm hasn't even found any <i>cycles</i> in the graph: the induced subgraph that it's seen so far is just a tree, providing no information whatsoever about where the EXIT vertex might be.</p>

<p>I'm interested in pinning down the randomized query complexity of this problem more precisely.  My question is this:</p>

<p><b>Can anyone come up with a classical algorithm that finds the EXIT vertex in fewer than ~2<sup>n</sup> steps---say, in O(2<sup>n/2</sup>), or O(2<sup>2n/3</sup>)?  Alternatively, can anyone give a lower bound better than &Omega;(2<sup>n/2</sup>)?</b></p>

<p>(Note that, by the birthday paradox, it's not hard to find cycles in the graph after O(2<sup>n/2</sup>) steps.  The question is whether one can <i>use</i> the cycles to get any clues about where the EXIT vertex is.)</p>

<p>If anyone can improve the lower bound past &Omega;(2<sup>n/2</sup>), then to my knowledge, this would provide the very first provable example of a black-box problem with an exponential quantum speedup, whose randomized query complexity is greater than &radic;N.  (Where N~2<sup>n</sup> is the problem size.)</p>

<p><b>Update:</b> I've learned from Andrew Childs that, in <a href="http://arxiv.org/pdf/quant-ph/0312230v1.pdf" rel="noreferrer">this note</a>, Fenner and Zhang explicitly improve the randomized lower bound for conjoined trees to &Omega;(2<sup>n/3</sup>).  If they were willing to accept constant (rather than exponentially-small) success probability, I believe they could improve the bound further, to &Omega;(2<sup>n/2</sup>).</p>

<p><img src="https://i.sstatic.net/n78YZ.jpg" alt="enter image description here"></p>

<graph-algorithms><quantum-computing><randomized-algorithms><random-walks><decision-trees>
The randomized query complexity of the conjoined trees problem
Scott Aaronson
# The randomized query complexity of the conjoined trees problem

(Asked by: username_0 on 2014-07-19)

An [important 2003 paper by Childs et al.](http://arxiv.org/pdf/quant-ph/0209131v2.pdf) introduced the "conjoined trees problem": a problem admitting an exponential quantum speedup that's unlike just about any other such problem that we know of. In this problem, we're given an exponentially-large graph like the one pictured below, which consists of two complete binary trees of depth n, whose leaves are connected to each other by a random cycle. We're supplied with the label of the ENTRANCE vertex. We're also supplied with an oracle that, given as input the label of any vertex, tells us the labels of its neighbors. Our goal is to find the EXIT vertex (which can easily be recognized, as the only degree-2 vertex in the graph other than the ENTRANCE vertex). We can assume that the labels are long random strings, so that with overwhelming probability, the only way to learn the label of *any* vertex other than the ENTRANCE vertex is to be given it by the oracle.

Childs et al. showed that a quantum walk algorithm is able simply to barrel through this graph, and find the EXIT vertex after poly(n) steps. By contrast, they also showed that any classical randomized algorithm requires exp(n) steps to find the EXIT vertex with high probability. They stated their lower bound as Ω(2n/6), but I believe that a closer examination of their proof yields Ω(2n/2). Intuitively, this is because with overwhelming probability, a random walk on the graph (even a self-avoiding walk, etc.) will get stuck in the vast middle region for an exponential amount of time: any time a walker starts heading toward the EXIT, the much larger number of edges pointing away from the EXIT will act as a "repulsive force" that pushes it back toward the middle.

The way they formalized the argument was to show that, until it's visited ~2n/2 vertices, a randomized algorithm hasn't even found any *cycles* in the graph: the induced subgraph that it's seen so far is just a tree, providing no information whatsoever about where the EXIT vertex might be.

I'm interested in pinning down the randomized query complexity of this problem more precisely. My question is this:

**Can anyone come up with a classical algorithm that finds the EXIT vertex in fewer than ~2n steps---say, in O(2n/2), or O(22n/3)? Alternatively, can anyone give a lower bound better than Ω(2n/2)?**

(Note that, by the birthday paradox, it's not hard to find cycles in the graph after O(2n/2) steps. The question is whether one can *use* the cycles to get any clues about where the EXIT vertex is.)

If anyone can improve the lower bound past Ω(2n/2), then to my knowledge, this would provide the very first provable example of a black-box problem with an exponential quantum speedup, whose randomized query complexity is greater than √N. (Where N~2n is the problem size.)

**Update:** I've learned from Andrew Childs that, in [this note](http://arxiv.org/pdf/quant-ph/0312230v1.pdf), Fenner and Zhang explicitly improve the randomized lower bound for conjoined trees to Ω(2n/3). If they were willing to accept constant (rather than exponentially-small) success probability, I believe they could improve the bound further, to Ω(2n/2).

![enter image description here](https://i.sstatic.net/n78YZ.jpg)

**Tags:** graph-algorithms, quantum-computing, randomized-algorithms, random-walks, decision-trees


---

## 1 answers

### Answer by username_1 on 2014-07-20. Score: 23 | Accepted answer

I think I have a deterministic algorithm that finds the exit in $O(n2^{n/2})$ oracle calls.

First, find the labels for all the vertices of distance $n/2$ from the entrance. This takes $O(2^{n/2})$ queries. Then, start from the entrance and walk $n+1$ steps to get to a node $X$ of distance $n+1$ from the entrance. We will try to reach the exit from this node.

We have two options of where to go from $X$, and we wish to choose the one closer to the exit. To do this, pick one of the options arbitrarily, arriving at a node $Y$. Then explore all the $O(2^{n/2})$ ways of walking $n/2$ steps from $Y$. If one of them gives a label of distance $n/2$ from the entrance, we know that going from $X$ to $Y$ was the wrong choice. Otherwise, $Y$ was the right choice. Thus in $O(2^{n/2})$ we found a node $X\_2$ of distance $n+2$ from the entrance.

We can keep proceeding this way. To find a node of distance $n+3$ from the entrance, we start at $X\_2$ and walk two arbitrary steps. We then explore all options of walking $n/2$ additional steps (while never walking backwards), and check if any of them have distance $n/2$ from the entrance. This will happen if and only if the first step we walked from $X\_2$ was wrong.

Getting to the exit requires doing this $n$ times, for a total of $O(n2^{n/2})$ oracle calls. In addition, perhaps surprisingly, this algorithm is deterministic.

**Edit:** Just to clarify, to get from $X\_t$ to $X\_{t+1}$, we walk $t$ arbitrary steps, then run a search of depth $n/2$, for a total of $t+2^{n/2}$ steps. If the first step lead away from the exit, then all the first $t$ steps did, and we therefore find a label of distance $n/2$ from the entrance. This means $t+2^{n/2}$ steps suffice for determining the next single step to take from $X\_t$.

> **Comments:**
> **username_2**: I don't understand. To find $X_{t+1}$, you would make $t$ arbitrary steps from $X_t$ and then $n/2$ additional steps? Wouldn't this give $2^t2^{n/2}$ steps which is too much?  
> **username_0**: I second username_2's confusion.  Isn't it the case that, the closer you get to the EXIT, the longer the path you're going to need to get to one of the $2^{n/2}$ points that you queried at the beginning?  Still, maybe you could exploit the fact that paths that start close to the EXIT are extremely likely to move left toward the center until they reach it?  (This would add a bit of randomization to your algorithm.)  
> **username_0**: Come to think of it, what if we took advantage of the fact that, from any vertex in the right half of the graph, you have a 1/2 chance of picking a direction that's going to lead you *inexorably* back to the center?  That might be enough to get us n/2 away from the EXIT vertex, which would then allow us to find the EXIT vertex itself with $2^{n/2}$ further queries.  
> **username_1**: To find $X_{t+1}$, make $t$ arbitrary steps from $X_t$, but _only once_. This takes $t$ steps, not $2^t$ steps. Then make $n/2$ steps in _all possible ways_. This takes $2^{n/2}$ steps. The total is $t+2^{n/2}$.  I'm using the fact that if the first of the $t$ steps was wrong, then all $t$ of these steps lead away from the exit (and back towards the entrance). This stops being the case after the first $t$ steps, which is why you need to start an exhaustive search.  
> **username_2**: I see, so your algorithm to find $X_{t+1}$ from $X_{t}$ is 1, Go $t$ steps 2, Test whether we are in the center 3, If no, use first step of the $t$ steps to get $X_{t+1}$ 4, If yes, use the other edge from $X_{t}$ to get $X_{t+1}$ Nice!  
> **username_3**: The idea of starting a search from both ends and leading to a sqrt() improvement over the naive algorithm is known as *bidirectional search* and has been rediscovered independently many times in various contexts e.g. route planning in google maps. The original reference seems to be:   G. B. Dantzig. Linear Programming and Extensions. Princeton University Press, 1962.  

---

