Category: Science and Technology

Back in 2004, Tim O’Reilly observed that the Web had changed, and coined the term Web 2.0. This new Web is made of several layers which enable the Social Web. Wikipedia and Facebook are defining examples of the Social Web.

This sudden discovery of the Social Web feels wrong to me. In the early nineties, I was an active user of Bulletin Board Systems (BBS). While it was not the Web, or even part of the Internet, BBSes were clearly a social media. You know the multi-user games people play on Facebook? We had that back in 1990. The graphics were poorer, obviously, but it was all about meeting people.

The barrier to entry keeps getting lower, to the point were even grand-fathers are now on Facebook. But the Web has hardly been limited to an elite. Even BBSes were quite democratic: retired teachers would chat with young hackers all the time. It is the extreme low cost of computers and their ubiquity which makes the Social Web so widespread.

A much more interesting change has received less notice: the tempo of the Web is changing. Geocities made it easy for anyone to create a home page. But updating your home page was a slow process. In effect, our mental model of the Web was that of a library, and Web sites were books that could be updated from time to time. Eventually, we gave up on this model and decided to view the Web as a data stream. This realization changed everything.

The pace used to range from static web pages to flaming on posting boards. We have now expanded our temporal range. We can now communicate with high frequency in short bursts. Twitter is one extreme: it is akin to techno music. Facebook is somewhat slower, and more elaborate, maybe  like rock. Posting research articles is no music at all: it is akin to the rhythm of the Earth around the Sun. These tools don’t just differ on the frequency of the updates, but also on their volume, and on the length of the pauses.

Maybe we should try to understand the Web by analogy with music. How does the Web sound to you, today?

Further reading: See my blog post Is Map-Reduce obsolete? Also, be sure to check Venkatesh Rao’s blog. Rao has a new book which I will review in the future.

Many databases engines ensure consistency: at any given time, the database state is logically consistent. For example, even if you receive purchase requests by the thousands, you will always have an accurate count of how many products you have sold, and how many remain in stock. Accountants are especially concerned with consistency: they have invented techniques such as the double-entry systems to favor consistency. Inconsistencies cause problems:

• The user bought a product, a purchase record has been added, but the user account has not yet been charged. This could allow a user to buy more than he can afford.
• All items in stock have been sold, but a customer is being told that a few items remain in stock. Thus, a vendor could make sales it cannot fulfill.

Yet, in practice, requiring consistency means that your system will become unavailable from time to time. Thus, many NoSQL databases have adopted an eventual consistency approach. That is, while at any point in time the system might be logically inconsistent, it will eventually recover:

• The user account will  be charged prior to the delivery of the product.
• A customer who ordered a product that is no longer in stock will be told prior to finishing his order.

Even though it give headaches to the developers, eventual consistency is good enough. In any case, robust systems have to deal with exceptions. Even if your systems tell you that there enough items on stock, it could be that one item was damaged in the warehouse, or that another vendor is willing to quickly provide you with missing items. That is, at best, the data in your database is a logically consistent abstraction. But all non-trivial abstractions, to some degree, are leaky. And that is why we pay accountants: they chase down the leaks.

Maybe we should keep in mind that the largest, most powerful, information system ever designed is logically inconsistent: the Web is full of dangling and misdirected hyperlinks. And it would be extremely hard to debug the Web. Thankfully, we do not need to. My own Web site is probably filled with mistakes. I am sure that I link to pages that no longer exist. Still, it works. The cost of maintaining the integrity would be too high. The errors are acceptable.

As an analogy, security experts rarely try to fully secure systems. Instead, they identify components that must be secured, and they determine the risk tolerance. Complete security is simply too expensive in practice, unless you are willing to live in an isolated bunker.

Thus, maybe the solution will be to accept that information systems that are not even eventually consistent. If I run a business, all that matters to me is that my customers are happy, and I am making a healthy profit. Everything else is secondary. I might be willing to tolerate that some customers are never charged for an item they receive. I might be willing to slightly overstock on some items.

Sure, some might describe a not even eventually consistent system as an abomination, something impossible to program for… but the Web would have been described this way in the 1980s. The key is that the Web is not inconsistent in any random way: it has its own viable logic.

Further reading: The CALM Conjecture: Reasoning about Consistency

The programming language R is a standard for statisticians. And it is free software which runs on Windows, Mac and Linux.

