We nowadays tend to recognize the dangers of blindly following tradition, yet in virtually all areas of mathematics we continue to adhere to notational lunacy, and pass it on to future generations starting as early as in junior high school.

This lunacy is so deeply ingrained in our minds that we see nothing wrong with the following expression:

Let’s decipher the above. We start with a number x, apply f, square the result, and finally apply sin. Yet how do we recover this order of operations from the symbols above? Starting at x in the middle we move left to f, right to the , and far left to the sin.

Although we read and write left-to-right, and so naturally imagine time evolving in this direction, the notation f(x) (due to Euler) means the opposite: start with x, then apply f. Even worse is when we have an expression like f(g(h(x))). The very first operation is written on the very right, and the final operation is written on the very left, in complete contrast to how we normally think.

Worse still is that we do read some operations left-to-right, like raising to a power, and so we end up mentally zig-zagging across mathematical writing to even decipher mathematical expressions.

But worst of all is the following: when we write a function , A denotes the input domain, and B denotes the output domain: input on the left, output on the right. As we’d expect in a sane world. If we also have a function , this left-to-right notation suggests we should be able to follow the arrows (A to B to C) to compose f and g. Yet, of course, the composite is called gf rather than fg. When reading gf we are meant to mentally reverse the direction of the arrows, so that and , although we never write this way!

This is psychotic behaviour, and we should put a stop to it. I suggest we forget tradition, and instead succumb to notational common sense to write expressions like x.f.g rather than g(f(x)).

This may seem bizarre at first, but at least one group of scientists adopted this notation years ago. In object-oriented programming languages a mental shift is required, where one stops thinking that functions have certain inputs, and instead starts to see that inputs have certain functions. In doing so, the left-to-right notation becomes completely natural, and we would write deck.sort.pop to sort a deck of cards and remove the last one, rather than pop(sort(deck)) as we’d expect in the mathematicians’ ridiculous notation.

I believe that a notational shift would make all of our lives easier in the long run, but of course it will likely never happen. Just as negative charge will always correspond to an excess of electrons, Euler’s notation is an unfortunate convention that is simply known by too many people. As a result, already-difficult subjects like category theory are made even more maddening for silly reasons, and high school students have far more difficulty learning precalculus than they should.

Help us, Barack Obama, we need Change.

(Problem 1.) You are trying to determine a secret integer x between 1 and n inclusive, using only queries of the form “is x = a (mod b)?” for integers a and b of your choosing. How many queries are required to determine x in the worst case?

And more restrictively,

(Problem 2.) Same as above but you are only allowed to make queries where b is prime.

The comments section seems to reveal at least a partial solution, but these are fun problems, so at least give them a shot before reading the solution there (or here.) If you’d like the solution spoiled anyway, read on!

First let’s talk about a problem that has a more intuitive solution. Namely, the same problem of finding an integer between 1 and n, but where we are allowed to ask questions of the form “is x ≤ a?” for our choice of integers a.

Computer scientists in the audience should recognize the solution: first, find out about the midpoint. That is, whether x ≤ n/2. Whatever the answer is, we split the search space in half! That is, we originally knew that x must be one of n values. After the first query, we know that x must be one of n/2 values: either 1 ≤ x ≤ n/2 or n/2 < x ≤ n. Either way, we can simply repeat the process again! After the second query, we know it must be one of n/4 values. And so on. For example, for 1 ≤ x ≤ 8, the following sequence of questions would reveal that the answer is x = 3.

It should be easy to convince yourself of the fact that you can only make these divisions lg(n) (that’s log-base-2*) times before you determine x.

Furthermore, this is the best we can do: any algorithm that finds x using only true/false queries requires at least lg(n) queries in the worst case. Why? Essentially, because this is how many bits there are in the binary expansion of x. Take n = 8 for example. If you could determine any 1 ≤ x ≤ 8 using only two queries in the worst case, then any such x could be written uniquely using only 2 bits, which is impossible.

But let’s go back to Problem 1. Notice that the above argument applies for any algorithm that may only make queries about x whose answers are boolean. So we may immediately say that at least lg(n) queries are required by any algorithm that solves it.

However, is the answer again exactly lg(n)? Our binary search problem had the “nice” property that no matter what the answer to our previous query was, we could always construct another query that cut the search space in half again. Any boolean query may be thought of as a filter that eliminates a certain portion of the search space (which here is simply the set {1, 2, …, n}.) But not all queries may have this nice property. For example, if we were only allowed to ask questions of the form “is x = a?” then we would need to ask n – 1 questions in the worst case—because no matter in what order we guess numbers, our first n – 1 guesses could be wrong.

It turns out that the queries in Problem 1 do indeed have this nice property. The algorithm works like so:

1. Ask whether x = 0 (mod 2). Doing so cuts the search space in half.
2. If the answer above was Yes, then ask whether x = 0 (mod 4). Since the previous answer was Yes, it must be the case that either x = 0 (mod 4) or x = 2 (mod 4), and the answer to this query again cuts the search space in half.
3. If the answer above was No, then ask whether x = 1 (mod 4). From the same reasoning as above, we again cut the search space in half.
4. Repeat the process using mod 8, 16, 32, etc., crafting the appropriate query.

