Here are two ways to count the numbers from 1 to 1000000 in Python. First, the classical way:

sum([i for i in xrange(1000000)])

Runs 0.8s on an old Linux box. It uses quite a bit of memory.

Second, the better way:

sum((i for i in xrange(1000000)))

Runs 0.2s on the same box. It uses a tiny amount of memory.

That is right. The second option is 4 times faster! According to my tests, the second option remains better even if you only sum the numbers between 1 and 1000, though the benefits are then tiny.

Disclaimer: Yes, I am aware that I could simply do 1000000*(1000000-1)/2.

Source: Parand.

Google just told me my blog is being taken out of their index. I investigated. Spammers took over my blog footer, inserting a large set of invisible hyperlinks. They did even worse: they created a large set of PHP files (hundreds!) that were serving spam from my blog without my knowledge.

I upgraded Wordpress, changed my passwords, and I removed the offending files.

At least, Google was nice enough to warn me.

I just reviewed a paper where the authors come up with a nice highly scalable algorithm. And it is really scalable too! But to prove just how fast it is, they process 2,000 data points.

This is correct, strictly speaking. Their algorithm runs in O(n) time, so to know how long it would take to process 1000 times more data, just multiply by 1000.

But where is the fun in that?

Stephen Few few wrote a post on how insane academic publishing is. If you publish academic papers, his post is worth your time. Don’t miss the comments!

Stephen is not in academia. From his point of view, what is required of him makes no sense:

• While he does not expect to get paid for publishing a paper, he expects some kind of symbolic reward like a few subscription to the journal: Is there really any question that someone who takes the time to write an article and go through the lengthy process of working with a publisher, deserves a gesture of thanks equaling the cost of postage?
• Stephen is surprised that reviewers remain anonymous through the entire process: Cloaking the process in anonymity seemed to indicate a level of discomfort with critique that I didn’t expect to find to this degree in academia.
• He is upset with how IEEE handles copyright:”I have worked with several publishers and I have never had to give up my rights as author. Most modern publishers know that they don’t need to strip authors of their rights in order to do their job.“

My own answers:

• Anonymous review is just a system we refuse to question. Speaking your mind is certainly a dangerous thing—more so in some countries than others. However, I believe a scholar should have the backbone to speak out in the open. Do something else with your life if you are afraid to sign your opinion pieces.
• The copyright issue is a shame. However, Stephen should also ask why so many employers ask for non-compete clauses. He should also ask why musicians sign away their soul routinely. I have always been puzzled at how easily TV series are killed: clearly the authors lose their copyright along the way. Fortunately, scholars are pretty bad at reading the contracts they sign…

We have made available a PDF copy of the proceedings for the second Netflix/Large-Scale KDD Recommender workshop. It includes the following papers:

• Jinlong Wu and Tiejun Li. A Modified Fuzzy C-Means Algorithm For Collaborative Filtering
• Gavin Potter. Putting the collaborator back into collaborative filtering
• Andreas Toescher, Michael Jahrer and Robert Legenstein. Improved Neighborhood-Based Algorithms for Large-Scale Recommender Systems
• Oscar Celma and Pedro Cano. From hits to niches? or how popular artists can bias music recommendations
• Domonkos Tikk, Gabor Takacs, Istvan Pilaszy and Bottyan Nemeth. Investigation of Various Matrix Factorization Methods for Large Recommender Systems

Mathematicians and philosophers often make terrible programmers. They also tend to write gibberish even in English. (Ok, I do not know if it is a fact, but stay with me.)

A terrible way of programming is to try to hold the entire problem in your head and to put it into code in one shot. Why? Because you are almost certainly overestimating your brain. Your mind can only cope with few parameters at a time.

Here is how you have to program:

• If you have the luxury to start fresh, start small. Otherwise, make sure you understand and respect the code you start with.
• Identify specific changes you want to implement. Small changes! Then implement them. Then test them!

You should never redesign working software from the ground up without incremental testing. Never. Even if you work alone.

Interestingly, I also write my papers incrementally, fixing small things one after the other. No other way works for me.

CSS 3 is around the corner. Already we are seeing some benefits. The latest versions of Safari and Opera, as well as the beta version of Firefox allow you to select even or odd rows in a table using only CSS:


tr:nth-child(2n+1) {
background-color: blue;
}
tr:nth-child(2n) {
background-color: red;
}


See? No ECMAScript, no server-side programming. Alas, no sign of support for this in Internet Explorer.