Subsections

# 1.2 Mathematical Background

In this section, we review some mathematical notations and tools used throughout this book, including logarithms, big-Oh notation, and probability theory. This is intended to be a review of these topics, not an introduction. Any reader who feels they are missing this background is encouraged to read, and do exercises from, the appropriate sections of the very good (and free) textbook on mathematics for computer science [45].

## 1.2.1 Exponentials and Logarithms

The expression denotes the number raised to the power of . If is a positive integer, then this is just the value of multiplied by itself times:

When is a negative integer, . When , . When is not an integer, we can still define exponentiation in terms of the exponential function (see below), which is itself defined in terms of the exponential series, but this is best left to a calculus text.

In this book, the expression denotes the base- logarithm of . That is, the unique value that satisfies

Most of the logarithms in this book are base 2 (binary logarithms), in which case we drop the base, so that is shorthand for .

An informal, but useful, way to think about logarithms is to think of as the number of times we have to divide by before the result is less than or equal to 1. For example, when one does binary search, each comparison reduces the number of possible answers by a factor of 2. This is repeated until there is at most one possible answer. Therefore, the number of comparison done by binary search when there are initially at most possible answers is at most .

Another logarithm that comes up several times in this book is the natural logarithm. Here we use the notation to denote , where -- Euler's constant -- is given by

The natural logarithm comes up frequently because it is the value of a particularly common integral:

Two of the most common manipulations we do with logarithms are removing them from an exponent:

and changing the base of a logarithm:

For example, we can use these two manipulations to compare the natural and binary logarithms

## 1.2.2 Factorials

In one or two places in this book, the factorial function is used. For a non-negative integer , the notation (pronounced  factorial'') is defined to mean

Factorials appear because counts the number of distinct permutations, i.e., orderings, of distinct elements. For the special case , is defined as 1.

The quantity can be approximated using Stirling's Approximation:

where

Stirling's Approximation also approximates :

(In fact, Stirling's Approximation is most easily proven by approximating by the integral .)

Related to the factorial function are the binomial coefficients. For a non-negative integer and an integer , the notation denotes:

The binomial coefficient (pronounced  choose '') counts the number of subsets of an element set that have size , i.e., the number of ways of choosing distinct integers from the set .

## 1.2.3 Asymptotic Notation

When analyzing data structures in this book, we will want to talk about the running times of various operations. The exact running times will, of course, vary from computer to computer and even from run to run on an individual computer. When we talk about the running time of an operation we are referring to the number of computer instructions performed during the operation. Even for simple code, this quantity can be difficult to compute exactly. Therefore, instead of analyzing running times exactly, we will use the so-called big-Oh notation: For a function , denotes a set of functions,

Thinking graphically, this set consists of the functions where starts to dominate when is sufficiently large.

We generally use asymptotic notation to simplify functions. For example, in place of we can write, simply, . This is proven as follows:

which demonstrates that the function is in the set using the constants and .

There are a number of useful shortcuts when using asymptotic notation. First:

for any . Second: For any constants ,

These inclusion relations can be multiplied by any positive value, and they still hold. For example, multiplying by yields:

Continuing in a long and distinguished tradition, we will abuse this notation by writing things like when what we really mean is . We will also make statements like the running time of this operation is '' when this statement should be the running time of this operation is a member of .'' These shortcuts are mainly to avoid awkward language and to make it easier to use asymptotic notation within strings of equations.

A particularly strange example of this comes when we write statements like

Again, this would be more correctly written as

The expression also brings up another issue. Since there is no variable in this expression, it may not be clear which variable is getting arbitrarily large. Without context, there is no way to tell. In the example above, since the only variable in the rest of the equation is , we can assume that this should be read as , where .

Big-Oh notation is not new or unique to computer science. It was used by number theorist Paul Bachmann as early as 1894, but it is immensely useful in describing the running times of computer algorithms. Consider a piece of code like the following:

  void  snippet() {
for (int i = 0; i < n; i++)
a[i] = i;
}

One execution of this method involves
• assignment ( ),
• comparisons ( ),
• increments ( ),
• array offset calculations ( ), and
• indirect assignments ( ).
So we could write this running time as

where , , , , and are constants that depend on the the machine running the code and represent the time to perform assignments, comparisons, increment operations, array offset calculations, and indirect assignments, respectively. If this is the expression for the running time of two lines of code, then clearly this kind of analysis will not be tractable to complicated code or algorithms. Using big-Oh notation, the running time simplifies down to

Not only is this more compact, but it also gives nearly as much information. The fact that the running time depends on the constants , , , , and in the above example means that, in general, it will not be possible to compare two running times to know which is faster without knowing the values of these constants. Even if we go through the effort of determining these constants (say, through timing tests) then our conclusion will only be valid for the machine we run our tests on.

Big-Oh notation allows us to reason at a much higher level, making it possible to analyze much more complicated functions. If two algorithms have the same big-Oh running time, then we won't know which is faster, and there may not be a clear winner. One may be faster on one machine and the other may be faster on a different machine. However, if the two algorithms have a demonstrably different big-Oh running time, then we can be certain that the one with the smaller running time will be faster for large enough values of .

An example of how big-Oh notation allows us to compare two different functions is shown in Figure 1.5, which compares the rate of grown of versus . It might be that is the running time of a complicated linear time algorithm while is the running time of a considerably simpler algorithm based on the divide-and-conquer paradigm. This illustrates that, although is greater than for small values of , the opposite is true for large values of . Eventually wins out, by an increasingly wide margin. Analysis using big-Oh notation told us that this would happen, since .

In a few cases, we will use asymptotic notation on functions with more than one variable. There seems to be no standard for this, but for our purposes, the following definition is sufficient:

This definition captures the situation we really care about: when the arguments make take on large values. This agrees with the univariate definition of when is an increasing function of . The reader should be warned that, although this works for our purposes, other texts may treat multivariate functions and asymptotic notation differently.

## 1.2.4 Randomization and Probability

Some of the data structures presented in this book are randomized; they make random choices that are independent of the data being stored in them or the operations being performed on them. For this reason, performing the same set of operations more than once using these structures could result in different running times. When analyzing these data structures we are interested in their average or expected running times.

Formally, the running time of an operation on a randomized data structure is a random variable and we want to study its expected value. For a discrete random variable taking on values in some countable universe , the expected value of , denoted by , is given the by the formula

Here denotes the probability that the event occurs. In all the examples in this book, these probabilities are only with respect to whatever random choices are made by the randomized data structure; there is no assumption that the data stored in the structure is random or that the sequence of operations performed on the data structure is random.

One of the most important properties of expected values is linearity of expectation: For any two random variables and ,

More generally, for any random variables ,

Linearity of expectation allows us to break down complicated random variables (like the left hand sides of the above equations) into sums of simpler random variables (the right hand sides).

A useful trick, that we will use repeatedly, is that of defining indicator random variables. These binary variables are useful when we want to count something and are best illustrated by an example. Suppose we toss a fair coin times and we want to know the expected number of times the coin comes up heads. Intuitively, we know the answer is , but if we try to prove it using the definition of expected value, we get

This requires that we know enough to calculate that , that we know the binomial identity , and that we know the binomial identity .

Using indicator variables and linearity of expectation makes things much easier: For each , define the indicator random variable

Then

Now, , so

This is a bit more long-winded, but doesn't require that we know any magical identities or compute any non-trivial probabilities. Even better: It agrees with the intuition that we expect half the coins to come up heads precisely because each individual coin has probability of coming up heads.

opendatastructures.org