(These code examples are in CoffeeScript. Click Here for code examples in JavaScript.)
A good long while ago (The First Age of Internet Startups), someone asked me one of those pet algorithm questions. It was, “Write an algorithm to detect a loop in a linked list, in constant space.”
I’m not particularly surprised that I couldn’t think up an answer in a few minutes at the time. And to the interviewer’s credit, he didn’t terminate the interview on the spot, he asked me to describe the kinds of things going through my head.
I think I told him that I was trying to figure out if I could adapt a hashing algorithm such as XORing everything together. This is the “trick answer” to a question about finding a missing integer from a list, so I was trying the old, “Transform this into a problem you’ve already solved” meta-algorithm. We moved on from there, and he didn’t reveal the “solution.”
I went home and pondered the problem. I wanted to solve it. Eventually, I came up with something and tried it (In Java!) on my home PC. I sent him an email sharing my result, to demonstrate my ability to follow through. I then forgot about it for a while.
Some time later, I was told that the correct solution was:
class LinkedList
constructor: (@content, @next = undefined) ->
appendTo: (content) ->
new LinkedList(content, this)
tailNode: ->
@next?.tailNode() or this
tortoiseAndHareLoopDetector = (list) ->
tortoise = list
hare = list.next
while tortoise? and hare?
return true if tortoise is hare
tortoise = tortoise.next
hare = hare.next?.next
false
list = new LinkedList(5).appendTo(4).appendTo(3).appendTo(2).appendTo(1)
tortoiseAndHareLoopDetector(list)
#=> false
list.tailNode().next = list.next
# five now points to two
tortoiseAndHareLoopDetector list
#=> true
This algorithm is called “The Tortoise and the Hare,” and was discovered by Robert Floyd in the 1960s. You have two node references, and one traverses the list at twice the speed of the other. No matter how large it is, you will eventually have the fast reference equal to the slow reference, and thus you’ll detect the loop.
At the time, I couldn’t think of any way to use hashing to solve the problem, so I gave up and tried to fit this into a powers-of-two algorithm. My first pass at it was clumsy, but it was roughly equivalent to this:
teleportingTurtleLoopDetector = (list) ->
speed = 1
turtle = rabbit = list
# tortoise is now the first element, hare the second (if there is one)
while true
for i in [0..speed] by 1
rabbit = rabbit.next
return false unless rabbit?
return true if rabbit is turtle
turtle = rabbit
speed *=2
false
list = new LinkedList(5).appendTo(4).appendTo(3).appendTo(2).appendTo(1)
teleportingTurtleLoopDetector(list)
#=> false
list.tailNode().next = list.next
# five now points to two
teleportingTurtleLoopDetector list
#=> true
Today, thanks to Reddit, I came across a discussion of this algorithm, The Tale of the Teleporting Turtle. I’d like to congratulate myself for thinking of a fast algorithm, but the simple truth is that I got lucky. It’s not like I thought of both algorithms and compared them on the basis of time complexity. Nor, for that matter, did I think of it in the interview.
Reading about these algorithms today reminded me of a separation of concerns issue: Untangling how you traverse a data structure from what you do with its elements.
a very simple problem
Let’s consider a remarkably simple problem: Finding the sum of the elements of an array. In iterative style, it looks like this:
sum = (array) ->
total = 0
total += number for number in array
total
What’s the sum of a linked list of numbers? How about the sum of a tree of numbers (represented as an array of array of numbers)? Must we re-write the sum function for each data structure?
There are two roads ahead. One involves a generalized reduce or fold method for each data structure. The other involves writing an Iterator for each data structure and writing our sum to take an iterator as its argument. Let’s use iterators, especially since we need two different iterators for the same data structure, so a single object method is inconvenient.
Since we don’t have iterators baked into the underlying JavaScript engine yet, we’ll write our iterators as functions:
class LinkedList
constructor: (@content, @next = undefined) ->
appendTo: (content) ->
new LinkedList(content, this)
tailNode: ->
@next?.tailNode() or this
ListIterator = (list) ->
->
node = list?.content
list = list?.next
node
sum = (iter) ->
total = 0
number = iter()
while number?
total += number
number = iter()
total
list = new LinkedList(5).appendTo(4).appendTo(3).appendTo(2).appendTo(1)
sum ListIterator list
#=> 15
ArrayIterator = (array) ->
index = 0;
->
array[index++]
sum ArrayIterator [1..5]
#=> 15
Summing an array that can contain nested arrays adds a degree of complexity. Writing a function that iterates recursively over a data structure is an interesting problem, one that is trivial in a language with coroutines. Since we don’t have Generators yet, and we don’t want to try to turn our loop detection inside-out, we’ll Greenspun our own coroutine by maintaining our own stack.
This business of managing your own stack may seem weird to anyone born after 1970, but old fogeys fondly remember that after walking barefoot to and from University uphill in a blizzard both ways, the interview question brain teaser of the day was to write a “Towers of Hanoi” solver in a language like BASIC that didn’t have reentrant subroutines.
LeafIterator = (array) ->
index = 0
state = []
myself = ->
element = array[index++]
if element instanceof Array
state.push({array, index})
array = element
index = 0
myself()
else if element is undefined
if state.length > 0
{array, index} = state.pop()
myself()
else
undefined
else
element
myself
sum LeafIterator [1, [2, [3, 4]], [5]]
#=> 15
We’ve successfully separated the issue of what one does with data from how one traverses over the elements.
folding
Just as pure functional programmers love to talk monads, newcomers to functional programming in multi-paradigm languages often drool over folding a/k/a mapping/injecting/reducing. We’re just a level of abstraction away:
fold = (iter, binaryFn, seed) ->
acc = seed
element = iter()
while element?
acc = binaryFn.call(element, acc, element)
element = iter()
acc
foldingSum = (iter) -> fold iter, ((x, y) -> x + y), 0
foldingSum LeafIterator [1, [2, [3, 4]], [5]]
Fold turns an iterator over a finite data structure into an accumulator. And once again, it works with any data structure. You don’t need a different kind of fold for each kind of data structure you use.
unfolding and laziness
Iterators are functions. When they iterate over an array or linked list, they are traversing something that is already there. But they could, in principle, manufacture the data as they go. Let’s consider the simplest example:
NumberIterator = (base = 0) ->
number = base
->
number++
fromOne = NumberIterator(1)
fromOne()
#=> 1
fromOne()
#=> 2
fromOne()
#=> 3
fromOne()
#=> 4
fromOne()
#=> 5
And here’s another one:
FibonacciIterator = ->
previous = 0
current = 1
->
value = current
[previous, current] = [current, current + previous]
value
fib = FibonacciIterator()
fib()
#=> 1
fib()
#=> 1
fib()
#=> 2
fib()
#=> 3
fib()
#=> 5
A function that starts with a seed and expands it into a data structure is called an unfold. It’s the opposite of a fold. It’s possible to write a generic unfold mechanism, but let’s pass on to what we can do with unfolded iterators.
This business of going on forever has some drawbacks. Let’s introduce an idea: A function that takes an Iterator and returns another iterator. We can start with take, an easy function that returns an iterator that only returns a fixed number of elements:
take = (iter, numberToTake) ->
count = 0
->
if ++count <= numberToTake
iter()
else
undefined
oneToFive = take NumberIterator(1), 5
oneToFive()
#=> 1
oneToFive()
#=> 2
oneToFive()
#=> 3
oneToFive()
#=> 4
oneToFive()
#=> 5
oneToFive()
#=> undefined
With take, we can do things like return the squares of the first five numbers:
square take NumberIterator(1), 5
#=> [ 1,
# 4,
# 9,
# 16,
# 25 ]
How about the squares of the odd numbers from the first five numbers?
square odds take NumberIterator(1), 5
#=> TypeError: object is not a function
Bzzzt! Our odds function returns an array, not an iterator.
square take odds(NumberIterator(1)), 5
#=> RangeError: Maximum call stack size exceeded
You can’t take the first five odd numbers at all, because odds tries to get the entire set of numbers and accumulate the odd ones in an array. This can be fixed. For unfolds and other infinite iterators, we need more functions that transform one iterator into another:
iteratorMap = (iter, unaryFn) ->
->
element = iter()
if element?
unaryFn.call(element, element)
else
undefined
squaresIterator = (iter) -> iteratorMap iter, (n) -> n * n
iteratorFilter = (iter, unaryPredicateFn) ->
->
element = iter()
while element?
return element if unaryPredicateFn.call(element, element)
element = iter()
undefined
oddsFilter = (iter) -> iteratorFilter iter, odd
Now we can do things like take the sum of the first five odd squares of fibonacci numbers:
foldingSum take (oddsFilter squaresIterator FibonacciIterator()), 5
#=> 205
This solution composes the parts we already have, rather than writing a tricky bit of code with ifs and whiles and boundary conditions.
summary
Untangling the concerns of how to iterate over data from what to do with data leads us to thinking of iterators and working directly with iterators. For example, we can map and filter iterators rather than trying to write separate map and filter functions or methods for each type of data structure. This leads to the possibility of working with lazy or infinite iterators.
next
In The “Drunken Walk” Programming Problem, we’ll refactor the “Tortoise and Hare” algorithm to solve an isomorphic programming problem.
This material also appears in the book JavaScript Allongé.