This began life as me explaining entropy and KL divergence to friends on a group chat. All my logs are base 2.
§ Surprise
We wish to measure how "surprising" something is. We will measure this as where is the probability of an event. This way, if an event is deterministic ( ) then its surprise is 0. If an event is impossible ( ), then its surprise is infinite. So the surprise of an event whose probability is is going to be .
§ Entropy is expected surprise
The entropy of a random variable is the expected surprise we are going to get from it:
For example, given a binary random variable which takes on heads with probability and tails with probability , the entropy is going to be . We can check that this is maximum when . This ought to be intuitive, because when , we can't predict anything about the coin toss. If it were slightly higher, then we could guess that it's more likely to be heads, so we "know more" about it.
Note that to define the entropy, all we needed was . So really, entropy is a property of a probability distribution. And if we think about it a little carefully (ie, stare at the equation and fiddle with it), we come to the intuition that entropy is high when is spread out. One can show that the uniform distribution is the unique distribution that has the highest entropy over a set . The intuition is the same as the coin's: if the distribution is uniform, you can't really guess.
§ Entropy is bits you have to pay
OK, now we move to the coding theory perspective on all this, which is the one true way (and is, BTW, also the right way to understand KL divergence IMO). We have a sender who is sending elements , with each drawn IID from with distribution . Now, how many bits do we need to encode ?
We can design clever schemes and stupid schemes. Coding theory proves that on average, the best encoding scheme will need bits to encode each . It might spend more bits on some and fewer bits on some , but on average we will need bits, if the data is generated using the distribution . For an actual example of this, see Huffman coding : it achieves optimal encoding, choosing a different number of bits for different elements of , and it doesn't clash because it's prefix-free and blah.
Some questions, for intuition about this entropy-as-encoding-cost:
- Q1: we have a coin that is biased such that it only outputs heads, and we're going to be sending the results of the coin flips. How many bits do we need? A1: zero, because we don't need to transmit anything: the receiver already knows what's going to be sent, since the sequence must be [heads, heads, heads, ... ]. There's no point in transmitting it. (This is actually somewhat of a failing of entropy: it only considers the unknown to be information. If you have some complex, deterministic thing, it's not information in this perspective. Other perspectives, such as descriptive complexity , remedy this.)
- Q2: a coin that takes heads and tails in equal likelihood? A2: we are forced to use 1 bit, since . This is from Shannon's source coding theorem .
- Q3: what is the "good" encoding of a coin where heads occurs with probability 0.9 and tails with 0.1? Entropy tells us that we ought to manage with bits per flip. A3: batch flips together and encode runs.
§ KL divergence is extra bits you pay
KL divergence is a divergence (not a distance!) between two probability distributions , which tells us how many extra bits we pay on average if the data came from distribution , but we encoded it as if it came from distribution . That is:
- I was given , sampled from .
- is handed to an encoder which assumes the data was sampled from (notice, not ).
- uses more bits than would, since it has inefficiencies. How much more? That's the KL divergence between and :
You can look at it from an adversarial perspective:
[data ~ p(x)] --> [encoder ~ p(x)] (optimal) [baseline][data ~ p(x)] --> [encoder ~ q(x)] (adversarial) [how bad are you?]§ The fair coin and the heads coin
We go back to the humble unfair coin, for we are gamblers. Assume we have two coins. One is fair, governed by a distribution with ( for fair). The other only tosses heads: , .
Before computing, let's talk intuitions. How do we encode the fair coin? We encode heads as 0 and tails as 1. How do we encode the heads coin? Well, coding theory says "don't". There's nothing to send, so don't bother sending information.
- If I have the encoder and I hand it the sequence HHH generated from the heads coin, it'll spend 3 bits, encoding it as 000. will do fine (and not send anything), because it assumes anything it has to send is of the form HHHHH... So paid extra bits, assuming the underlying distribution was : is finite (it's 1 bit per flip).
- If I have the encoder and I hand it the sequence HTH generated from the fair coin, it's out of luck. How the fuck is it supposed to send T? It needs to spend infinitely more bits than to do anything: .
So, well, clearly, this is not a symmetric concept. If there are things you literally cannot encode, you spend an infinite number of bits trying to encode them. If there are things you can encode but are bad at, you spend more bits trying. But you'll always spend more bits, on average.
This example is also how I remember the formula:
- It has to be , since we're riffing off of entropy.
- It is either or .
- It has to be , since if (ie, cannot represent something), it is infinitely far away from : . Aka "out of band stuff costs infinite bits".
- And it has to be because if (ie, the source never gives you this data), I don't care whether we can encode it or not, following the convention that .
A friend ( Aditya Bharti ) offered a far less roundabout mnemonic: the expected bits to encode is , where the first is there because it's an expectation, and the second is there because the encoder uses the distribution to calculate the number of bits. If the encoder makes the wrong assumption (data from , encoder assuming ), the expectation stays but the encoder's term becomes . Subtract the honest cost from the wrong-assumption cost, and the formula falls out. I'm a little iffy with this one because you can write distributions where goes negative for some while the overall sum remains positive, which is why I refrain from the pointwise perspective. But it's a useful mnemonic.
§ KL divergence is non-negative: the Bregman divergence
We have not yet proved that KL divergence is always non-negative. So let's do that next. I'm going to define a weird geometric distance that's only valid for convex functions, into which when we plug in our surprisal, life is going to be dandy, and we regenerate the KL divergence. This gadget is called as the "Bregman divergence".
So, let us begin with the humble equation , where I use for the dot product (yay quantum notation). Now, we can algebraically manipulate it:
where , so . We can interpret the last line as
and is the equation of a point on a line: start at , with slope , and move for a distance of . So the distance we are measuring is the gap between the value of the function at and the tangent drawn at , followed out to . Draw the parabola and a tangent line: for a convex function this gap is clearly always positive (for a formal proof, please, the convexity of ).
Now, we can choose to generalize this to any convex function , and it will give us an analogous "distance". Note that the same argument holds in ; we used nothing special about here. So define the divergence
Now plug in the convex function , whose derivative is . On simplification (for probability vectors, the terms are zero since both sum to one):
Hence, KL divergence is the Bregman divergence of , and is non-negative. Here is a great visualization link: Meet the Bregman divergences . Anyway, that's my preferred proof for KL divergence being non-negative.
§ Conclusion
Why for surprise, and not some other function that is 0 when (which other functions satisfy as well)? If you add the condition that for independent , along with some other intuitive conditions, entropy is uniquely characterised .
I'm still somewhat dis-satisfied with my KL divergence explanation. I'll do the Fisher information based motivation someday.