

An accesible & intuitive layman's explanation of Bayes' Theorem - lobo_tuerto
http://oscarbonilla.com/2009/05/visualizing-bayes-theorem/

======
loup-vaillant
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.)

------
nosignal
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 ;) ]

~~~
loup-vaillant
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>

~~~
nosignal
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 ;)

------
pjscott
I'm impressed: this actually _is_ accessible and intuitive.

------
gmantastic
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.

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

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

------
tel
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>