It shouldn’t be too hard to find the correct question to ask in each case. As an example,

This process can always be completed in lg(n) queries, which is the answer to Problem 1.

Note, however, that we always use a modulus of the form , so this solution doesn’t help us solve Problem 2, where the modulus must always be prime! Don’t panic; I will discuss a solution to this problem in my next blog post.

* Here I’m assuming that n is a power of 2 to make the formula simpler, but if it isn’t then the correct answer is simply the ceiling of lg(n). That is, round lg(n) up. In fact, whenever I write lg(n) you can assume this is what I mean.

.

At first glance, it’s not even obvious whether the above converges.

On the other hand, it is easy to see that  does not exist (at least not in in the traditional sense) and is analogous to the alternating sequence { 1, -1, 1, -1, … }. But what of squaring the x? The function alternates between positive and negative as well, so one might be tempted to say that its integral also diverges.

But before jumping to conclusions, let’s take a look at its graph:

As x increases, the areas under the positive and negative parts of the curve become smaller and smaller. The question is, do the areas become small fast enough for the integral to converge? The answer turns out to be yes, but proving so (and evaluating its value) turns out to be less straight-forward than the problem seems.

To prove convergence, we can show that  converges. By substituting the integral becomes , and integrating by parts (ignoring the constant factor of 1/2) yields

It’s easy to see that the left term vanishes at infinity, so we need only worry about the integral in the right term. But this converges as well—in fact, absolutely, because

where the right-hand side converges by the “p-test.”

So we’ve proved that the bugger converges, but what about evaluating it?

This also turns out to be more difficult than it has any right to be. The antiderivative of doesn’t have any nice, closed form. The standard method for evaluating it involves observing that and considering the contour integral of this function around a pizza slice-shaped region in the complex plane which includes a line on the positive x-axis.

(Image stolen from the Wikipedia entry.)

As the radius R of the pizza slice goes to infinity, evaluating the line integral of along γ₁ and taking its imaginary part would give us the value of the integral we want. Unfortunately, this integral is no easier to evaluate directly. However, has no singularities, so by the residue theorem its path integral all the way around the above path must be zero. Furthermore, we can prove that its integral along the crust goes to zero as R tends to infinity.

Therefore, the path integral along the diagonal γ₃ (from the origin outward) must be equal to the integral along γ₁ (also outward from the origin.)

We can parametrize the diagonal by , so the path integral across the diagonal is

Taking only the imaginary part, we arrive at

where the second integral is simply half of the Gaussian integral.

The contribution of complex analysis is to prove the first identity above. My question is, is there a more elementary way of establishing it? It seems as though we shouldn’t need the theory of complex functions to evaluate something like this, but I can’t find any other way.

Show that given any 201 points inside a 10-by-10 square, there is a unit circle containing at least 3 of those points.

It is natural to ask, for what other number of points n does the above hold? And what is the smallest such n?

One way to bound n geometrically follows from noticing the obvious fact that

given k circles covering a square and m points inside that square with any individual circle containing at most two of them, then it must be the case that m ≤ 2k.

which is just a restatement of the fact that

So it is sufficient to produce a covering of the square by 100 unit circles to prove the original statement, i.e. when n = 201.

Two-hundred and one turns out to be a very generous bound, though. It’s quite easy to construct a covering of 60 (maybe 61?) circles, by an arrangement similar to the one below:

Tiling this arrangement of unit circles allows you cover a 10-by-10 square with 60 of them

This allows us to reduce the number of points from 201 in the original puzzle to only 2*60 + 1 = 121.

How much further can we reduce this number by this method? Worded slightly differently, what is the smallest number of unit circles that can cover a 10-by-10 square? This turns out to be a difficult problem, and Erich’s Packing Center has the answer for the opposite question (that is, “what is the largest s-by-s square that n unit circles can cover?”) for small values of n, with s reaching values of only about half of in what we’re interested.

Using Wolfram Alpha, we can plot these values and observe that s appears to increase approximately linearly with n, and perform a linear fit. Solving the resulting equation for s = 10, we might expect that a covering of a 10-by-10 square is possible using only 27 unit circles, which if true would bring the bound proved above down from 121 to only 55.

Finding such coverings allows us to prove that the original statement holds for (say) all n ≥ 121, but would finding the optimal covering give us the smallest n for which it holds? That doesn’t seem obvious, as this method essentially gives us a fixed set of circles we are allowed to use, independent of the points in the square, while the original statement allows for the circle to be a function of the points. So can we prove anything directly from the statement itself?

Again, it doesn’t seem obvious how, but what we can do easily is prove that the original statement fails for n ≤ 49. Simply consider a square lattice of points separated horizontally and vertically by a distance of , so that each point is separated diagonally by at least a distance of 2. If we take ε to be small enough, say ε = 0.1, we can fit a grid of 7*7 = 49 points inside a 10-by-10 square, and it’s easy to convince yourself that no unit circle can cover three of the points in the lattice.

Spacing each point apart horizontally and vertically by √2+ε units ensures that no unit circle will cover three points