You can learn much online about R, but if you prefer a bona fide book, there are also many to choose from. I just finished one of those: Statistical Analysis with R by John M. Quick.

The book is colorful and ludic which is a good idea for a “Beginner’s Guide”. The layout is attractive, there are many detailed examples. I like the pedagogy: the author wants you to learn by doing. However, the book is poor as a reference: the coverage is limited despite the 300 pages and the chapter summaries are strictly non-technical.

Overall this is a good book for people with no programming background who just want to use R to load data, do ANOVA tests and simple models. They will find step-by-step instructions down to the installation of the software, complete with screenshots of every step. This could be a good book for scientists or business people who want to try R as a substitute for Excel.

Disclosure: I got a free copy of the e-book from the publisher with the expectation that I would publish a review.

Is Open Source software better than closed-source software? Is Wikipedia better than Britannica? Is NoSQL better than Oracle and SQL Server? Are blogs better than corporate news services? Do patents favor innovation? Do long and painful funding applications help science? Is learning off Wikipedia and YouTube as good as learning in a classroom? Is duck typing good or bad?

All these questions are closely related to the concept of Innovation without permission: people innovate more when they do not have to ask permission.

Innovation without permission is analogous to Ridiculously Easy Group-Formation, popularized by Clay Shirky, but first proposed by my colleague Sébastien Paquet in 2002. Paquet’s message is that we are pushing the threshold for group creation to an unprecedented low.  In 2011, it is hard to disagree with Paquet: entire political movements come online together automatically.

Similarly, we are lowering the barriers to innovation to unprecedented lows:

• Open Source developers are probably no better than closed-source developers, but they typical produce their work without asking permission. Moreover, Open Source has gotten much easier over the years. Starting a project was relatively difficult in the nineties. Then sourceforge came along. Today, we have Github which is even easier. Using Github, people I never heard about, and never approved, submitted patches to some of my code without permission! Fantastic!
• When the era of personal computers arrived, a small team could publish a game, get it distributed through stores and sold to millions of people. Yet, last year, Markus Persson became a millionaire in a month by publishing an unfinished game as a Java applet from his web site (Minecraft). At each step in this process, the barrier to innovation becomes lower. First, you had to ask permission to the stores. Today, you can innovate and just post your work and, apparently, get paid very well for your effort.
• Many of the best-selling titles in the Amazon kindle store come from self-published authors. People write and sell books without asking permission to a publisher! They are also making more money than they used to.
• Wikipedia contributors and editors are no better than Britannica’s authors, but they mostly work without asking permission.
• NoSQL databases often allow developers to add new features without having to convince a DBA to change the database schema.
• Bloggers post without the approval of an editor.
• Duck Typing allows you to use a function that was meant for a different data type without having to ask for a change in the API.
• The barriers in scientific research has come down significantly. You can solve problems, post your solutions online and people might offer you a million dollar. It happened to Perelman. Increasingly, access to the literature is Open Access. Anyone can read the papers on PLoS and even contribute comments.

We can identify some barriers to innovation which are also great opportunities:

• Patents and copyright are first on my list. Much of the copyrighted content is easier to pirate than to license. Unsurprisingly, people do not ask permission and they violate copyright. A possible outcome is that all industries could become like the fashion industry where copyright is largely irrelevant.
• Funding remains a significant barrier to innovation.  The Kickstarter model is interesting in this respect.
• While I love web applications such as Google Mail, YouTube and Facebook, they won’t let their users redesign the product. You can post innovative content, but you cannot contribute (much) to the architecture of the application. Twitter is maybe the exception where users redefined Twitter by using tags and retweets, both design elements that were not present in the system initially. I am amazed that nobody has thought of creating a web application letting people program and distribute video games online. (If you implement this idea well and become a millionaire, please send me a check.)

I make my own yogourt because I cannot stand commercial yogourt. You can make your own yogourt in less than 30 minutes: heat milk to 112F (44C), mix in a small quantity of yogourt, leave the container of warm milk in a blanket overnight.

To minimize the labor I wanted a digital thermometer with an alarm set at 112F. Alas, most kitchen digital thermometers are designed for cooking meat. They can take intense heat, but exposure to milk shortens their life considerably.

Inspired by Frauenfelder’s Made by Hand, I decided to make my own programmable digital thermometer.

