Jeff Brown's Probability Quiz: What Are The Chances ...

Tue, 04 Aug 2009 02:40:08 GMT

... Jeff is of course talking about Grails, SpringSource, and Clojure. Near the end of the post, Jeff challenged his readers with a probability brain teaser:

Jeff Brown: I am honestly not sure how many technologists work for SpringSource but for the sake of having a number to work with, lets say there are 50. Lets also say that Clojure is interesting enough that 15% of JVM developers are interested in learning more about it. I can't back that number up with any research, lets just go with it. If 15% of JVM developers are interested in the language and you take a random group of 50 JVM developers (the 50 in question are certainly not 50 random developers, these are the edge cutters which probably makes them more likely to be interested in keeping an eye on what is new, but work with the idea that they are random)... Do the math. No, really... Do the math. Do the math to figure out the likelihood that 3 of the 50 would be interested in Clojure. I challenge you to do the math in Clojure and post your solution in a comment here. Do it in Scala, Do it in Groovy. Pick a JVM language and do the math.

My answer got a little bit too long for a comment on Jeff's blog. So I'm putting it here.

First of all, Jeff, its probability, not mathematics. They branched off a long time ago, just like computer science branched off more recently. It's nevertheless an interesting problem to ponder about in a Saturday morning. It also helps that I'm married to a statistician. Here's how the conversation went:

Me: Jeff Brown blogged about an interesting probability problem. (Reading the problem)
Her: The problem is not complete. He didn't mention how many JVM developers there are. The answer probably depends on it.
Me: For the sake of argument, let's say there are 100 of them.
Her: OK. Then the problem is equivalent to the following:

Problem: There is a jar of 100 balls. Among them 85 balls are black, and 15 balls are read. A batch of 50 balls are selected at random from the jar. A group of 3 balls are selected at random from the batch. What is the probability that all 3 balls in the selected group are red?

Me: That sounds like a probability problem the students could tackle.
Her: You analyze the scenario into more concrete cases: What if the batch of 50 contains no red balls? 1 red ball? 2? 3?, ... Use the Law of Total Probability. Here's the book!

(Saturday morning turned into Sunday evening, and we finally have a chance to work the problem out.)

We'll solve the probability problem by hand and reduce it to a computation problem that is as simple as possible, and then use the computing machinery.

Solution: We use the following letters to denote the various quantities:

n—the total number of balls
r—the number of red balls
m—the number of balls in the batch
k—the number of balls in the group

The event of selecting a batch of m balls and then selecting exactly k red balls from the m can be decomposed to:

selecting a batch of m balls containing exactly k red balls and then selecting exactly k red balls from the m
selecting a batch of m balls containing exactly k + 1 red balls and then selecting exactly k red balls from the m
...
selecting a batch of m balls containing exactly r red balls and then selecting exactly k red balls from the m

The law of total probability dictates that the probability of out target event is the sum of the products of the probabilities of each of the successive events in the above list:

P = Σ_{i = k}^r P(n, r; m, i) P(m, i; k, k)

where P(n, r; m, i) is the probability of selecting m balls from a jar of n balls containing r red balls and having exactly i red balls in the selected batch. The probability of this event is given by the formula

P(n, r; m, i) = C(r, i) C(n - r, m - i) / C(n, m)

where C(r, i) is the binomial coefficient.

With the problem thus solved, I went ahead to "Pick a JVM language and do the math." Guess which language I picked? Java. Yes, Java. Not Clojure. Not Scala. Not Groovy, but the old dependable Java. "Why?" you ask. Because doing it in any other language would have taken me longer to get the results out.

Here are the classes I wrote:

Foo.java

1    public class Foo { 
2      private int n; 
3      private int r; 
4      private int m; 
5      private int k; 
6     
7      public Foo(int n, int r, int m, int k) { 
8        this.n = n; 
9        this.r = r; 
10       this.m = m; 
11       this.k = k; 
12     } 
13    
14     public static double C(int n, int k) { 
15       System.out.println("C(" + n + ", " + k + ") called."); 
16       double prod = 1.0; 
17       for (int i = 1; i <= k; i++) { 
18         prod *= ((double) (n - i + 1)) / ((double) i); 
19         System.out.println("\tIteration " + i + ": prod = " + prod); 
20       } 
21       System.out.println("\tReturning " + prod); 
22       return prod; 
23     } 
24    
25     public static double P(int n, int r, int m, int i) { 
26       System.out.println("P(" + n + ", " + r + ", " + m + ", " + i + ") called."); 
27       double retVal = C(r, i) * C(n - r, m - i) / C(n, m); 
28       System.out.println("\tReturning " + retVal); 
29       return retVal; 
30     } 
31    
32     public double P() { 
33       double sum = 0.0; 
34       for (int i = k; i <= r; i++) { 
35         sum += P(n, r, m, i) * P(m, i, k, k); 
36       } 
37       return sum; 
38     } 
39   } 
40

