<p>You could do regular expression matching. A naive backtracking matcher can easily be pushed into exponential behavior on inputs that a smarter matcher can handle in linear time. </p>

CC BY-SA 3.0
2011-06-25T23:24:28.350Z
2011-06-25T23:24:28.350Z
Neel Krishnaswami
<p>Try counting perfect matchings in planar graphs, a problem that should be easy to explain. In the planar case, the <a href="http://en.wikipedia.org/wiki/FKT_algorithm" rel="nofollow noreferrer">Fisher-Kastelyen-Temperley algorithm</a> solves it in polynomial time, whereas for general graphs the problem is #P-complete, i.e. probably no faster way than to do brute force counting. Simply run FKT on the slow machine and brute force counting on the fast one.</p>

<p>(<a href="https://cstheory.stackexchange.com/questions/6399/surprising-algorithms-for-counting-problems">This</a> is also a related question.)</p>

CC BY-SA 3.0
2011-06-25T17:15:35.833Z
2011-06-25T17:48:11.513Z
2017-04-13T12:32:28.053Z
Martin Schwarz
<p>If you are teaching algorithms I think you should do something simple, that illustrates the idea. I think that your sorting algorithm idea is a very good one and probably work if you try non-recursive algorithms in the primitive computer.</p>

<p>I'm currently comparing sorting algorithms and I have Heap Sort running with 17,000 elements on a computer with 32kb ram.</p>

<p>I would try insertion sort vs Heap Sort.</p>

CC BY-SA 3.0
2011-06-26T23:21:25.577Z
But insertion sort of 17000 elements on a modern computer is pretty fast. (The question already alludes to this.)
Radu GRIGore
CC BY-SA 3.0
2011-06-26T12:05:29.893Z
2011-06-26T12:05:29.893Z
Topo
<p>An answer that somewhat generalizes Neel's comment is to look in the area of search and dynamic programming, which is full of wonderful algorithms that perform great if you memoize and terribly if you do not - even the boring factorial function you were thinking of falls in this category. </p>

<p>Of course, you will be limited by the memory ceiling on the slow computer, but I think that just means you have to be careful that you're sufficiently "mean" to the fast computer. Here are some specific ideas:</p>

<ul>
<li>Given a large undirected graph, find a path between two points. The fast computer implements a (fair, or it might not terminate!) randomized search through the graph, whereas the slow computer calmly performs a breadth-first or depth-first search. You'd probably need to run this on multiple trials to ensure that the performance difference is noticable.</li>
<li>Get a directed graph and try to find the shortest path between two points: fast computer enumerates all acyclical paths (using the tortoise-and-hare cycle detection algorithm at every step, bwahahahaha) first, and the slow computer patiently runs single-source shortest path.</li>
<li>The edit distance algorithm? Any more-naive-than-dynamic-programming algorithm is probably going to completely choke here.</li>
</ul>

<p>One last idea is that you could try some algorithms in Prolog with and without an (unnecessary) occurs-check. But if you show those students how wonderful it is that Prolog without a semantically meaningful occurs-check is faster, I will cry. Also, this is usually a linear-vs-quadratic not polynomial-versus-exponential.</p>

CC BY-SA 3.0
2011-06-26T11:15:32.133Z
2011-06-26T11:15:32.133Z
Rob Simmons
<p>I'm planning on running an “experiment” when teaching my algorithms class this fall, with one very old, limited computer (main limiting factor is probably memory—possibly as low as 16KB) and one modern/standard one. The idea being to solve a problem with a polynomial one, running on the slow computer, and an exponential one on the fast one (and, of course, have the slow one win).</p>

<p>The problem is finding a suitable problem—one where the running times will be really different for instances of very limited size (and, preferably, where the data structures are quite simple; the primitive computer is … primitive). I originally thought about sorting algorithms (e.g., quadratic vs. linear), but that would require far too large instances (unless I went with bogosort, for example).</p>

<p>At the moment, the only (rather boring) example I've thought of is computing Fibonacci numbers the smart and the stupid way. It would be nice to have something a little less tired/overused, and preferably something (semi-)obviously useful. Any ideas/suggestions?</p>

CC BY-SA 3.0
2011-06-25T15:24:17.900Z
Actually, I was planning on using the pseudopolynomial (“linear in Fibonacci rank”) and superexponential (recursive) solutions to the problem; the main point is the obvious difference in complexity, which lets the weaker computer win easily.
Magnus Lie Hetland
CC BY-SA 3.0
2011-06-25T16:27:16.140Z
Bipartite maximum-weight matching (Hungarian vs. brute-force)?
Jukka Suomela
<ds.algorithms><teaching>
Example problems with polynomial and exponential solutions, and tiny footprint?
Magnus Lie Hetland
# Example problems with polynomial and exponential solutions, and tiny footprint?

(Asked by: username_0 on 2011-06-25)

I'm planning on running an “experiment” when teaching my algorithms class this fall, with one very old, limited computer (main limiting factor is probably memory—possibly as low as 16KB) and one modern/standard one. The idea being to solve a problem with a polynomial one, running on the slow computer, and an exponential one on the fast one (and, of course, have the slow one win).

The problem is finding a suitable problem—one where the running times will be really different for instances of very limited size (and, preferably, where the data structures are quite simple; the primitive computer is … primitive). I originally thought about sorting algorithms (e.g., quadratic vs. linear), but that would require far too large instances (unless I went with bogosort, for example).

At the moment, the only (rather boring) example I've thought of is computing Fibonacci numbers the smart and the stupid way. It would be nice to have something a little less tired/overused, and preferably something (semi-)obviously useful. Any ideas/suggestions?

**Tags:** ds.algorithms, teaching

> **Comments:**
> **username_0**: Actually, I was planning on using the pseudopolynomial (“linear in Fibonacci rank”) and superexponential (recursive) solutions to the problem; the main point is the obvious difference in complexity, which lets the weaker computer win easily.  
> **username_1**: Bipartite maximum-weight matching (Hungarian vs. brute-force)?  

---

## 4 answers

### Answer by username_6 on 2011-06-26. Score: 6 | Accepted answer

An answer that somewhat generalizes Neel's comment is to look in the area of search and dynamic programming, which is full of wonderful algorithms that perform great if you memoize and terribly if you do not - even the boring factorial function you were thinking of falls in this category.

Of course, you will be limited by the memory ceiling on the slow computer, but I think that just means you have to be careful that you're sufficiently "mean" to the fast computer. Here are some specific ideas:

* Given a large undirected graph, find a path between two points. The fast computer implements a (fair, or it might not terminate!) randomized search through the graph, whereas the slow computer calmly performs a breadth-first or depth-first search. You'd probably need to run this on multiple trials to ensure that the performance difference is noticable.
* Get a directed graph and try to find the shortest path between two points: fast computer enumerates all acyclical paths (using the tortoise-and-hare cycle detection algorithm at every step, bwahahahaha) first, and the slow computer patiently runs single-source shortest path.
* The edit distance algorithm? Any more-naive-than-dynamic-programming algorithm is probably going to completely choke here.

One last idea is that you could try some algorithms in Prolog with and without an (unnecessary) occurs-check. But if you show those students how wonderful it is that Prolog without a semantically meaningful occurs-check is faster, I will cry. Also, this is usually a linear-vs-quadratic not polynomial-versus-exponential.


---

### Answer by username_2 on 2011-06-25. Score: 9

You could do regular expression matching. A naive backtracking matcher can easily be pushed into exponential behavior on inputs that a smarter matcher can handle in linear time.


---

### Answer by username_3 on 2011-06-25. Score: 5

Try counting perfect matchings in planar graphs, a problem that should be easy to explain. In the planar case, the [Fisher-Kastelyen-Temperley algorithm](http://en.wikipedia.org/wiki/FKT_algorithm) solves it in polynomial time, whereas for general graphs the problem is #P-complete, i.e. probably no faster way than to do brute force counting. Simply run FKT on the slow machine and brute force counting on the fast one.

([This](https://cstheory.stackexchange.com/questions/6399/surprising-algorithms-for-counting-problems) is also a related question.)


---

### Answer by username_4 on 2011-06-26. Score: 1

If you are teaching algorithms I think you should do something simple, that illustrates the idea. I think that your sorting algorithm idea is a very good one and probably work if you try non-recursive algorithms in the primitive computer.

I'm currently comparing sorting algorithms and I have Heap Sort running with 17,000 elements on a computer with 32kb ram.

I would try insertion sort vs Heap Sort.

> **Comments:**
> **username_5**: But insertion sort of 17000 elements on a modern computer is pretty fast. (The question already alludes to this.)  

---

