X = X + 1 Is Evil

Tue, 22 Sep 2009 13:11:50 GMT

(Not via Twitter.)

Rich Hickey (in an Artima interview): For example, take a mutable Date class that has year, month, and day. To me, changing a date is like trying to change 42 into 43.

This is as close an elevator pitch for pure functional programming as I've ever seen.

Rich's analogy reminds me of the most painful experience I had when I started programming. So painful that I suppressed that memory ever since. That was when I first saw

x = x + 1;

That's impossible, I thought. That's plainly wrong. It took me days or weeks to "get over" it. My mind fought the rationalization for such stupidity:

The equal sign is not a mathematical equal sign but an assignment. (What?)
The read x and the blue x means different things. (What?)
The blue one is the value before the assignment, and the red after. (Before?)
It's really the location. (Location or value, which is it?)

Of course, given no other practical alternatives, I gave in just like everyone else. And now we are in this concurrency crisis. For countless times, we've been called to "look at" problems where a program is not "working" because the assignments are not happening in the order the programmer envisioned. There clearly is a systemic problem.

Rich Hickey's solution is his clojure programming language. I dabbled with it a bit in the past year. I have gotten tremendous value out of Mark Volkmann's write ups on Clojure and STM.

In Mark's latest tweets and emails, he often mentions these three things in one breath:

Immutable objects
Persistent data structures
Transactional software memory

I wonder if that will become the rallying cry for Clojure and Clojure-like alternatives to main stream languages. If so, a paradigm shift is afoot.

Remember OO got traction after its "encapsulation, inheritance, and polymorephism" motto was coined.

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

Mark Volkmann: Clojure---Functional Programming for the JVM (And a Friday Quiz)

Fri, 15 May 2009 15:16:54 GMT

Just want to let everyone know that Mark Volkmann did the Clojure presentation at the St. Louis Java Users Group yesterday evening.

The slides are here:

Please also check out Mark's Clojure page for an constantly updated version of his February 2009 JNB article on the same topic.

CodeToJoy did a pre-game analysis.

In honor of the presentation, today's quiz is a clojure one:

Q: What would the following code produce:

(defn f [x [y z]]
        [y [z x]])
(f 1 [2 3])

Weiqi Gao's Observations - clojure tag

X = X + 1 Is Evil

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

Mark Volkmann: Clojure---Functional Programming for the JVM (And a Friday Quiz)