I coded the simplest examples from

• Defunctionalization at work. O Danvy, LR Nielsen. PPDP 2001.

in literate Haskell for the audience, and also showed off QuickCheck a little to make sure the translation was correct (finding one error, if I recall).

This blog post is a merging of my talk outline and new stuff that came up live. Try loading it up in GHCi or Haskell-mode and running the examples and QuickCheck properties.

> {-# LANGUAGE RankNTypes #-}

> import Prelude hiding (reverse)
> import Control.Monad
> import Control.Monad.Cont
> import Test.QuickCheck

Broadly, defunctionalization is transforming a program to eliminate higher-order functions. Rather than focus on its use for compilation (see this H Cejtin, S Jagannathan, S Weeks paper on MLTon) or analyses (see Firstify from N Mitchell and C Runciman). I wanted to emphasize its use in understanding your own program, along the lines of Wand’s Continuation-Based Program Transformation Strategies (JACM 1980).

Here is the first example from Danvy.

> aux1 :: (Int -> Int) -> Int
> aux1 f = f 1 + f 10
>
> main1 x y b = (aux1 (\z -> x + z)) * 
>               (aux1 (\z -> if b then y + z else y - z))

Defunctionalization replaces all the first-class functions with an explicit data structure Lam1 and a global apply1 function, essentially embedding a mini-interpreter for just those lambda terms occurring in the program.

> data Lam1 = Lam1A Int      -- (Lam1A x)   ~ (\z -> x + z)
>           | Lam1B Int Bool -- (Lam1B y b) ~ (\z -> if b then y + z else y - z)
>
> apply1 :: Lam1 -> Int -> Int
> apply1 (Lam1A x)   z = x + z
> apply1 (Lam1B y b) z = if b then y + z else y - z
>
> aux1defun :: Lam1 -> Int
> aux1defun f = (apply1 f 1) + (apply1 f 10)
>
> main1defun x y b = (aux1defun (Lam1A x)) *
>                    (aux1defun (Lam1B y b))

Is it correct? Ask quickcheck:

> prop1 x y b = (main1 x y b == main1defun x y b)

*Main> quickCheck prop1
+++ OK, passed 100 tests.

Next example: flattening a binary tree

> data BinaryTree a = Leaf a
>                   | Node (BinaryTree a) (BinaryTree a)

First, there is the straightforward, inefficient version of flatten

> flatten (Leaf x) = [x]
> flatten (Node t1 t2) = (flatten t1) ++ (flatten t2)

We can represent our output with difference lists offering O(1) append.

> flatten' t = walk t []
>   where walk (Leaf x)     = (x:)
>         walk (Node t1 t2) = (walk t1) . (walk t2)

And now that we’ve introduced a bunch of first-class functions, let’s see what happens when we defunctionalize them.

> data LamBTree a = LamBTreeA a -- (x:)
>                 | LamBTreeB (LamBTree a) (LamBTree a) -- (u . v)
>
> applyBTree (LamBTreeA x)   l = x:l
> applyBTree (LamBTreeB u v) l = applyBTree u (applyBTree v l)
>
> flatten_defun t = applyBTree (walk t) []
>   where walk (Leaf x)     = LamBTreeA x
>         walk (Node t1 t2) = LamBTreeB (walk t1) (walk t2)

Note how LamBTree looks just like the definition of BinaryTree, because it is a catamorphism, hence a hylomorphism, i.e. a recursive function with a call tree that looks like a BinaryTree or whatever structure you are hylo’ing over. (See Sorting morphisms for a beautiful examples of using this to understand your program (L Augusteijn. AFP 1998)). So walk is pretty much the identity function on trees, and then applyBTree is a flatten function with an accumulating parameter. Ignoring the intermediate structure, then we see defunctionalization as a way to derive accumulating parameters.

> prop_flatten :: BinaryTree Int -> Bool
> prop_flatten t = (flatten_defun t == flatten t)

*Main> quickCheck prop_flatten
OK, passed 100 tests

Defunctionalization as an inverse to church encoding

This was possibly my favorite part of Danvy’s paper, but I unfortunately had to elide it from my talk as being slightly too esoteric for the mixed crowd.

Let us suppose that tuples were not built in to Haskell but we needed to make them ourselves. The data type and destructors would look like this:

> data MyPair a b = P a b 
>                 deriving (Eq,Show)
>
> myPair x y    = P x y
> myFst (P x y) = x
> mySnd (P x y) = y

And we can ask Quickcheck to test extensionality.

> prop_pair :: MyPair Int Int -> Bool
> prop_pair p = (p == myPair (myFst p) (mySnd p))

*Main> quickCheck prop_pair
+++ OK, passed 100 tests.

So, if you recall whatever lambda-calculus course you may have taken, we can represent them with only functions. I like having rank-N type available for this.

> type ChurchPair a b = (forall c . a -> b -> (a -> b -> c) -> c)

> churchPair x y = (\operation -> operation x y)
> churchFst  p   = p (\x y -> x)
> churchSnd  p   = p (\x y -> y)

Rather than make an Arbitrary instance, I’ll settle for reduction rules in this case.

> prop_churchPair :: Int -> Int -> Bool
> prop_churchPair x y = (x == churchFst (churchPair x y)) &&
>                       (y == churchSnd (churchPair x y))

*Main> quickCheck prop_churchPair
+++ OK, passed 100 tests.

But now I’ve introduced a bunch of higher-order functions, so we just have to see how they defunctionalize!

> data LamSelector = LamFst | LamSnd
> applySelector (LamFst) x y = x
> applySelector (LamSnd) x y = y
>
> data LamPair a b = LamPair a b
> applyPair (LamPair x y) operation = applySelector operation x y
>
> defunPair x y = (LamPair x y)
> defunFst  p   = applyPair p LamFst
> defunSnd  p   = applyPair p LamSnd

You can see that this just reproduces the original, modulo inlining!

Now let’s church-encode BinaryTree as its own fold (or catamorphism, if you like). So we have something to defunctionalize, let’s write churchDepth to calculate the depth of the tree.

> type ChurchTree a = forall c. (a -> c) -> (c -> c -> c) -> c

> churchLeaf x     = \onLeaf onNode -> onLeaf x
> churchNode t1 t2 = \onLeaf onNode -> onNode (t1 onLeaf onNode) (t2 onLeaf onNode)
>
> churchFold onLeaf onNode t = t onLeaf onNode

> churchDepth t = t (\x -> 0) (\d1 d2 -> 1 + (d1 `max` d2))

Acknowledging that the church encoding is just the fold, we can defunctionalize the fold over any functor to recover the data type. Anyhow…

> data LamLeaf = LamLeaf -- onLeaf
> applyLeaf LamLeaf x = 0
>
> data LamNode = LamNode -- onNode
> applyNode LamNode d1 d2 = 1 + (d1 `max` d2)
>
> data LamTree a = LamTreeLeaf a   -- churchLeaf
>                | LamTreeNode (LamTree a) (LamTree a) -- churchNode
>
> applyTree (LamTreeLeaf x)     onLeaf onNode = applyLeaf onLeaf x
> applyTree (LamTreeNode t1 t2) onLeaf onNode = 
>   applyNode onNode (applyTree t1 onLeaf onNode)
>                    (applyTree t2 onLeaf onNode)
> depth_defun t = applyTree t LamLeaf LamNode

applyTree is just fold over a tree, as promised, and we’ve recovered the tree data structure.

Defunctionalize your continuation

Suppose you have a first-order (boring!) program. You can’t have any fun until you find a way to introduce some first-class functions. A classic way to introduce a gratuitous number is to convert your code into continuation-passing style. Let’s try it.

This is Danvy’s ’s example of a parser to recognize the language . It is written with an auxiliary function in the Maybe monad to simulate throwing an exception as soon as we can reject the string.

> recognize :: [Int] -> Bool
> recognize xs = case walk xs of Just [] -> True
>                                _       -> False 
>   where 
>     walk :: [Int] -> Maybe [Int]
>     walk (0:xs') = do remaining <- walk xs'
>                       case remaining of (1:ys) -> Just ys
>                                         _      -> Nothing
>     walk xs = Just xs -- otherwise

The audience insisted that I test this, because it is a bit of a weird way to write a trivial function.

> prop_recognize1 n = recognize (take n (repeat 0) ++ take n (repeat 1))
> prop_recognize2 m n = (m >= 0 && n >= 1 && m /= n) 
>    ==> (not (recognize (take m (repeat 0) ++ take n (repeat 1))))

*Main> quickCheck prop_recognize1
+++ OK, passed 100 tests.
*Main> quickCheck prop_recognize2
+++ OK, passed 100 tests.

Now if we CPS it, we no longer need the Maybe because we can just discard the continuation and return False.

> recognize' :: [Int] -> Bool
> recognize' xs = walk xs (\xs' -> [] == xs')
>   where
>     walk :: [Int] -> ([Int] -> Bool) -> Bool
>     walk (0:xs') k = walk xs' (\rem -> case rem of (1:ys) -> k ys
>                                                    _      -> False)
>     walk xs      k = k xs -- otherwise

And defunctionalizing it

> data Continuation = ContToplevel     -- (\xs' -> null xs')
>                   | ContRecurse Continuation -- (\remaining -> ... )
>
> applyCont ContToplevel    l = (l==[])
> applyCont (ContRecurse k) l = case l of (1:ys) -> applyCont k ys
>                                         _      -> False
>
> recognize'' xs = walk xs ContToplevel
>   where
>     walk (0:xs') k = walk xs' (ContRecurse k)
>     walk xs      k = applyCont k xs

But now we can look and see that the continuation data structure is just implementing natural numbers, so we replace it by an Int.

> applyNumCont 0 []     = True
> applyNumCont k (1:xs) = applyNumCont (k-1) xs
> applyNumCont _ _      = False

> recognize_final xs = walk xs 0
>   where walk (0:xs') k = walk xs' (k+1)
>         walk xs      k = k xs

We get the program we should have written in the first place.

I didn’t get to the rest of this in my talk, and anyhow it is most interesting to people who play with operational semantics a lot. This last bit is from Danvy’s paper On Evaluation Contexts, Continuations, and The Rest of Computation from the continuation workshop in 2004.

We have a simple arithmetic language, and two ways of giving it a semantics: We can either reduce the expression a single small step, using reduceAllTheWay to normalize it, or we can eval the expression directly to a result.

> data Exp = Value Int
>          | Add Exp Exp
>
> reduce :: Exp -> Exp
> reduce (Add (Value v1) (Value v2)) = Value (v1 + v2)
> reduce (Add (Value v1) e2        ) = Add (Value v1) (reduce e2)
> reduce (Add e1         e2        ) = Add (reduce e1) e2
>
> reduceAllTheWay :: Exp -> Int
> reduceAllTheWay (Value v) = v
> reduceAllTheWay e = reduceAllTheWay (reduce e)
>
> eval :: Exp -> Int
> eval (Value v)   = v
> eval (Add e1 e2) = (eval e1) + (eval e2)

Now we CPS both of them

> reduceCPS :: Exp -> (Exp -> a) -> a
> reduceCPS (Add (Value v1) (Value v2)) k = k (Value (v1 + v2))
> reduceCPS (Add (Value v1) e2        ) k = reduceCPS e2 (\e -> k (Add (Value v1) e))
> reduceCPS (Add e1         e2        ) k = reduceCPS e1 (\e -> k (Add e e2))
>
> reduceAllTheWayCPS :: Exp -> (Int -> a) -> a
> reduceAllTheWayCPS (Value v) k = k v
> reduceAllTheWayCPS e         k = reduceCPS e (flip reduceAllTheWayCPS k)

> evalCPS :: Exp -> (Int -> a) -> a
> evalCPS (Value v)   k = k v
> evalCPS (Add e1 e2) k = evalCPS e1 (\v1 -> evalCPS e2 (\v2 -> k (v1 + v2)))

CPS code is easier to read when I write it like this

> evalCPS' :: Exp -> (Int -> a) -> a
> evalCPS' (Value v)   k = k v
> evalCPS' (Add e1 e2) k = evalCPS e1 (\v1 ->
>                          evalCPS e2 (\v2 ->
>                          k (v1+v2)  ))

and I might as well admit that Haskell already has this in the bag

> evalCPS'' :: Exp -> Cont a Int
> evalCPS'' (Value v)   = return v
> evalCPS'' (Add e1 e2) = do v1 <- evalCPS'' e1
>                            v2 <- evalCPS'' e2
>                            return (v1 + v2)

Now we defunctionalize both semantics

> data ContReduce = ContReduce  -- (flip reduceAllTheWay)
>                 | ContAddV1 Exp ContReduce -- (\e -> Add (Value v1) e)
>                 | ContAddE2 ContReduce Exp -- (\e -> Add e e2)
>
> applyContReduce :: ContReduce -> Exp -> Exp
> applyContReduce ContReduce e = e
> applyContReduce (ContAddV1 v1 k) e = applyContReduce k (Add v1 e)
> applyContReduce (ContAddE2 k e2) e = applyContReduce k (Add e e2)
>
> reduceCPSdefun :: Exp -> ContReduce -> Exp
> reduceCPSdefun (Add (Value v1) (Value v2)) k = applyContReduce k (Value (v1 + v2))
> reduceCPSdefun (Add (Value v1) e2        ) k = reduceCPSdefun e2 (ContAddV1 (Value v1) k)
> reduceCPSdefun (Add e1         e2        ) k = reduceCPSdefun e1 (ContAddE2 k e2)

The data type ContReduce is the now-common notion of an “evaluation context” which some researchers prefer because it separates the important rules about how terms are reduced from the rules that just tell you where in a term reduction happens.

Next…

> data ContEval = ContEval -- toplevel
>               | ContE1 ContEval Exp
>               | ContE2 Int ContEval
>
> applyContEval :: ContEval -> Int -> Int
> applyContEval (ContEval) v = v
> applyContEval (ContE1 k e2) v1 = evalCPSdefun e2 (ContE2 v1 k) 
> applyContEval (ContE2 v1 k) v2 = applyContEval k (v1 + v2)
>
> evalCPSdefun (Value v)   k = applyContEval k v
> evalCPSdefun (Add e1 e2) k = evalCPSdefun e1 (ContE1 k e2)

Hey it looks like almost the same thing! The difference is in how we interpret the data structure. In the previous case, applyContReduce just used it for navigation. In this case, applyContEval calls back into evalCPSdefun to keep the evaluation rolling.

If, like myself, you liked this because you feel there is important and interesting structure underlying operational semantics that is hidden by its many superficial forms, then you’ll probably like this additional reading:

• Modularity and implementation of mathematical operational semantics. M Jaskelioff, N Ghani, G Hutton. MSFP 2008.
• Fold and unfold for program semantics. G Hutton. ICFP 1998.

And I leave you with my hidden instances of arbitrary…

> instance Arbitrary a => Arbitrary (BinaryTree a) where
>   arbitrary = oneof [liftM Leaf arbitrary, liftM2 Node arbitrary arbitrary]

> instance (Arbitrary a, Arbitrary b) => Arbitrary (MyPair a b) where
>   arbitrary = liftM2 myPair arbitrary arbitrary

• Automatic Verification of Concurrent Systems Using Temporal Logic Specifications by EM Clarke, EM Emerson, AP Sistla.

The “efficient algorithm” presented in the paper is, upon reflection, merely a memoized traversal of the state machine, so I combined it with a modified version of

• Monadic Memoization Mixins by D Brown, WR Cook

which actually eliminated an auxilliary function from the algorithm, yielding an efficiently-executable 20-line Haskell specification of the meaning of CTL (which is probably clearer than my English prose explanation, and certainly more fun to play with).

This post is, as usual, literate Haskell. Load it up in GHCi, Haskell-mode, or compile it with ghc --make and try it out. Maybe you can convince my state space exploration not to terminate

> {-# LANGUAGE TypeOperators,ScopedTypeVariables,PatternSignatures #-}

> import qualified Data.Map as M
> import qualified Data.Set as S
> import Data.List
> import Control.Monad 
> import Control.Monad.State hiding (fix)

Memoization Mixins

Here is the easy example from the Brown-Cook paper, before getting on to model checking.

To enable functional mixins, we write our functions using open recursion. Instead of a function of type a -> b we write one of type Gen (a -> b) and then later “tie the knot” with fix (reproduced here for reference)

> type Gen a = (a -> a)

> fix :: Gen a -> a
> fix f = f (fix f)

The classic example they start with is calculating the nth fibonacci number, but don’t stop reading just because this example is simple! It is just to illustrate the technique.

> fib :: Int -> Int
> fib 0     = 0
> fib 1     = 1
> fib (n+2) = fib n + fib (n+1)

By the time you get to fib 30 it takes a dozen or seconds to return on my poor old computer. Rewrittin in open recursion as

> gFib :: Gen (Int -> Int)
> gFib recurse 0     = 0
> gFib recurse 1     = 1
> gFib recurse (n+2) = recurse n + recurse (n+1)

> fib' = fix gFib

This fib' has essentially the same performance, up to constant factors: slow.

To enable us to store the memoization table in something like a State, we parameterize over an underlying monad. A beautiful technique in its own right, if you ask me. I agree with the authors that open recursion and monadification are important and powerful enough to deserve language support; you probably will think gmFib below looks a bit crufty.

> gmFib :: Monad m => Gen (Int -> m Int)
> gmFib recurse 0     = return 0
> gmFib recurse 1     = return 1
> gmFib recurse (n+2) = do a <- recurse n
>                          b <- recurse (n+1)
>                          return (a + b)

And now we can mix in memoize

> type Memoized a b = State (M.Map a b)

> memoize :: Ord a => Gen (a -> Memoized a b b)
> memoize self x = do memo <- check x
>                     case memo of
>                       Just y  -> return y
>                       Nothing -> do y <- self x
>                                     store x y
>                                     return y

> check :: Ord a => a -> Memoized a b (Maybe b)
> check x = do memotable <- get
>              return (M.lookup x memotable)

> store :: Ord a => a -> b -> Memoized a b ()
> store x y = do memotable <- get
>                put (M.insert x y memotable)

Here’s the final fib, which returns instantly up to at least 10000.

> fib'' n = evalState (fix (gmFib . memoize) n) M.empty

Computation Tree Logic (CTL)

The language for which Clarke et al give a graph-based algorithm is called CTL; nowadays people are interested in a bunch of variants like CTL* and ACTL. I’m not a model-checking researcher so I don’t really know the subtleties of their differences. CTL is a logic for specifying certain restricted kinds of predicates over the possible traces of a state machine, for today a finite state machine.

Let’s just look at the Haskell definition:

> data CTL p = TT | FF
>            | Atomic p
>            | Not (CTL p)
>            | And (CTL p) (CTL p)
>            | AllSucc  (CTL p)
>            | ExSucc   (CTL p)
>            | AllUntil (CTL p) (CTL p)
>            | ExUntil  (CTL p) (CTL p)
>              deriving (Eq,Ord)

Some of these are simply your usual logic

• TT holds of any state
• FF never holds
• Atomic p is some atomic proposition over a state, like inequality over program variables, etc.
• Not and And have their expected meanings

The successor constructions let you talk about “the next” state:

• AllSucc f (respectively ExSucc) holds of a state s when the formula f holds for all (respectively some) successor states.

The interesting ones though, are “Always Until” and “Exists Until”:

• AllUntil f1 f2 holds of a state s when for all prefixes of any trace starting at s you eventually reach a state satisfying f2, and everywhere along the way f1 holds.
• ExUntil is the existential version of that.

We can then define some more predicates like “forever in the future” and “eventually”

> allFuture f = AllUntil TT f
> existsFuture f = ExUntil TT f

> allGlobal f = Not(existsFuture(Not f))
> existsGlobal f = Not(allFuture(Not f))

Now, to apply a formula to a state machine, first I need the state machine. I’ll just represent it by its successor function.

> type Succ st = st -> [st]

And we need some interpretation of atomic formulas as predicates over states

> type Interp p st = p -> st -> Bool

And since I’m using a monadified form of computation, I will lift a bunch of operations into monads to make everything readable.

> andThen,orElse :: Monad m => m Bool -> m Bool -> m Bool
> andThen = liftM2 (&&) 
> orElse  =  liftM2 (||) 

> notM :: Monad m => m Bool -> m Bool
> notM = liftM not

> anyM,allM :: Monad m => (s -> m Bool) -> [s] -> m Bool
> allM f = liftM and . mapM f
> anyM f = liftM or  . mapM f

The Model-Checking Algorithm

In the Clarke et al paper, the algorithm is expressed by induction on the formula f you want to check: First, label your state-space graph with all the atomic formula that hold at each state. Then, label with each the compound formula of height two that holds. Etc, etc, you are guaranteed that the graph is already labeled with each subformula by the time it becomes necessary.

Like dynamic programming, this is simply a complicated way of expressing memoization. In fact, they even use a depth-first search helper function that is completely eliminated by expressing it as a memoized function. This code is considerably shorter and, I think, clearer than the pseudocode in the paper, modulo the overhead of “mixing in” and “tying the knot”.

Today we have fancy algorithms involving BDDs and abstraction, so I’m not claiming anything useful except pedagogically. I do wonder, though, if this code gains something through laziness. It certainly traverses the state space fewer times (but I’m sure an implementation of their algorithm would do similar optimizations).

> checkCTL :: forall p st . (Ord p, Ord st) => 
>                           Interp p st -> Succ st -> st -> CTL p -> Bool
> checkCTL interp succ init f = 
>    evalState (fix (gCheckCTL . cyclicMemoize2 False) f init) M.empty
>  where 
>    gCheckCTL :: Monad m => Gen (CTL p -> st -> m Bool)
>    gCheckCTL recurse f s = checkFormula f
>      where checkFormula TT           = return True
>            checkFormula FF           = return False
>            checkFormula (Atomic p)   = return (interp p s)
>            checkFormula (Not f1)     = notM (recurse f1 s)
>            checkFormula (And f1 f2)  = recurse f1 s `andThen` recurse f2 s
>            checkFormula (AllSucc f1) = allM (recurse f1) (succ s)
>            checkFormula (ExSucc f1)  = anyM (recurse f1) (succ s)

>            checkFormula (AllUntil f1 f2) = recurse f2 s `orElse` 
>                            (recurse f1 s `andThen` allM (recurse f) (succ s))

>            checkFormula (ExUntil f1 f2)  = recurse f2 s `orElse` 
>                            (recurse f1 s `andThen` anyM (recurse f) (succ s))

You may also notice that I cheated a little, perhaps. I have used cyclicMemoize2 instead of memoize:

> cyclicMemoize2 :: (Ord a, Ord b) => c -> Gen (a -> b -> Memoized (a,b) c c)
> cyclicMemoize2 backEdge self x y = do memo <- check (x,y)
>                                       case memo of
>                                          Just z  -> return z
>                                          Nothing -> do store (x,y) backEdge
>                                                        z <- self x y
>                                                        store (x,y) z
>                                                        return z

One reason is simply that I need a curry/uncurry wrapper for my two argument monadified function. The deeper thing is that cyclicMemoize2 False inserts a fake memoization entry while a computation is progressing. If there is ever a “back edge” in the search, it will return this dummy entry. For CTL, the auxilliary depth-first search used in the paper for AllUntil returns False in these cases, so I seed the memo table accordingly. This is because by the time you have recursed around a cycle, that means that the f2 you are searching for did not occur on the cycle, so it never will.

To play with it, I’ve only made a couple of examples involving stop lights (of occasionally curious colors). I’d love more, and you’ll undoubtedly find bugs if you actually run something significant.

> ex1interp p s = (p == s)

> ex1succ "Red"    = ["Green"]
> ex1succ "Green"  = ["Yellow"]
> ex1succ "Yellow" = ["Red"]

> ex2succ "Red"    = ["Green"]
> ex2succ "Green"  = ["Yellow", "Orange"]
> ex2succ "Orange" = ["Red"]
> ex2succ "Yellow" = ["Red"]

But it looks kind of OK,

*Main> let ch2 = checkCTL ex1interp ex2succ
*Main> let ch1 = checkCTL ex1interp ex1succ
*Main> ch1 "Red" (existsFuture (Atomic "Red"))
True
*Main> ch1 "Red" (existsFuture (Atomic "Blue"))
False
*Main> ch2 "Green" (ExUntil TT (Atomic "Red"))
True
*Main> ch2 "Green" (ExUntil (Atomic "Green") (Atomic "Orange"))
True
*Main> ch1 "Green" (Not (AllUntil (Not (Atomic "Yellow")) (Atomic "Red")))
True
*Main> ch1 "Green" (Not (ExUntil (Not (Atomic "Yellow")) (Atomic "Red")))
True
*Main> ch2 "Green" (Not (ExUntil (Not (Atomic "Yellow")) (Atomic "Red")))
False

Quite fun!

You might wonder what I mean by “recreational mathematics” since clearly all math is fun . Well, I’m talking about math that is intended to be fun before being instructive. It usually mixes in a bit of history and description of famous math personalities for added interest, and has much much MUCH more motivation than your average math textbook; I find that this helps me immensely in remembering the math. However, I am not talking about books only about the people, places, and times of mathematics. All the books in this review have, to some degree, real and rigorous mathematical content. But none of them are a “pure” exposition of consequences from axioms. It’ll be plenty clear if you take the time to find and read some of these wonderful books.

Journey Through Genius by William Dunham

If you read just one book, read Journey Through Genius. It hits many mathematicians and topics, and is a great overview.

Each chapter is centered on one “great” theorem, but is arranged beautifully such that the theorem is merely the peak of the story arc. For example, the first chapter on Hippocrates’ quadrature of the lune gives 17 pages to classical constructive geometry, discussing the disconnect between “number” and “length” and showing the quadrature of various polygons. The proof of the great theorem is then about one full page. After the main result, an epilogue eases you out with a discussion of some following results, in this example about 7 pages, finishing with the impossibility of squaring the circle with straightedge and compass.

Perhaps my favorite thing about the book is that it really feels like it is about math, and the artistry with which great theorems are proved. People, places, and the passage of time appropriately spice up the story; reading Newton or Euler’s work doesn’t seem like a disjoint concern from that of Archimedes, but rather like a change of camera angle in a (highly metaphorical) movie.

Journey through Genius ends with Cantor’s theorem, so don’t expect to gain new appreciation for modern abstract nonsense – I suspect it will be a long time before a recreational math book tries to tackle what they teach in grad school today.

Yearning for the Impossible by John Stillwell

This book is definitely my second favorite next to Journey Through Genius. Most books are themed by mathematical content or a famous mathematician, or deliver a historical overview, but this one manages to truly have an emotional theme just as implied by the title. I literally felt the suspense of wondering what would be discovered next as the mathematicians in the book are practically forced to discover irrational numbers, complex numbers, projective geometry, infinitesimals, hyperbolic space, quaternions, prime ideals, and uncountability.

The treatment of prime ideals especially struck me, since I’ve never seen an ounce of motivation elsewhere, and certainly nothing as down-to-earth as providing unique factorization for Gaussian integers. I’m sure more sophisticated uses abound, since they bother teaching it in the first quarter of Algebra, but since I study programming languages my grad math experience is somewhat ad hoc… I learn math for kicks, and count on motivation and formalism to be presented together, which is very uncouth in modern math culture! Anyhow, I sure wish I had read this book years ago.

Four Colors Suffice by Robin Wilson

This one I just got for Christmas, and makes it to number three in my list because it treats a different sort of problem that has a very different sort of proof. The subject, of course, is the Four Color Theorem. In order to create an entire book for the history of this theorem, Wilson adopts the interesting approach of describing many false starts and negative results – of course, they really do form a major part of the story, and the eventual correct proof relies on the techniques of an early incorrect proof. Also nice are the numerous primary source documents, such as the first document where DeMorgan communicates the problem to Hamilton, and where Story says (translating into modern Santa Cruz English) “Dude, this problem is gnarly!” I hadn’t realized that this problem moved through such prestigious hands as DeMorgan, Hamilton, Peirce, Euler, Cayley, and Kempe (apologies to the other names who will simply have to wait 100 years to achieve proper prestige – I visited the Boston museum of science recently and they have this wall with a chronology of math where pre-1900 there are perhaps 1-4 famous people alive at a time and post-1900 it explodes to fill the entire wall vertically, so I can’t be expected to remember them all )

Anyhow, as the book progresses, results build up – but not results that aid the proof, rather they are results that prove how large any counterexample must be, and how many special cases must be considered. And then there is the moment where over a thousand cases are checked by computer algorithm, with the expected reactionary backlash against such a proof. Amusingly, the proof starts with a ton of tedious work by hand yet it is the computer part that people didn’t trust! Subsequent work automates the first part of the proof so now a computer can replay the proof at home in a short while. Especially in the context of mechanizing the metatheory for programming languages, this is an interesting issue.

Euler: Master of us All by William Dunham

This book has a very similar feel to Journey Through Genius, but is focused entirely on Euler. The same good intro/climax/epilogue format is followed for each chapter, and the same wonderful style that is distinctly Dunham. Added to that, Euler’s math is truly artistic; I feel like yelling “BAM!” at the end of each proof. I absolutely loved this one too, but don’t read it right after Journey Through Genius or the tone will be getting old.

There is much discussion of rigor issues with Euler’s approach, which are certainly valid in the absolute sense that he was working with terms and notations that weren’t clearly defined. But in my opinion it isn’t reasonable to retroactively apply rigorous reinventions of terminology.

Imagining Numbers by Barry Mazur

This one was a gift that got me started on this train of books. It is OK, but in retrospect not as good as the others, and complex numbers make a prominent appearance in many of these books, particularly Yearning for the Impossible. On the upside, it is short and nice, and has poetic and philosophical interludes, making it a unique experience.

Fearless Symmetry by Avner Ash and Robert Gross

I read this because it had a catchy title . I recall it was pretty good, and had content and motivation I hadn’t seen before, since I haven’t yet had time to reach Galois theory in my sampling of math courses. It has been a while since I read it, and it has been returned to the library, so I can’t say anything terribly specific about its content or presentation, but I certainly recommend reading or re-reading it to anyone engaged in group theory or Galois theory in particular. The more of it you already know, the quicker you will blaze through it anyhow. Apropos a comment I made in the review of Journey Through Genius, this book is probably the closest to actually touching abstract and somewhat difficult modern topics.

The Pea and the Sun by Leonard Wapner

This one is all about the Banach-Tarski “paradox” so it has a natural advantage because of the curiosity of the subject matter. Unfortunately, it doesn’t really take advantage of it. Before getting to the main theorem, it develops many analogous smaller versions of the paradox to get the reader situated, and I found it rather dragging. Simpler versions of the paradox do make great party tricks, if you know them well enough to deliver the proof quickly and with flare, and if you go to the kind of parties that I do…

Unknown Quantity by John Derbyshire

This one is really popular and well-reviewed, so I’m almost afraid to say it was my least favorite of all I’ve read. It was just too heavy on the history, and not exciting enough to keep my interest. The book is also quite long, while I like knowledge in bite sized chunks… I’ll stick to mathematical pamphlets!