that is,

Now, it’s possible (probable, in fact) that this can be proved by purely algebraic means. If you come up with such a proof I would love to see it! But I must confess that I spent several hours banging my head against it (algebraically speaking) without making any progress. Eventually I turned to the idea of a combinatorial proof.

What do I mean by that? Combinatorics is the subfield of mathematics concerned with counting. The essence of a combinatorial proof is to show that two different expressions are just two different ways of counting the same set of objects—and must therefore be equal. I’ve described some combinatorial proofs before, in counting the number of ways to distribute cookies.

As another simple example, consider the binomial coefficient identity

It’s certainly possible to prove this algebraically, by expanding out the binomial coefficients (using ), but we can give a more elegant proof, based on the fact that is the number of ways to choose a subset of things out of a set of things. For example, here are the ways to choose three things out a set of five:

Consider the first element of the size- set. Every subset of size either includes this first element, or it doesn’t. The number of size- subsets which do not include the first element is , since that’s the number of ways to choose things from the remaining elements. The number of size- subsets which do include the first element is , because they correspond to choosing of the remaining things. Therefore .

Here’s an illustration of how this works in the particular case when and :

Notice how the ten subsets from above have been split into two groups: the first group, on the left, are those that don’t include the first element; you can see that each of them corresponds to one of the size- subsets of the remaining four elements. The second group, on the right, are those that do include the first element; each corresponds to one of the size- subsets of the remaining four elements.

So that’s the idea of a combinatorial proof. And we want to do something similar for the identity we are trying to prove—although, of course, it’s going to be a bit more difficult!

You might have fun trying to think about what a combinatorial proof of our target equation might look like; although if you don’t have much experience with combinatorics you may have trouble coming up with what sorts of things the two sides of the equation might be counting! That’s what I’ll talk about in my next post.

For example:

Several commenters figured this out as well. Does this always happen? If so, can we prove it?

Let’s start by thinking about what happens when we do the successive-differencing procedure. If we start with the list , then we get . (I want to keep the letters in order, which is why I wrote instead of . Instead of subtracting the first value from the second, we can think of it as adding the negation of the first value to the second.) If we start with , we get

.

(The negation of is ; adding this to yields .) From we get

Do you see any patterns yet? Let’s do one more. From the above calculation we can already see that doing four iterations on will result in (do you see why?). Doing one final iteration gives us

.

Hmm. Let’s make a table.

	Result
1
2
3
4
5

I included one more row (which you can verify if you like). Now do you see a pattern? The coefficients seem to be taken from Pascal’s triangle, but with alternating signs!

In fact, it’s actually not too hard to see why this happens. At each step we take two offset copies of the previous row (by "offset" I mean that the letters are shifted by one, like and ) and add the negation of the first to the second. Since the signs are alternating, we really end up adding absolute values of the coefficients. Probably the best way to really see this is through an example:

Notice how we flip all the signs in the first row, so that they match the signs in the second row. But this is exactly how Pascal’s triangle is generated—each row is the sum of the previous row with itself, offset by one.

Now, in the real problem, we don’t start with , but with the th powers of consecutive integers. Let’s call the first integer , so the sequence of consecutive integers is . Given this, we can now write down an expression for what we end up with after doing the iterated difference procedure:

Let’s break this down a bit. We know that we get a sum of terms; that’s the part (you can read more about sigma notation here). We’ll use to index the terms. We also know that the terms alternate sign, so we need to include raised to some power involving ; the last term is always positive, so we use , which is equal to when . The binomial coefficient gives us the th entry on the th row of Pascal’s triangle. Finally, of course, is the th power of one of the integers we started with.

The claim, therefore, is that

And I will prove it to you, with pretty pictures, as promised!

As just announced by Bill Gasarch, this is a grid which has been four-colored (that is, each point in the grid has been assigned one of four colors) in such a way that there are no monochromatic rectangles, that is, no four grid points forming the corners of an axis-aligned rectangle are all of the same color. For example, if we change the top-left grid point to red, we can see several monochromatic rectangles pop up:

Or here’s another version where I randomly picked a grid point in the middle, changed its color, and sure enough, more monochromatic rectangles result:

As you can try verifying for yourself (and as I also verified using a computer program), there are no such monochromatic rectangles in the four-coloring at the top of this post! (If you want to play with the four-coloring yourself, here it is in a simple data format.)

For several years no one knew if this was possible, and Bill had offered a prize of $289 (that’s , of course) to anyone who could find such a four-coloring. The prize will be collected by Bernd Steinbach and Christian Posthoff—you can find more details in Bill’s post. No one yet knows exactly how they found their four-coloring, but apparently they will be presenting a paper about it in May. I’ll try to write more about it then (if I understand it at all)!

If you’re interested in reading more about the history and math behind this problem (and to get some intuition for why it is difficult), take a look at these posts by Brian Hayes on his blog, bit-player: The 17×17 challenge and 17 x 17: A nonprogress report. I also remember seeing Here’s a fun interactive applet where you can play around with the problem, created by Martin Schweitzer.

Nine Algorithms that Changed the Future: the Ingenious Ideas that Drive Today’s Computers, by John MacCormick. Princeton University Press, 2012.

I’m often wary of books written for general audiences on technical topics. It’s quite difficult to write in a way that is both accessible to a wide audience and technically accurate. Many such books end up sacrificing accuracy in the name of accessibility, trying to convey just the “intuition” or “general sense” of some topic, but often end up giving people the wrong idea instead.

I was quite happy to find, therefore, that John MacCormick nails it: “9 Algorithms that Changed the Future” is technically right on the money, but manages to explain things in ways that are both understandable and fun. Want to understand how Google ranks search results? Or how Amazon manages to never lose or mess up your order information, even though they get hundreds of thousands of orders each day and (as we all know) networks and hard drives are unreliable? Ever wonder how you can order something over the internet without your credit card number being stolen? Or how “zip” is able to make your files smaller, seemingly by magic? Even if you have never wondered about these things, perhaps I have made you wonder about them just now. And that’s exactly the point of this book: there are quite a few ingenious algorithmic ideas that most of us rely on every day that we rarely—or never—even stop to wonder about.

For example, I actually learned something new: I knew about public-key cryptography but had never really known much about Diffie-Hellman key exchange, which is what allows your web browser to talk to, say, Amazon’s servers securely even though they have never communicated before. It’s like having a secret conversation in code with a pen-pal whom you’ve never met, even though lots of people are reading your mail. How can you ever agree on a secret code in the first place without the people reading your mail finding out (and hence being able to read all your subsequent coded messages)? Sounds impossible, doesn’t it? But it turns out that it is possible, with some clever ideas, which MacCormick skillfully explains using a fun metaphor about mixing colors of paint.

Each chapter starts out very simply, gradually building up more complex examples until you reach a full understanding of the algorithm being explained. Along the way MacCormick introduces the “tricks”—the clever, central ideas—that make each algorithm work. The writing is excellent: clear, precise, and fun. I highly recommend this book to anyone curious about the ingenious mathematical and algorithmic ideas underlying some of today’s most ubiquitous technology.

In a previous post, we found a decadic number

with the curious property that it is its own square, even though it is obviously not zero or one. We then derived a more efficient algorithm for generating the digits of . Here’s some Haskell code (explained in the previous post) which implements the more efficient algorithm, which I include here just so that this post will be a valid literate Haskell file in its entirety.

