# Master Method

# Internal

# Overview

The **master method** or **master theorem** is a general mathematical tool for analyzing the running time of divide and conquer algorithms that divide a problem in **equal** subproblems and call themselves recursively. The fact that the subproblems are equal in size is important: master method does not apply to divide and conquer algorithms that divide the problem in unequal parts. There are generalization of the master method that apply to unbalanced problems, but they are not addressed in this article.

Also, the master theorem offers running time predictions as Θ() - **bounded from above and below** - as long as the running time for the combine phase of the divide and conquer algorithm is offered as Θ(). If the running time for the combine phase of the algorithm is given as O(), then the master theorem can be used to predict O().

The master theorem applies to recursive algorithms whose running times can be expressed with a generic formula called recurrence, as described below.

# Master Method and Recurrences

Master method can be applied to predict running time for recursive algorithms whose running time can be expressed as a recurrence (or recurrence equation). The first step in applying the master method is to identify the recurrence that characterizes the algorithm.

We denote the maximum number of operations the algorithm needs to solve the computational problem for a problem of size n with T(n). This is the quantity we want an upper bound for. The recurrence is a way to express T(n) in terms of T() of smaller numbers, specifically the size of the subproblems the recursive algorithm calls itself recursively on.

Every recurrence has two ingredients:

- a base case that describes the running time where there is no further recursion.
- the general case, that describes the running time done by the recursive calls invoked at that level plus the work that is done by the current level.

In the most generic case, a recurrence looks like this:

┌ │ ≤ c # base case, running time bounded by a constant for sufficiently small n T(n) = │ │ ≤ aT(n/b) + O(n^{d}) # general case, for larger n └

For the general case:

- a is the number of subproblems (recursive calls).
- b is the factor by the input size shrinks before the recursive call is applied. b is constant bigger than 1. For example, if we call recursively on each half of the current problem, then b is 2.
- d is the exponent in the running time of the "combine" phase, the amount of work that is done outside the recursive calls. d can be zero or larger.

The recurrence expresses the fact that solving the original problem involves dividing the problem into "a" subproblems of size "n/b", applying the algorithm recursively *a* times on *n/b*-size problems and then combining the result in O(n^{d}) time. If the problem size is small enough (n ≤ n_{0}) the straightforward solution takes constant time.

The fact that we express the subproblem size as n/b shows that for master theorem to apply, all subproblems must have the same size.

# Formal Definition

┌ │ a │ O(n^{d}log n) if a = b^{d}(or ── = 1) # Case 1 │ b^{d}│ a T(n) = │ O(n^{d}) if a < b^{d}(or ── < 1) # Case 2 │ b^{d}│ a │ O(n^{logba}) if a > b^{d}(or ── > 1) # Case 3 │ b^{d}└

# Intuition

The conditions expressed in terms of a/b^{d} can be understood intuitively as an expression of a tug of war between two opposing forces: the force of good and the force of evil. "a" is the number of subproblems a problem of a certain level is divided into, so "a" can seen as the rate at which the subproblems proliferate (RSP) as we descend in the recursion tree. This is the force of evil, more subproblems there are, the algorithm will run slower. On the other hand, with each recursion level we do less work per subproblem, and the extent to which we do less work is expressed by b^{d}. b^{d} can be seen as rate of work shrinkage (RWS). Interestingly enough, the shrinkage of work grows with d - this seems a bit counterintuitive at the first sight.

In case of a tie (RSP is equal with RWS, a = b^{d}), we find ourselves in Case 1. The amount of work should be the same at each level of the recursion tree, to the total amount of work is the work on the first level cn^{d} multiplied with the number of levels log_{b}n, hence O(n^{d}log_{b}n). The base of the logarithm does not count asymptotically so the time complexity will be O(n^{d}log n).

When forces of good prevail (RSP < RWS, a < b^{d}, rate of work done by each subproblem is shrinking faster than the subproblem number growth) we find ourselves in Case 2. In this case, the biggest amount of work is at the root level, and that running time at the root dominates the total running time: O(n^{d}).

When forces of evil prevail (RSP > RWS, a > b^{d}, subproblems proliferate more rapidly than the savings per subproblem), we find ourselves in Case 3. The worst case will be at the leaves, the leaves dominate up to a constant factor, so the amount of work is proportional to the number of leaves: O(#leaves) = O(a^{logbn}). This can be rewritten as O(n^{logba}) Why?.

# Proof

The proof uses a recursion tree.

# Examples

- Merge Sort
- Binary search on a sorted array
- Karatsuba multiplication algorithm
- Strassen's matrix multiplication

# More Details

CLRS page 93.