You can do it in an hour and for less than $80. You do not need any specific knowledge. A kid could do it.

You need to order:

• An Arduino board ($30). I have used an Uno Arduino.
• An LCD Keypad Shield ($24). I have used the DFRobot Shield.
• A ZX-Thermometer Temperature Sensor by INEX Robotics ($8). (Update: my tests show that its surface is lead-free.)
• You also need a USB cable to connect the Arduino to your computer, wires, a generic piezo element (as a buzzer) and a resistance. I recommend buying an Arduino Starter kit.
• You may also need a 9V battery and an adaptor to connect it to the Arduino board. You can get a 9V to 2.1mm Barrel Jack for $3.
• I have used a breadboard for convenience.

The assembly takes less than an hour (see my Picasa album for all the pictures).

1. Put the LCD shield on the Arduino.
2. Connect the thermometer on the analog port 2 (middle wire). Connect another wire to the 5V and another yet to ground. You need to add a resistance between the 5V and the thermometer.
3. Connect the piezo on digital 12. Don’t forget to ground one half of it.
4. Connect the Arduino to your computer by USB. Upload the program using the Arduino IDE. I have posted the C++ software on github. You can use Linux, Windows or a Mac to connect to the Arduino.

Operating the thermometer is easy. Give it some power. The display should come alive. Put the end of the black wire from the thermometer in your liquid. The up and down button control the target temperature. When it is reached, the piezo will play a bad rendition of Frère Jacques. Make sure you disconnect the battery once you are done to save power. This thermometer should work well for beer and yogourt making.

You can easily customize it by adding timers and several different target temperatures. Instead of a piezo element, you could use a voice synthesizer. Best of all, if the temperature sensor breaks, you only need to replace an $8 component.

Further reading: Arduino and Open hardware.

Disclosure: Though I link to RobotShop products, I am not affiliated with them in any way. The main Arduino web site has a list of Arduino distributors by country.

Code: Source code posted on my blog is available from a github repository.

For large data sets on disk, indexes are often essential. However, if your data fits in RAM, indexes are often unnecessary. They may even be harmful.

Consider a table made of 10,000,000 rows and 10 columns. Using normalization, you can replace each value by a 32-bit integer for a total of 381 MB. How long does it take to scan it all?

• When the data is on disk, it takes 0.5 s to scan the data. To maximize buffering, I have used a memory-mapped file.
• When the data is in memory, it takes 0.06 s.

Can you bring the 0.06 s figure down with an index? Maybe. But consider that :

• Indexes use memory, sometimes forcing you to store more data on disk.
• Indexes typically slow down construction and updates.
• Indexes typically only improve the performance of some queries. This is especially true with multidimensional data.

Verify my results: My Java code is available on paste.bin. I ran the tests on an iMac with an Intel Core i7 (2.8 GHz) processor.

Source: This blog post was motivated by a question from Julian Hyde, of Mondrian fame.

Further reading: Understanding what makes database indexes work

Code: Source code posted on my blog is available from a github repository.

In response to my Why do we need database joins? post, many readers stressed the importance of strict database schemas to preserve data integrity. In short, we want database administrators (DBA) to input constraints at design time so that the integrity of the database is insured no matter how lousy your programmers are. There is nothing a DBA hates more than having to recover a database from the backup tapes. And several businesses simply cannot afford to have their databases disrupted.

And really, businesses can be careless with their data. I have repeatedly seen businesses and public organizations hire students or recent graduates for 3 months so that they can add a feature or quickly build a web application. Every single time, I cringe. And almost every single time it ends badly. Managers shouldn’t mess with software and data without real professionals. Alas, the bad ones often do. In such a context, we need DBAs to protect the data, to keep the useful applications running.

So, unsurprisingly, we keep hearing that NoSQL databases fail to get any traction in large organizations. Is this a surprise? NoSQL tends to do away with schemas. It gives a lot more power to the programmer. More power to screw up as well. So,  we are getting at the heart of the matter. NoSQL is not meant for DBAs. In fact, it is a coup against DBAs:

NoSQL is for programmers. This is a developer led coup. The response to a database problem can’t always be to hire a really knowledgeable DBA, get your schema right, denormalize a little, etc., programmers would prefer a system that they can make work for themselves.

In effect, NoSQL developers are working to make DBAs less relevant (or even irrelevant). And, if history is our guide, they will succeed. I wouldn’t be surprised if in ten years, we declared database administration to be an obsolete occupation. The software will protect the data better than any DBA ever could. This revolution, however, cannot come from the vendors who sell to DBAs. We must have disruptive innovation. And this is exactly what NoSQL is.

Note: I have nothing against DBAs. I expect to be obsolete myself by 2020. (And hopefully, I’ll find a way to retire early.)

In a recent post, I argued that the current NoSQL trend could be called NoJoin. My argument boils down to the fact that SQL entices you to normalize your data which creates complicated schemas. Meanwhile, NoSQL database systems use simple schemas and are therefore easier to scale out.

Curt Monash has a reasonable post where he points out that we need joins because we normalize. Furthermore, he offers reasons for normalization:

• To simplify the programming of the updates. Simply put, if the string “Montreal” appears once in your database, and the city changes its name, it is trivial to do the update. This applies mostly when you have complex schemas.
• For faster updates. Updating a single entry in a database is much faster than searching and updating for all occurrences of the value “Montreal”. This is mostly applicable when you have large update volumes.

However, the case against joins is also strong:

• Normalization makes your schemas complex. I have seen university databases made of hundreds of tables. The average query is well over 256 characters and involves dozens of joins. It is simply impossible to make sense of the content of any one table. Building new applications on top of this mess is expensive and bug prone. Complexity is bad for your health.
• Database engines can compress the data automagically so normalization to save space is a waste of time.

The dogma of normalization too often leads to over-engineering. We are so afraid that a programming error could leave the database in a wrongful state that we invest massively in inflexible schemas. In turn, this over-engineering comes back to haunt us when we need to be more agile, or to scale out.

Example:

Suppose you want to design a database of research papers. Let us simplify the problem by omitting the paper identifiers, the dates, and so on. Let us also assume that there is only one author per paper. Maybe your main table looks like this:

Being helpful, your friendly database expert points out that your database schema is not even in the second normal form. Clearly, you are an amateur. Being helpful, he creates a secondary table which maps the authorID field to an author name. And voilà! You have saved storage, and won’t ever get someone’s name wrong. Updates to someone’s name will be much faster in the future.

But wait?!? What if Nathalie gets married and changes name? And indeed, people have their names changed all the time. Yet, we never retroactively change the names of the authors on a paper. Maybe you never thought about it, but many ladies hold two or more names in their lifetime. Did the bunch of guys in IT knew about this? (As an aside, are the digital librarians worried at all about researchers changing name and seeing their publication list cut in half? Yes: See update below.)

My point is that normalization effectively enforces dependencies decided upon when you created the schema. These envisioned dependencies break down all the time. Life is complicated. I could come up with hundreds of examples. Strict normalization makes as much sense as the waterfall model.

What about the physical layer? Because normalization has removed entire fields from the main table, you might think that normalization will save storage! That may well be true in the database engine you are using. However, other database engines will automatically detect the dependencies and compress the data accordingly. In this case, it is trivial to discover that there  is a bijective (1-to-1) mapping between author ID and author name. And if the bijectivity breaks down, the database engine will simply have to work a bit harder to compress the data. Your code won’t break down. It won’t need to be retested. (To be fair, I don’t know if any database system gets this right.)

Update: Apparently, Otfried Cheong—a Computer Science professor in Korea—once published as Otfried Schwarzkopf. At least, the two names are merged on DBLP. It suggests that DBLP can cope with researchers changing their name.

When I took my current position, I was invited to teach a course on unstructured data. It is a sensible topic for a course: some say that between 80% to 90% of all enterprise data is unstructured. But I objected to the title for marketing reasons. How many students would take a course on unstructured data? I can hear the students asking “what’s that course about?” Thus, I proposed a better title for the course: information retrieval and filtering. Indeed, everyone wants to filter and retrieve data, right?

Meanwhile, there were already courses on structured data (that is, on databases and information systems). However, there was no course on semi-structured data. So I proposed one. But I couldn’t call it semi-structured data as hardly any student would know what the title meant. Instead, I proposed a course which, roughly translated, is called “Information Management with XML.”

