A Refresher on Logarithms

· 6 min read · #math #logarithms #algorithms #data-structures #complexity

If you are taking Data Structures with me, logarithms are about to show up everywhere: binary search, balanced trees, the cost of sorting. You met them in a math class once, and then you probably never used them again. This page is a refresher — no prior fluency assumed. Let's rebuild logarithms from the one idea they rest on.

What a logarithm actually is

A logarithm is the inverse of exponentiation. That single sentence is the whole game.

Exponentiation asks: start with a base, raise it to a power — what do you get? A logarithm runs that backwards: you know the base and the result; what was the power?

We write it like this:

Read as "the power you raise to in order to get ." The is the base.

Let's pin this down with one concrete case we'll come back to throughout this page. Take base and :

That's it. is just the answer to "two to the what gives eight?" — and the answer is three. Whenever a logarithm looks intimidating, translate it back into that question.

(Two small print conditions, so nothing surprises you later: the base must be positive and not equal to , and you can only take the log of a positive . You can't raise a positive base to any power and land on zero or a negative number, so those inputs have no answer.)

Two values fall straight out of the definition:

Anything to the zero power is one, so the log of one is always zero. And the base raised to the first power is itself, so the log of the base is always one.

The laws of logarithms

There are three laws you'll lean on, plus a fourth for switching bases. Here they are together; we'll derive each one in the next section.

These laws use the same conditions as before: the bases are positive and not equal to , and every quantity inside a logarithm must be positive.

Notice the shape of the first three: multiplication on the inside turns into addition on the outside, division turns into subtraction, and a power turns into multiplication. A logarithm often knocks an operation down one level. That is exactly what made logarithms useful for hand calculation centuries ago, and it is why they tame the multiply-heavy counting we do when we analyze algorithms.

Before deriving anything, let's just check the product law on numbers we can verify by hand:

Same answer both ways. Good. Now let's see why.

Where the laws come from

Every law here is an exponent law wearing a disguise. The trick is the same each time: name the logs we're working with, rewrite everything as powers of , and use the exponent rule we already know.

The product law

We want to understand . Start by naming the two logs on the right:

By the definition of a logarithm, that's the same as saying:

Now multiply and by multiplying their power-of- forms:

The second line is the one exponent law we need: multiplying same-base powers adds the exponents. Now read that result back through the definition of a logarithm — equals raised to , so the log of is :

That's the product law. Multiplication inside became addition outside, because multiplying powers adds their exponents.

The quotient law

Same setup, division instead of multiplication. With and :

Dividing same-base powers subtracts the exponents. Reading it back:

The power law

Now . Name the inner log, , so . Then:

Raising a power to a power multiplies the exponents. So is raised to , which means:

A power inside comes out front as a plain multiplier. This is the law that lets us pull an exponent down — we'll use it in a moment to switch bases.

Change of base

Calculators and the laws above are happy in any base, but the log on your calculator is usually base or base , while in algorithms we almost always want base . So we need a way to compute using some other base we can evaluate.

Let , which means . Both sides are equal, so their logs in base are equal too:

The second line is just the power law applied to the left side — it pulled the exponent out front. Now solve for by dividing:

And was all along, so:

Let's confirm it on our running example, getting out of base- logs:

There's a quiet payoff hiding here. Changing the base only ever divides by a constant ( doesn't depend on ). So , , and differ only by a constant factor. When we care about how a cost grows rather than its exact value, the base of the logarithm stops mattering — which is why you'll often see people write just "" and not fuss over the base.

Where this shows up in algorithm analysis

Two quick examples, both built on the same observation: doubling and halving are the operations logarithms count.

Binary search: counting halvings

Binary search looks for a value in a sorted array by checking the middle, then throwing away the half that can't contain the target. Each comparison either finds the target or cuts the remaining range roughly in half. Start with candidates:

After halvings the range has size about . Ignoring the small off-by-one details for the moment, the search is down to a single candidate when:

The middle line just multiplies both sides by ; the last line reads through the definition of a logarithm — is the power of that gives . So binary search takes on the order of comparisons. The exact worst-case count has a small rounding/off-by-one term, but the growth is logarithmic.

Check it against our running case. With : is three halvings, and . Depending on exactly when the target is found, binary search may use one more comparison than the number of halvings, but the logarithm is the part that controls the growth. That's the whole reason a sorted array is worth the trouble — searching a million elements costs about comparisons, not a million.

Counting bits: the inverse direction

Here's the same idea running the other way. For a positive integer , how many binary digits — bits — do you need to write the number ?

Each bit you add doubles how many values you can represent. With bits you can write different numbers, namely through . So to have a code for every value from through , you need enough bits that . Solving the rough version, , for gives — the same log, because doubling-per-bit is just halving-per-step read backwards.

Pinned to a number: in binary is , which is bits. The exact count is for , so for we get . (The floor and the are bookkeeping for the off-by-one; the is the part that matters.)

The take-home message

A logarithm answers one question: what power gives this number? Every law is an exponent law read through that lens — products become sums, powers become multipliers, and changing the base only ever costs a constant factor. In this course, captures the number of times you can halve before reaching (exactly when is a power of , and up to rounding otherwise). Keep that picture in mind and the cost of binary search, balanced trees, and good sorting algorithms will all read the same way.