So we have an interesting situation: we can prove that the statement fails for all n ≤ C by constructing sets of points, and prove that the statement holds for all n ≥ C by constructing sets of circles, but neither method easily provides an exact answer.

Can we do better?

deck.sort_by{ rand }

…or to pick out certain elements of one…

deck.find_all{ |card| card.suit == Clubs }

…or to seamlessly cache computations.

def average_earnings
  @average_earnings ||= some_lengthy_computation
end

(Above, the ||= operator acts analogously to the familiar += operator. So if the instance variable @average_earnings already has a non-nil value, it is returned without any further computation. If on the other hand it is nil, then some_lengthy_computation is performed, @average_earnings is set to it, and returned.)

In addition, there are also a number of ridiculously short applications written in it, including a web server in 70 lines of code, a message board application in 500 lines, and its slightly more verbose successor.

In addition to these, I present a proof of concept of my own: Mathematica and Maple-like symbolic differentiation in about a hundred lines of code.

The idea is to have a Function class, which is subclassed by actual functions (Cos, Exp, Constant, etc.) as well as by operators (Addition, Multiplication, etc.)

Ruby allows us to overload operators, so we can add, subtract, multiply, and divide functions naturally, and define “f + g” as an instantiation of the Add class (which we will define later!)

Each subclass of Function must implement two methods: (1) diff, which returns another Function object (its derivative), and (2) the indexing method [], so given a Function object f and number x in its domain, we can evaluate f(x) via “f[x]“.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

class Function
  # Skeleton. Returns: another Function
  def diff
  end
 
  # Skeleton. Returns: a number
  def [](index)
  end
 
  # Begin algebraic operations
  def +(a)
    Add.new(self,a)
  end
 
  def *(a)
    a = Constant.new(a) if a.kind_of? Numeric
    Multiply.new(self,a)
  end
 
  def /(a)
    a = Constant.new(a) if a.kind_of? Numeric
    Divide.new(self,a)
  end
 
  def -(a)
    self + a * -1
  end
 
  def -@
    self * -1
  end
  # End algebraic operations
end

All binary operations are initialized the same way and have the same basic structure: they act in some way on two functions specified upon creation of the object.

1
2
3
4
5
6

class BinaryOperation < Function
  def initialize(f, g)
    @f = f
    @g = g
  end
end

Multiply subclasses it as follows:

1
2
3
4
5
6
7
8
9

class Multiply < BinaryOperation
  def diff
    @f * @g.diff + @f.diff + @g
  end
 
  def [](x)
    @f[x] * @g[x] 
  end
end

We can similarly define Add and Divide. For any operation, we simply need to know how to differentiate the operation, and how to evaluate it.

We can also define some actual functions. For example,

1
2
3
4
5
6
7
8
9

class Sin < Function
  def diff
    Cos.new
  end
 
  def [](x)
    Math.sin(x)
  end
end

1
2
3
4
5
6
7
8
9

class Cos < Function
  def diff
    -Sin.new
  end
 
  def [](x)
    Math.cos(x)
  end
end

1
2
3
4
5
6
7
8
9

class Exp < Function
  def diff
    self
  end
 
  def [](x)
    Math.exp(x)
  end
end

Once we have all of our operations and functions defined, we can start computing and plotting functions and their derivatives,

1
2
3
4
5
6
7
8
9
10
11
12

f = Cos.new / Exp.new
g = f.diff
 
(0..10).each do |a|
  x = a.to_f/10
  puts "ft#{x}t#{f[x]}"
end
 
(0..10).each do |a|
  x = a.to_f/10
  puts "f't#{x}t#{g[x]}"
end

With a little additional code, we could also print out functions symbolically.

Not bad for less than a couple hundred lines of code.

The number of gifts one receives at the end of the Twelve Days Of Christmas is ironically 364—a gift for each day of the year except Christmas itself.

But what about the inhabitants of Gaia-n, who celebrate not 12 but n days of Christmas?

On the first day, such an inhabitant receives 1 present; on the second day, 1 + 2; on the third, 1 + 2 + 3; etc. Then, thanks to a theorem by some clever little kid, we can write the number of gifts he receives on day k as , the k^th triangular number, and thus the total number of presents he receives in all ndays as the sum of triangular numbers (where C is for Christmas.)

A geometric argument easily shows that , so (assuming n is even)

which is four times a pyramid number! Substituting the closed expression for the sum and simplifying gives,

.

We can easily verify that this expression also gives the correct answer when n is odd, and moreover as we hoped!

On other planets, inhabitants may celebrate a fraction of a number of days of Christmas, and they may wish to extend the expression to any real (or complex!) number, i.e.

which we naturally call the Christmas polynomial.

We may also wonder how many gifts someone will receive who has relatives on each of the planets Gaia-1, Gaia-2, …, up to Gaia-n. That is, what is the value of the sum ?

Because we may write and , it is a reasonable guess that . This indeed turns out to be the case, and so we may naturally define a generalized Christmas function

(where χ is for Xmas.) This results in the sequences

and so on, allowing us to calculate a great number of Christmas gift-giving scenarios.