Immediately, I got into trouble: how could I dare omit  SOAP and web services from a course on XML? I was annoyed by these comments. With some sense of irony, I decided to start dumping on my students some SOAP examples so that they could see the “beauty” [I’m being ironic] of using XML for data exchange on the web. So, there I was, trying to teach my students about semi-structured data, and I was asked to tell them about remote procedure calls, an irrelevant topic for my purposes.

Thankfully, it appears that history is on my side. Developers got tired of getting these annoying XML payloads. In time, they  started using JSON, a much more appropriate format for passing small loads of structured data between a server and an ECMAScript client. It uses fewer bytes and, more importantly, JSON is an order of magnitude faster than XML. When you ask on Stack Overflow whether you should be using SOAP you are being told to avoid SOAP at all costs. The developers have spoken. And as a result, the organization behind the SOAP stack decided to close shop.

Where does that leave XML at? Precisely where it started. XML is a great meta-example on how to deal with semi-structured data. And it is just as useful as ever. Want to deal with documents? DocBook and OpenDocument are great formats. Want to add semantic information to web pages? Microformats can do it. You want to exchange complex business data? The Universal Business Language probably does what you need. Some people are having luck with the SVG image format. You want to subscribe to my blog? Grab my atom feed. For these applications, you couldn’t easily replace XML by flat files or JSON. Nor should you try.

Alas, we ended up torturing XML by applying it to ill-suited purposes. We must learn how to select the best format. Does your data look like a table? Can a flat file do the job? Do you need a key-value format like JSON? Or maybe a simple text file? Or is your data more like an XML document? Take a good look at your data before picking a format for it.

Further reading: Indexing XML and Native XML databases: have they taken the world over yet?

Update: I don’t include configuration files in my list of proper XML applications.

Matt Cutts is Google’s search engine optimization expert. He runs a great YouTube channel called Google Webmaster Central. He was recently asked how Google handles special characters such as ligatures, soft hyphens, interpuncts and hyphenation points. His answer? He doesn’t know.

Being a scientist, I decided to compare Google to the young upstart (Bing).  Using Google, the result sets from Kurt Goedel differ from those with Kurt Gödel. For example, I could only find the Kurt Goedel article from the uncyclopedia when searching for Kurt Goedel. Similarly, Google fails to realize that cœur and coeur are the same words. However, Bing knows that Goedel and Gödel is the same person. Bing knows that cœur and coeur is the same word.

While the consequences are small, they are nevertheless real:

• Students may fail to find great references on Kurt Gödel because they search for Kurt Goedel. Indeed, most academic papers seem to prefer Gödel to Goedel.
• A writer who tries to be typographically correct and writes cÅ“ur may get penalized when people search for coeur.

Score: Bing 1. Google 0.

Source: Will Fitzgerald. Special thanks to Mark Reid, Marek Krajewski, Jeff Erickson and Christer Ericson for the debate on Twitter motivating this blog post.

It is not 9am yet. Nevertheless, I got a lot done:

• I attended the thesis proposal of my student Eduardo via Skype. I was literally in my basement with a fresh cup of coffee, attending a presentation hundreds of kilometers away. Beside myself, there were professors from two different cities attending.
• I watched a recorded concert of the latest Japanese rockstar, Hatsune Miku, on YouTube. Oh! And she is a synthetic character.
• I read my morning news on my Star Trek-like iPad. I received my news from a hand-picked lot of 50 or so people worldwide. It has been months since I last read a newspaper.

Though I tried to convince my wife that the future has finally arrived, she insists that we always live in the present.

Well. Some people certainly insist on living in the past:

• Canada’s largest science funding agency (NSERC) sent me a funding proposal to review. They had to send it to me on paper, by mail. The file has dozens of pages. I had to carry it home. I will have to find a way to recycle it after shredding it. What is wrong with giving me access to a PDF or HTML copy of the proposal? Can’t the person in charge of printing the proposal find another occupation?
• Even though I have not had to look up a research article on physical paper in nearly a decade, a leading journal asked me to include page numbers in all my references. But these page numbers only make sense if you are holding the physical copy of the journal. Why would anyone look up articles from the physical copy when they can find and download research papers in seconds? I’m even told that graduate students in several schools are trained in how to use a (physical) library to look up references. Oh! The pain! Why do librarians insist on teaching obsolete skills? There is no shortage of useful skills a librarian could teach students in 2010. Indeed, I am amazed at how little most graduate students know about tracking research papers online.
• My employer still sends me, every two weeks, a little enveloppe with a single paper in it which tells me how much money they put into my bank account. Of course, I know exactly what this amount is, as I can see it listed through online banking. So what is the point of this piece of paper? Create employment at a local printing press? Tracking pieces of paper is time consuming. Worse: the information is incomplete, even incomprehensible at times because of the  lack of physical space on the paper. Why can’t Human Resources setup a web site where I could get all the information I need to understand all the mysterious deductions appearing on my fake pay check? Why must they insist on printing useless pieces of paper? Why can’t they provide useful and modern tools instead?

Source: The title of my post is a quote from William Gibson.

Suppose that you have 10 pictures, and all lined up, they take 100 pixels. Is it safe to say that each picture has a width of x pixels if 10 x = 100?

We all know that a x = b has a unique solution x as long as a is non-zero. If you work with integers, then you can say that there is at most one solution.

Unfortunately, computer arithmetic is uglier. Over 32-bit integers, the equation a x= 0 has 2³¹ solutions if a = 2³¹. Indeed, as long as x is even, 2³¹ x = 0.

But notice how I had to choose a large value of a to make computer arithmetic look bad. What if a is small? Certainly, if a = 1, then there is exactly one solution. If a = 2, then there are at most two solutions: 2 x can take any odd even and the most significant bit of x is discarded.

We can generalize this result a bit: if a = 2^L, then there are at most 2^L solutions x.

But we can generalize it even further! We have that a x = b has at most 2^L integer solutions x if a is an L-bit non-zero integer. That is, as long as a is small, then a x = b has few solutions. The proof is technical, but not difficult:

Proof (Sketch). Let a is an L-bit non-zero integer and suppose we work with K-bit arithmetic. We consider the equation a x div 2^L = b modulo 2^{K – L}. Let j be the first non-zero bit of a. E.g., if a = 7 then j = 1. Because a_i = 0 for i < j, we have that the value of a x 2^L is independent of the last j -1 bits of x. Moreover, we have that the most significant bit of x which matters (x_K-j+1) only matters for the last bit of a x. We can solve for this last effectual bit x_K-j+1 in (ax)_K = b_K-L as a function of b_K-L, a and the lesser bits of x. We can continue solving for the lesser bits of x by consider a x = b minus the last bit. (In effect, we have reduced the problem in an integer ring with K bits to a similar problem in integer ring with K-1 bits.) After K-L steps, the process terminates (K=L) leaving L bits in x that can be set freely generating 2^L different solutions. QED

Getting back to our orignal problem: Because the integer 10 can be written using 4 bits (0b1010), the equation 10 x = 100 has at most 2⁴ = 16 solutions. So if x was just picked at random, chances are good that the assertion would fail: for 32-bit integers, the probability of a false positive is at most 15/2³² which is much, much less than 1%.

Further reading: M. Dietzfelbinger, Universal hashing and k-wise independent random variables via integer arithmetic without primes, in: STACS’96, 1996.

Earlier, I asked whether integer addition was faster than bitwise exclusive or. My tests showed no difference, and nobody contradicted me.

However, everyone knows that multiplication is slower than addition? Right? In cryptography, there are many papers on how to trade multiplications for additions, to speed up software.

So? Can you predict which piece of code runs faster?

scalar product (N multiplications):

for(int k =0; k < N ; ++k)
answer += vector1[k] * vector2[k];


scalar product two-by-two (N multiplications):
for(int k =0; k < N ; k+=2)
answer += vector1[k] * vector2[k]
+vector1[k+1] * vector2[k+1];

non-standard scalar product (N/2 multiplications):
for(int k =0; k < N ; k+=2)
answer += ( vector1[k] + vector2[k] )
* ( vector1[k+1] + vector2[k+1] );


just additions (no multiplication):
for(int k =0; k < N ; ++k)
answer += vector1[k] + vector2[k];


Answer: Merely reducing the number of multiplications has no benefit, in these tests. Hence, simple computational cost models (such as counting the number of multiplications) may not hold on modern superscalar processors.

My results using GNU GCC 4.2.1 on both a desktop and a laptop:

Times are in seconds. The source code is available without pointer arithmetics. The same test with pointer arithmetics gives faster results, but the same conclusion. I tried a similar experiment in Java. It confirms my result.

Code: Source code posted on my blog is available from a github repository.