Main.java

1    public class Main { 
2      public static void main(String[] args) { 
3        Foo foo = new Foo(100, 15, 50, 3); 
4        System.out.println(foo.P()); 
5        System.out.println(Foo.P(100, 15, 3, 3)); 
6      } 
7    } 
8

According to my calculation, the probability of the event that Jeff described is 0.0028138528138528123 or 0.28% assuming there are 100 JVM programmers.

There are two points that's worth mentioning:

The condition of there being 50 SpringSource programmers can be actually shown to be superfluous. And the calculation can therefore be simplified to merely that of P(100, 15; 3, 3)
It can be shown that P(n, r, k, k) tends to (r/n)^k as n and r grows to infinity while the ratio r/n is kept constant.

(Now it's Monday morning. After staring at the 0.28% probability for a while, I realized something...)

What I calculated is not what Jeff wanted. He clearly said he wanted "the likelihood that 3 of the 50 would be interested in Clojure", or, in our language, "the probability of selecting 50 balls that contains exactly 3 red balls." That's P(100, 15; 50, 3), which is 0.009392308830476828 or 0.94%.

A simple experiment suggests that as n and r grows to infinity while the ratio r/n is kept constant, the probability tends to 3.19%.

(It's Monday evening now. And I again have doubts about if I solved the right problem.)

Did Jeff mean "the likelihood that at least 3 of the 50 would be interested in Clojure"? After all, from the description of the story I can't infer that the other 47 are not interested in Clojure.

The probability of that would be

&Sigma_{i = 3}¹⁵ P(100, 15; 50, i)

which turns out to be 99.8%.

(I think I'll turn my work in now. Or I'll start doubt my solution again tomorrow morning.)

Your jirb, groovysh and clj Commands Doesn't Work In Cygwin

Tue, 08 Apr 2008 13:28:08 GMT

This is another one of those making things work in Cygwin posts. You can safely skip this post if you are not married to Cygwin, or have not followed my Ten Steps To Higher Cygwin Productivity.

The issue this time is with a little library called JLine, which is a BSD licensed library that brings GNU readline style command line editing to Java. I first learned about it through the Clojure programming language (a LISP with immutable variables and software transactional memory (STM)).

And of course, it doesn't work in my Cygwin xterm window. A little Googling landed me at JLine issue-1822900. A little looking around in the JLine source and some experiments later, I had a partial workaround, which I added as a comment to the issue.

While doing the Google search, I also noticed that both Groovy and JRuby use JLine to some extend (in jirb and groovysh). Sure enough, the same issue showed up in the Groovy JIRA as GROOVY-2584, to which I added the workaround.

A fresh download of the just released JRuby 1.1 showed the same symptom. The JLine workaround can be applied directly to the jruby script, which, thankfully, does contain infrastructure for Cygwin support.

There are other issues with JLine on a Cygwin xterm. But the workaround at least makes the repls workable.

The part that makes me uncomfortable is that I don't see how this workaround can be incorporated into a patch for JLine. In that regard, I concede Cygwin is a somewhat hacky platform. (Jonathan and Adam, if you are still reading...)

Java News Brief (JNB): Introduction to Grails

Tue, 06 Mar 2007 17:49:08 GMT

The March issue of the Java News Brief (JNB) is out. Jeff Brown gives an introduction to Grails—the "framework for agile web development using Groovy and Java."

Jeff Brown: Grails is a remarkably flexible framework while maintaining an ease of use that is unparalleled by other web application frameworks targeted for the JVM. Use the exercises in this article as a jump start with Grails and have fun exploring the possibilities.

Weiqi Gao's Observations - groovy tag

Jeff Brown's Probability Quiz: What Are The Chances ...

Your jirb, groovysh and clj Commands Doesn't Work In Cygwin

Java News Brief (JNB): Introduction to Grails