> {-# LANGUAGE TypeSynonymInstances
>            , FlexibleInstances
>   #-}
>
> module Decadic2 where
>
> import Control.Monad.State
>
> -- State for incrementally constructing u_n.
> -- Invariant: curT = 10^n; un^2 = pn*curT + un
> data UState = UState { pn     :: Integer
>                      , un     :: Integer
>                      , curT   :: Integer
>                      }
>   deriving Show
>
> -- u_1 = 5;  5^2 = 25 = 2*10 + 5
> initUState = UState 2 5 10
>
> uStep :: State UState Int
> uStep = do
>   u <- gets un
>   p <- gets pn
>   t <- gets curT
>
>   let d   = p `mod` 10      -- next digit
>       u'  = d * t + u       -- prepend the next digit to u
>       p'  = (p + 2*d*u + d*d*t) `div` 10   -- see above proof
>
>   put (UState p' u' (10*t)) -- record the new values
>
>   return $ fromInteger d    -- return the new digit
>
> type Decadic = [Int]
>
> u :: Decadic
> u = 5 : evalState (sequence $ repeat uStep) initUState

To round things out, I’d like to show off some of the cool things we can do with this. First, as we know, it’s possible to do arithmetic with decadic numbers. So let’s implement it!

Addition of decadic numbers is done just like addition of the usual decimal numbers: we add corresponding places (i.e., line up the numbers one under the other and then add in columns).

> plus :: Decadic -> Decadic -> Decadic

First, we have special cases for zero, represented by the empty list of digits: in those cases we just return the other number unchanged.

> plus [] n2 = n2
> plus n1 [] = n1

Next, to add a decadic number whose first digit is x to a decadic number whose first digit is y, we just add x and y and then continue adding recursively.

> plus (x:xs) (y:ys) = (x+y) : plus xs ys

Of course, we’re not done: this doesn’t do any carrying. Instead of modifying our plus function to do carrying, we just write a function normalize which makes sure every place in a decadic number is between and ; it will come in handy for more than just addition.

> normalize :: Decadic -> Decadic

The normalize function simply calls a recursive helper function normalize' which keeps track of the current "carry". The starting carry, of course, is zero.

> normalize = normalize' 0

To normalize zero (the empty list) when the current carry is zero, just return the empty list.

>   where normalize' 0 [] = []

With a nonzero carry and the empty list, we simply extend the list with a special zero digit and continue normalizing.

>         normalize' carry [] = normalize' carry [0]

In the general case, we add the current carry to the next digit x, and compute the quotient and remainder when dividing this sum by ten. The remainder is the next digit d, and the quotient is the new carry which gets passed along recursively.

>         normalize' carry (x:xs) = d : normalize' carry' xs
>           where (carry', d) = (carry + x) `divMod` 10

And now for multiplication, which is based on the observation that zero times anything is zero, and in the general case

.

> mul :: Decadic -> Decadic -> Decadic
> mul [] _ = []
> mul _ [] = []
> mul (x:xs) (y:ys) = x*y : (map (x*) ys + (xs * (y:ys)))

Finally, we declare Decadic to be an instance of the Num class, which allows us to use decadic numbers in the same ways that we can use other numeric types:

> instance Num Decadic where

To add or multiply decadic numbers, use the plus and mul functions and then normalize.

>   n1 + n2 = normalize (plus n1 n2)
>   n1 * n2 = normalize (mul n1 n2)

To negate a decadic number, subtract the last digit from 10 and the rest of the digits from 9.

>   negate [] = []
>   negate (x:xs) = normalize $ (10-x) : negate' xs
>     where negate' []     = repeat 9
>           negate' (x:xs) = (9-x) : negate' xs

Finally, to convert an integer into a decadic number, put the integer into a list of one element and normalize.

>   fromInteger = normalize . (:[]) . fromInteger

So, let’s try it! We’ll want a way to display decadic numbers:

> showDecadic :: Decadic -> IO ()
> showDecadic d = putStrLn . dots $ digits
>   where d'   = take 31 d
>         dots | length d' <= 30 = id
>              | otherwise       = ("..." ++)
>         digits =  concat . reverse . map show . take 30 $ d'

Normal decimal integers can also be used as decadic numbers:

*Decadic2> showDecadic 7
7

Here’s :

*Decadic2> showDecadic u
...106619977392256259918212890625

And here’s ; it had better be the same as !

*Decadic2> showDecadic (u^2)
...106619977392256259918212890625

Well, looks like it’s the same for the first 30 digits at least! We can also compute . Remember, if then , so should be another self-square number. Remember how we thought there might be a self-square number ending in ? Well, this is it!

*Decadic2> showDecadic (1-u)
...893380022607743740081787109376
*Decadic2> showDecadic ((1-u)^2)
...893380022607743740081787109376

Finally, we can check that :

*Decadic2> showDecadic (u * (1-u))
...000000000000000000000000000000

If you recall, this is in some sense the fundamental reason why the decadic numbers act so funny, because it has zero divisors: pairs of numbers (like and ), neither of which is zero, whose product is nonetheless zero.

Now, if you remember, from even further back, what got us into this whole decadic mess in the first place:

In that first post, I said

I managed to extend this pattern for a few more digits before I got bored. Does it continue forever or does it eventually stop? Is there any deeper mathematical explanation lurking behind this supposed “curiosity”? What’s so special about ? Do patterns like this exist for other functions?

Well, by this point I hope it’s clear that there is indeed a deeper mathematical explanation lurking! The equation

admits the solutions and , but does it admit any other decadic solutions? Notice that given , which has and as solutions, then (and ) are also solutions:

.

So in this case we get

as a solution (the other solution is not a decadic integer).

To implement it, we need a way to halve decadic numbers (I’ll let you work out what’s going on here):

> halve :: Decadic -> Decadic
> halve [] = []
> halve t@(s:_)
>   | odd s     = error "foo"
>   | otherwise = halve' t
>   where
>     halve' [] = []
>     halve' [x] = [x `div` 2]
>     halve' (x:x':xs) = (x `div` 2 + adj) : halve' (x':xs)
>       where adj | odd x'    = 5
>                 | otherwise = 0

And now we can define

> q = halve (3*u - 1)

*Decadic2> showDecadic q
...159929966088384389877319335937
*Decadic2> showDecadic (2*q^2 - 1)
...159929966088384389877319335937

Woohoo! This clearly shows that the pattern does, in fact, continue forever. It also shows us that is not particularly special: any quadratic function that factors as , at the very least, will lead to a pattern like this, and probably lots of other equations do too.

If you’re interested in reading more, here’s where I got some of my information. For example, you can read about how there is another number , defined by starting with and iteratively raising to the fifth power (just as we defined by starting with and successively squaring), such that . It even seems that the author of that page, Gérard Michon, has recently added a discussion of this very problem, prompted by my blog posts! Isn’t the internet great?

For example, suppose we choose , and start with the five consecutive integers . We raise them all to the fourth power, giving us

Now we take pairwise differences: , then , and so on, and we get the new list

Repeating the difference procedure gives

OK, so we get . So what?

Well, if you try enough examples, you may notice a surprising pattern. I’ll let you play with it for a while. Over the course of a few future posts I’ll explain the pattern and prove that it always holds—but the proof will be a really cool combinatorial one, with pretty pictures!

In my previous post, we found a decadic number

with the curious property that it is its own square.

We also discovered an algorithm for computing : starting with , we square each and take the remainder (that is, we keep only the last digits) to give us . Then is defined as the limit of the as .

(As an aside, notice why we are allowed to define as a limit: because of the funny decadic metric, the distance between successive is actually getting smaller by a factor of each time; they are converging on something, and that something is .)

So,

We can pretty easily turn this into a computer program to compute to as many digits as we like. As usual, I’m using my favorite programming language, Haskell. It doesn’t matter if you don’t know Haskell, I’ll try to explain things well enough that you can still follow along anyway.

First we just need to import something we’ll need later.

> module Decadic where
>
> import Control.Monad.State

Now, we define u1 to be 5, and the function nextU takes and as input and produces .

> u1 :: Integer
> u1 = 5
>
> nextU :: Integer -> Integer -> Integer
> nextU n un = (un^2) `mod` (10^(n+1))

Now we can define the (infinite!) list of , which we’ll call us. generateUs takes the current values of and and generates a list with as its first element, and the remainder of the list computed by a recursive call to generateUs (with and as its inputs). us just gets things started by calling generateUs with and .

> us :: [Integer]
> us = generateUs 1 u1
>   where generateUs n un = un : generateUs (n+1) (nextU n un)

Let’s see if it works by asking for the first ten elements of the list us:

*Decadic> take 10 us
[5,25,625,625,90625,890625,2890625,12890625,212890625,8212890625]

Seems good!

However, all is not roses. Let’s think about what our program had to do in order to calculate . Given , it first squared it to get … but wait a minute! ends in —of course it does, since that’s the defining property of the . But that means that half (more or less) of the work needed to square was completely wasted! There’s no point in computing the last half of , since we already know it is going to be . We only care about the rest of it.

Realizing that our program is doing too much work is one thing; turning this intuition into actual improvements is quite another! Initially it was far from obvious to me how to avoid the repeated work. But I finally figured it out.

The key is to remember at each step not just , but . However, since we know that ends with , we can remember along with the prefix (call it ) of that comes before the ending . For example, for we’ll remember and (since ). That is, we will always insist that

.

The key question now is: given and , how do we compute and ? Well, computing is easy: it’s just with an extra digit tacked on, namely, the final digit of . In particular, we can define to be the last digit of ; then .

It’s computing which is the tricky part. Since we want to have , the idea is to expand out , manipulate it into the desired form, and see what we get for :

Now, note that we can break into two parts: the last digit (which we’re calling ) and the rest. That is,

where denotes rounding down to the nearest integer, so means to divide by 10 and throw away the remainder—that is, without its final digit. Continuing,

and there we have it! We have expressed in the form . In particular,

Notice that is actually guaranteed to be an integer, since is divisible by 5—this is the same phenomenon we ran across in proving that our simple algorithm for computing works correctly. So we can factor out a division by ten (division is generally slow so we’d rather only do it once):

And now for some code! As one final optimization, instead of keeping track of , we keep track of , so we don’t have to keep recomputing every iteration.

First, the data structure we use to keep track of the current values of , , and :

> -- State for incrementally constructing u_n.
> -- Invariant: curT = 10^n; un^2 = pn*curT + un
> data UState = UState { pn     :: Integer
>                      , un     :: Integer
>                      , curT   :: Integer
>                      }
>   deriving Show

The initial state for has , , and .

> -- u_1 = 5;  5^2 = 25 = 2*10 + 5
> initUState = UState 2 5 10

The uStep function is the heart of the algorithm: it takes the current values of , , and and updates them to , , and . It also returns as its result, which we can use to build up digit-by-digit.

> uStep :: State UState Int
> uStep = do
>   u <- gets un
>   p <- gets pn
>   t <- gets curT
>
>   let d   = p `mod` 10      -- next digit
>       u'  = d * t + u       -- prepend the next digit to u
>       p'  = (p + 2*d*u + d*d*t) `div` 10   -- see above proof
>
>   put (UState p' u' (10*t)) -- record the new values
>
>   return $ fromInteger d    -- return the new digit

So, did we gain anything? As a concrete comparison, let’s see how long it takes to compute . Using our first, simple code, it takes 7.2 seconds:

*Decadic> :set +s
*Decadic> length . show $ us !! 10000
10001
(7.23 secs, 208746872 bytes)

(I just had it print the number of digits of to avoid wasting a ton of space printing out the entire number.) And using our new and hopefully improved code?

*Decadic> length . show . un . flip execState initUState
          $ replicateM_ 10000 uStep
10001
(1.55 secs, 225857080 bytes)

Only 1.5 seconds! Nice!

The other nice thing about uStep is that it spits out one digit of at a time, which we can use to define as an (infinite) list of digits—as if the digits were coming one at a time down a "tube", a -tube, one might say… get it, a … tube… heh… never mind.

> type TenAdic = [Int]
>
> u :: TenAdic
> u = 5 : evalState (sequence $ repeat uStep) initUState

*Decadic> reverse $ take 20 u
[9,2,2,5,6,2,5,9,9,1,8,2,1,2,8,9,0,6,2,5]

Nifty! Next time the real fun begins, as I show off some cool things we can do with our shiny new implementation of .

The Calkin-Wilf Tree

He also wrote generatingfunctionology, a textbook about generating functions, a topic near and dear to my heart (which I hope to write about here someday).

Although he was an emeritus professor at the University of Pennsylvania (where I am currently doing my PhD) I sadly never got a chance to meet him.

Finally, as promised, I can show you the strange number u which is its own square (but which isn’t zero or one!). Up until now all the decadic numbers we’ve considered have been equivalent to familiar rational numbers, but zero and one are the only rational numbers which are their own square; clearly u must be something quite different!

Assuming that such a u could exist—and assuming it’s a decadic integer, that is, has no digits to the right of the decimal point—let’s think for a minute about what u could possibly be. For example, what could its last digit be?

When we multiply two integers, the last digit of the result depends only on the last digits of the integers being multiplied, since all the other digits contribute some power of 10. So we can narrow down the possibilities for the last digit of any self-square decadic integer by seeing which digits have squares that end in the same digit:

0	0
1	1
2	4
3	9
4	16
5	25
6	36
7	49
8	64
9	81

I’ve highlighted the digits with the desired property: of course, and , but also ends in and ends in . We already know we don’t want to consider and . So for now, let’s suppose that ends with .

What about the last two digits of ? Again, the last two digits of depend only on the last two digits of . (If this isn’t obvious to you, you should try a few examples to convince yourself. For example, what is ? What information did you need to compute the last two digits of the answer?) So whatever the last two digits are, their square, when considered on their own as a two-digit number, must be some number that ends in the same two digits. Assuming the last digit is , we can turn this requirement into a modular equation which we can use to solve for the second-to-last digit:

Sure enough, which ends with .

Can we take this further? What about the last three digits?

Check: , which indeed ends with . Continuing in a similar fashion (I’ll let you work out the details on your own), we find that the fourth digit must be , and the fifth digit must be .

Are you seeing a pattern? Let’s make a table of the results so far:

1	5	25
2	25	625
3	625	390625
4	0625	390625
5	90625	8212890625

Why did I put some numbers in bold? Well, hopefully you’ve noticed by now that each number in the left-hand column always seems to be a suffix of the square of the previous number. So perhaps the next digit will be 8? Sure enough, ends in .

Will this always work? Yes, in fact, it will, and here’s why. Let’s let denote the last digits of (so , , and so on). Once we have found , we can set up a modular equation to find the next digit (this is just a generalization of what we did earlier):

Now, is clearly divisible by so that term goes away. But what about ? It seems that we only know it is divisible by , not necessarily by . Ah, but wait! We know that ends with , and hence is divisible by ; combining this with the gives us another factor of ! So this term goes away too, and we are left with

Now, (by definition), so subtracting from both sides leaves a multiple of in the place of (namely, with the rightmost digits set to zero). But we can also get rid of all the digits to the left of the st because we are working mod . Dividing by we find that must be equal to that st digit of .

So here’s the procedure: starting with , define

That is, square the current number of length and take the last digits to get the next number. The above proof shows that

• At every step we will have a number whose square ends with the digits of ;
• this procedure will always work; and
• this procedure gives the unique sequence of with this property when starting with !

So we have

and so on.

So what is ? It is simply the limit of carrying out this procedure to infinity!

We know that any suffix of , when squared, yields something ending with itself. So it makes sense (although it takes a bit of imagination!) that squaring itself yields again.

My name is Becky Raymond, I’m a Domain Brokerage Consultant working on behalf of the owner of traveled.com to sell this premium asset.

While searching online I came across your domain mathlesstraveled.com; since both domains have listings under a related keyword I thought perhaps your company may be interested in acquiring traveled.com? If this domain is of interest to you, please submit an offer in the four figure range and above to qualify as a potential buyer.

Sure thing, Becky! Here is my four-figure offer:

Fig. 1. A graph of the first 1000 hyperbinary numbers.

Fig 2. Hasse diagram for the subsets of a five-element set.

Fig. 3: Proof that .

Fig. 4: Complete set of 15-bracelets.

I hope you will agree that this is a very fine set of figures. I could probably add a couple more figures to my offer if that becomes necessary.

I look forward to being the proud owner of traveled.com, the place to go for all your mathematical travel needs!