Hacker News new | past | comments | ask | show | jobs | submit login
An accesible & intuitive layman's explanation of Bayes' Theorem (oscarbonilla.com)
81 points by lobo_tuerto on Sept 3, 2011 | hide | past | favorite | 8 comments



Links to other explanations not mentioned in the article :

http://wiki.lesswrong.com/wiki/Bayes%27_theorem

http://lesswrong.com/lw/2b0/bayes_theorem_illustrated_my_way

http://commonsenseatheism.com/?p=13156

(I don't mean to critique the article, which by the way looks great — short, yet comprehensible. It's just that different explanations may suit different people or be complementary.)


You know an explanation is good when you read it and think "Wait, that's it? Well of course I get that - I thought this was supposed to be complicated!"

Thanks for posting this. I have been trying to read & understand the Yudkowsky article linked to from this one for literally months without quite getting it - or I'd think I got it, then get confused again 2 paragraphs further down.

This one is MUCH more accessible and intuitive. "What we've effectively done is change the Universe from U (all people), to B (people for whom the test is positive), but we are still dealing with probabilities defined in U."

It's… almost like a closure for probability? [disclaimer: I don't really "get" closures yet either ;) ]


I think I can help with closures. Basically, you just have to keep in mind that functions are mathematical objects like any other:

  (* A named integer, then a named function *)
  let x : int        = 42
  let f : int -> int = fun x -> 3 * x + 2

  (* an anonymous integer, then an anonymous function *)
  42
  fun x -> 3 * x + 2
So functions, like integers, can be expressed literally. Expressions (`2 + 2`, `map ((+) 2)`) can denote functions as well as integers. (You can make the analogy with C, where function pointers (not the full thing) can be the result of an expression).

Now imagine you pass an integer around (as parameter, return value, bound to a name, or stored in a variable), surely you don't expect it to be modified behind your back? For instance:

  let x = 40    in 
  let y = x + 2 in (* so, that's 42...         *)
  let x = 0     in (* ...right?                *)
  print_int y      (* right.  It does print 42 *)
So, `y` hasn't been modified behind your back. How is this possible? Well, there's 2 ways to see this: either

(i) `y` was completely computed at the time it was defined. So, we grabbed the `x` that was in scope by the time we defined `y`, computed 40 + 2, and bam, we got 42. Of course, the value of 42 is not at all dependent on the value of the `x` name that is currently in scope.

(ii) `y` was not completely computed by the time it was defined, but only by the time we really really need it (here, at print time). But it still prints 42, not 2. The catch is, the value under `y` is made up of two things: the expression `x + 2`, and a key-value store, which will tell you the value of that `x` in the expression (here, that would be [("x", 40)]). Those two things do not change when you define a new x. And when you need to compute `y`, then you compute the expression, knowing that the above key-value store has the priority (you will see `x = 40` first, and won't bother to look up the other `x`, which has value `0`).

Functions work in exactly the same way. No trap. No trick. For instance, the program

  let x = 40             in
  let f = fun a -> x + a in
  let x = 0              in
  print_int (f 2)
will still print 42. Also, the two interpretations above still hold. Just remember that functions are values like any other.

Now there are some caveats. If you allow side effects and it is not clear whether you enclose over values or over variables (or references), then some things may indeed be modified behind your back. (Imagine that the closure uses a key variable store where you thought it would be a key value store. Then it would be possible to change the content of the variables behind your back.) Anyway, my advice is to avoid side effects as much as you can[1].

[1]: http://www.loup-vaillant.fr/articles/assignment


Hey, thanks for that. Makes perfect sense. I definitely had an "oh is that all?" reaction.

I wish I could +1 you more than once for that, cheers! Now I get closures and bayesian reasoning, not bad for 2 days ;)


I'm impressed: this actually is accessible and intuitive.


I worked through the Yudkowsky article yesterday, and had to picture/sketch venn diagrams to get my head round it. I find this far more intuitive - the way it translates back to the notation is really clearly presented.


Khan Academy - Probability part 7 and 8 also explains it with pictures

http://www.khanacademy.org/video/probability--part-8


This is actually the precise definition of conditional probability derived from Kolmogorov's measure theoretical construction of probability. It's easily the most popular construction of probability.

http://en.wikipedia.org/wiki/Probability_space http://en.wikipedia.org/wiki/Probability_axioms




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: