Tag: nerdy

By request, here's my attempt to explain Bayes' theorem (cribbing heavily from Wikipedia).

Deriving Bayes' Theorem

We start with the standard definition of conditional probability (for events A and B):

Which reads: The probability of event A given the known occurrence of event B is equal to the joint probability of events A and B (e.g., the probability of both events occurring) divided by the probability of event B (assuming the probability of B is not zero).  I'm not going to show the derivation of conditional probability.

The summation axiom helps us understand the joint probability of A and B:

It tells us that the joint probability of A and B is equal to the probability of A given B multiplied by the probability of B.  All we're talking about is the likelihood of events A and B both occurring.

Keep the following equivalence in mind, we'll need it in a minute.  It simply says that the order of variables when writing the joint probability is irrelevant.  It should be fairly straightforward that the likelihood of events A and B both occurring is the same as the likelihood of events B and A both occurring.

Filling back in our definition of conditional probability, we have (with the understanding that P(B) is not 0):

The third equation is the simplest form of Bayes' theorem.  It wasn't very hard to get to and the math, relatively speaking, is quite simple (we're not talking about deriving the Schrödinger equation or anything absurd).  But its application, and understanding what it means, can be tricky.

P(A) is called the "prior," representing our prior belief in the occurrence of event A.

P(A|B) is called the "posterior," representing our belief in the occurrence of event A after (post) accounting for event B.

The remaining pieces, P(B|A) / P(B), are called the "support," representing the support event B provides for the likelihood of event A occurring.

Applying Bayes' Theorem

I'll re-use the medical testing scenario from the previous post.

Substituting T to represent a positive test result and D to indicate the presence of the disease our equation becomes:

We expand P(T) into P(T|D)P(D) + P(T|¬D)P(¬D) which is to say: The probability of getting a positive test, P(T), is equal to [the probability of getting a positive test when the disease is present, P(T|D), multiplied by the probability that the disease is present, P(D)] plus [the probability of getting a positive test when the disease is not present, P(T|¬D), multiplied by the probability that the disease is not present, P(¬D)].

So now we just need to map the numbers we have about the disease and the test to the variables in our equation:

P(D), our prior, is 1 in 200 million--the disease occurrence rate in the general population.

P(T|D), the probability of getting a positive test when the disease is present, is derived from the false negative rate.  When the disease is present, our test will only incorrectly say it is not 1 out of 200,000 times; so P(T|D) is 199,999 out of 200,000.

P(T|¬D), the probability of getting a positive test when the disease is not present is the false-positive rate: 1 in 100,000.

P(¬D), the probability of the disease not being present is simply the other 199,999,999 out of 200 million.

So let's plug these numbers in step by step:

And we see that P(D|T), the probability that the disease is present given a positive test, is only 4.76%.  (My previous post incorrectly reported this as 0.05%, I've corrected the error.)

The car example I presented didn't use hard numbers, but I'll frame the concept into Bayes' Theorem.  S will represent a car being stolen and H will represent a car being a Honda Civic:

Which says, the probability that a car is stolen given that it's a Honda Civic is equal to [the probability that a car is a Honda Civic given that it's stolen] multiplied by [the probability of a car being stolen] divided by [the probability of a car being a Honda Civic].

The dealership was trying to push an insurance policy on me by only reporting P(H|S), but unless we account for the number of Honda Civics on the road in the first place, P(H), we aren't getting the full story.

(Notice that we don't have to actually care about P(S) if all we're doing is comparing car make/models.  P(S) doesn't change for the different make/models so it doesn't affect the relative rankings.)

Mom forwarded an email that was attempting to scam her in response to a Craigslist ad she placed for some furniture.

While I was thinking about this I realized we have the ability to essentially stop check forgery, specifically cashier's checks and money orders, but the principle would also apply to personal checks if we could develop a trusted lookup source for public keys.

Public-key cryptography allows you to publish a public key that can be used to either verify that you digitally signed something with your private key or to encrypt something which can only be decrypted with your private key.

The application would be as follows.

First, the banks put together a trusted database of public keys. This part is essential, as it must be possible to lookup a public key for any bank and you need to have a trusted source where at you do the lookup. A central database is mainly a convenience factor, you could simply have each bank publish their public key on their own site, but a more integrated solution is more likely to be used. This is not an insurmountable hurdle.

Second, when a bank creates a cashier's check it uses the data on the check (name, amount, date, etc.) and their private key to produce a digitally signed digital copy (or digitally signed hash) of the data which could be printed directly on the check as a QR code (or set of QR codes depending on size) [QR codes are those square barcodes].

Third, when someone attempts to cash the check the cashing bank scans the QR code(s) and verifies that the data matches what's printed on the check and also looks up the public key of the issuing bank and verifies that the signature is legitimate. In fact the actual printed data would be unnecessary at this point if it was encoded in the QR code, but I imagine we'd want to leave it on for the sake of the humans handling the check.

That's it. If implemented correctly and securely it would guarantee the authenticity of cashier's checks. The same system could be used for money orders as well. The other great thing about it is that individuals could verify a check the same way. They could scan the QR codes themselves with their fancy phones and then lookup the bank's public key (either from a trusted central repository or from the individual bank) and verify the authenticity of the check without any risk.

The biggest hurdles would really be getting a trusted repository set up and having banks securely store their private keys. There are easy extensions making this process even more feasible. You can use a master key to create sub-keys which could be used by individual branches. That would limit the risk if any individual branch's private key were compromised. With a central repository a compromised bank would revoke the published public key and flag it as compromised. Any outstanding checks would need to be brought back to the issuing bank to be reissued using a new key. A hassle, but it should be a world-shattering occurrence for a private key to be compromised.

This system is totally possible with today's technology. It would just be a matter of setting it up and getting banks to participate. Maybe I should go talk to some venture capitalists...

I did a search a moment ago and was surprised to discover that real-time searching is enabled for my account. This is apparently Google's big announcement today. It's kind of neat; no more hitting "Enter" or clicking "Search".

It doesn't seem to be active for everyone yet. I pulled up a different browser without logging in to my Google account and there was no real-time searching there.

The name they're using is "Instant Search" there's an option next to the search box to turn off instant search: