Python is a programming language that I learnt somewhat recently (something like 2, 3 years ago) and that I like very much. It is simple, to the point, and has several functional-like constructs that I am already familiar with. But Python is slow compared to other programming languages. But it was unclear to me just how slow Python was compared to other languages. It just felt slow.

So I have decided to investigate by comparing the implementation of a simple, compute-bound problem, the eight queens puzzle generalized to any board dimensions. This puzzle is most easily solved using, as Dijkstra did, a depth-first backtracking program, using bitmaps to test rapidly whether or not a square is free of attack¹. I implemented the same program in C++, Python, and Bash, and got help from friends for the C# and Java versions². I then compared the resulting speeds.

The eight queens puzzle consist in finding a way to place 8 queens on a 8×8 chessboard so that none of the queen checks another queen. By “checking”, we mean that if the other queen was of the opposing camp, you could capture it if it were your turn to play. So this means that no queen is on the same row, column, or diagonal as another queen. Using a real chessboard and pawns in lieu of queens, you can easily find a solution in a few seconds. Now, to make things more interesting, we might be interested in enumerating all solutions (and, for the time being, neglecting to check if a solution is a rotated or mirrored version of another solution).

The basic algorithm to solve the Eight queens puzzle is a relatively simple recursive algorithm. First, we place a queen somewhere on the first row and we mark the row it occupies as menaced. We also do so with the column and two diagonals. We then try to place a second queen somewhere on the second row, on a square that is menace-free, and mark the row, column, and diagonals of the new queen as menaced. And we proceed in the same fashion for other queens. But suppose that at the th stage, we cannot find a menace-free square, preventing us from placing the th queen. If the situation arises, we give up for the th queen and backtrack to the th queen. We try a new (and never tried before) location for the th queen and we go forth trying to place the th queen. If may happen that we go all the way back to the th queen because there are no other solutions for the th queen, which asks for the th queen to be moved, which can also result in a dead-end; and so forth all the way down to the th queen.

Because the algorithm proceeds depth-first and can rear back quite a bit in looking for new solutions, it is called a backtracking algorithm. Backtracking algorithms are key to many artificial intelligence systems like, well, chess programs.

So I wrote the program for the queens puzzle for a board in C quite sometime ago (circa 1995), then I ported to C++ recently (2006). And just for kicks, I decided to port it to different languages, with help from friends for Java and C# (of which I know about zilch). The C++ versions consist in a generic version that accepts the board size as a command-line argument and in a constant-propagated version where the board size is determined at compile-time. The Python versions, as there are two of them also, differ on how python-esque they are. The first variant is a rather literal translation of the C++ program. The second uses pythonesque idioms such as sets rather than bitmaps and turns out to be quite a bit faster—about 40% faster in fact. The Bash version is necessarily rather bash-esque as Bash does not offer anything much more sophisticated than arrays in terms of data structures.

All implementations were compiled with all optimizations enabled (-O3, inlining, interprocedural optimizations, etc.). For C++, I used g++ 4.2.4, for C#, gmcs 1.2.6.0, for Java, gcj 4.2.4, Python 2.6.2, and, finally, Bash 3.2.39—all latest versions for Ubuntu 8.04 LTS, which doesn’t means that they’re the really latest versions.

So I ran all seven implementations with boards sizes ranging from 1 to 15 on a AMD64 4000+ CPU (the numbers are arbitrary; I wanted to get good data but also limit the CPU time spent as the time increases factorially in board size!). At first, the results are not very informative:

Results, Time, Linear Scale

As expected, all times shoot up quite fast, with, unsurprisingly, BASH shooting up faster, followed by the two Python implementations. At this scale, Java, C#, C++, C++-fixed (the constant-propagated version) all seems to be more or less similar. To remove the factorial growth (as even with a log plot the data remains rather unclear), I scaled all performances relative to the C++ version. The C++ version is therefore 1.0 regardless of actual run-time; for board size , the time needed by Bash, for example, was divided by the time needed by C++ for board size . We now get:

Speed Ratio, Linear Scale

We can use a log-scale for the axis to better separate the similar results:

Speed Ratio, Log Scale

We see three very strange things. The first is Bash shooting up wildly. The second is that C# relative time goes down with the increasing board size. The third is that before , the results are fluctuating. The first is easily explained: Bash is incredibly slow. About 10,000 times as slow as the optimized compiled C++ version. It is so slow that the two last data points are estimated as it would have taken an extra week, or so, to get them. The second anomaly needs a bit more analysis. Looking at the raw timing data, we can see that the C# version seems to be needing an extra 7ms regardless of board size. I do not know where that comes from, as the timings do not time things such as program load and initialization, but only the solving of the puzzle itself. It may well be the JIT that takes a while to figure out that the recursive function is expensive and the run-time compilation takes 7ms? Anyway, would we remove this mysterious extra 7ms, the odd behaviour of the C# implementation would vanish. The third anomaly is easily explained by the granularity of the timer and the operating system; up to puzzle size of 8, the times are much less than 100 μs for most implementations. Suffice to move the mouse and generate a couple of interrupts to throw timing off considerably.

Removing the small board sizes yields:

Speed Ratios, Log Scale, Without Outliers

which shows that the respective implementations are well behaved (except for C# and its most probably JIT-related extra 7ms).

So we see that Bash is about 10,000 times slower than the optimized C++ version. The constant-propagated version is only a bit (~5%) faster than the generic C++ version. The Java version takes about 1.5× the time of the C++ version, which is way better than I expected—don’t forget that this is a native-code version of the Java program, it doesn’t run on the JVM. The C# version is twice as slow as the C++ version, which is somewhat disappointing but not terribly so. The Python versions are 120× (for the more pythonesque version) and 200× slower. That’s unacceptably slow, especially that the Python programs aren’t particularly fancy nor complex. We do see that using pythonesque idioms yields a nice performance improvement—40%—but that’s still nowhere useful.

*
* *

So what does this tell us? For one thing, that Bash is slow. But that Bash is slow even when it doesn’t use any external command should not come as a surprise. From what I understand from Bash, data structures are limited to strings and arrays. Lists and strings are the same. Basically, a list is merely a string with items separated by the IFS character(s), which causes all array-like accesses to lists to be performed in linear time as each time the string is reinterpreted given the current IFS. So even though a construct such as ${x[i]} looks like random-access, it is not. As for explicitly constructed arrays (as opposed to lists), there seems to be a real random-access capability, but it’s still very slow. I do not think that bash uses something like a virtual machine and an internal tokenizer to speed up script interpretation. Maybe that’d be something to put on the to-do list for Bash 5? In any case, I also learnt that Bash is a lot more generic than I thought.

The other thing is that Python is not a programming language for compute-bound problems. This makes me question how far projects such as Pygame (which aims at developing a cromulent gaming framework for Python) can go. While all of the graphics and sound processing can be off-loaded to third party libraries written in C or assembly language and interacting with the platform-specific drivers, the central problem of driving the game itself remains complete. How do you provide strong non-player characters/opponents when everything is 100× slower than the equivalent C or C++ program? What about strategy games? How can you build a MMORPG with a Python engine? Is a MMORPG I/O or compute bound? Could you write a championship-grade chess engine in Python?

My guess is that you just can’t.

And that’s quite sad because I like Python as a programming language. I used it in a number of (I/O-bound) mini-projects and I was each time delighted with the ease of coding compared to C or C++ (for those specific tasks). It pains me that Python is just too slow to be of any use whatsoever in scientific/high-performance computing. I wish for Python 4 to have a new virtual machine and interpreter to bring Python back with Java and C#, performance-wise. Better yet, why not have a true native compiler like gcj for Python?

*
* *

I am fully aware that the queens on a board puzzle is a toy problem of sorts. But its extreme simplicity and its somewhat universal backtracking structure makes it an especially adequate toy problem. If a language can’t handle such a simple problem very well, how can we expect it to be able to scale to much more complex problems like, say, a championship-level chess engine?

*
* *

The raw data (do not forget that the two last timings for Bash are estimated). All times are in seconds.

The More Pythonesque version:

#!/usr/bin/python -O
# -*- coding: utf-8 -*-

import sys
import time

########################################
##
##   (c) 2009 Steven Pigeon (pythonesque version)
##

diag45=set()
diag135=set()
cols=set()
solutions=0

########################################
##
## Marks occupancy
##
def mark(k,j):
    global cols, diag45, diag135
    cols.add(j);
    diag135.add(j+k)
    diag45.add(32+j-k)

########################################
##
## unmarks occupancy
##
def unmark(k,j):
    global cols, diag45, diag135
    cols.remove(j);
    diag135.remove(j+k)
    diag45.remove(32+j-k)

########################################
##
## Tests if a square is menaced
##
def test(k,j):
    global cols, diag45, diag135
    return not((j in cols) or \
        ((j+k) in diag135) or \
        ((32+j-k) in diag45))

########################################
##
## Backtracking solver
##
def solve( niv, dx ):
    global solutions, nodes
    if niv > 0 :
        for i in xrange(0,dx):
            if test(niv,i) == True:
                mark ( niv, i )
                solve( niv-1, dx)
                unmark ( niv, i )
    else:
        for i in xrange(0,dx):
            if (test(0,i) == True):
                solutions += 1

########################################
##
## usage message
##
def usage( progname ):
    print "usage: ", progname, " <size>"
    print "size must be 1..32"

########################################
##
## c/c++-style main function
##
def main():
    if len(sys.argv) < 2:
        usage(sys.argv[0])
    else:
        try:
            size = int(sys.argv[1])
        except:
            usage(sys.argv[0])
            return

        if (size <= 32) & (size>0):

            start = time.time()
            solve(size-1,size)
            elapsed = time.time()-start

            print "%s %0.6f" % (solutions,elapsed)

        else:
            usage(sys.argv[0])
#
if __name__ == "__main__":
    main()

The other versions can be found here in super_reines.zip. The Bash and C++ versions are somewhat Linux-specific.

² Frédéric Marceau translated the program from C++ to C#. François-Denis Gonthier translated from C++ to Java.

*
* *

So I added a third Python version to the archive. I also benchmarked it. It is quite a bit faster than the original one, and even than the ‘pythonesque’ version. For example:

$ super-reines.py 12
14200 15.966019
$ super-reines-2.py 12
14200 9.478235
$ super-reines-3.py 12
14200 6.845071

So a more ‘functional’ version performs about 2.3× faster than a direct translation from C++. For the same problem size, however, the C++ (fixed) version takes 0.069s… Roughly 100× faster than the 3rd version.

Speed Ratios, Log Scale, Without Outliers, with 3rd Python version

Very often, you have to keep an eye on a log, or maybe more than one log, and a couple of other things while a long-term simulation is running. The GNU/Linux distributions offer the program watch that allows the periodical execution of a command in the current interactive shell. While watch is convenient, you still have the problem of displaying the needed information in a terminal geometry aware way. Turns out, there are tools to query the terminal geometry and we can use them to write simple, effective, well displayed scripts.

So let us see how we can make BASH somewhat aware of the terminal it runs in.

The first command we will look at is stty. Traditionally, stty is used to set the various terminal’s parameters, but for now, we are interested in its parameter reporting capabilities. Invoking stty -a will output the current terminal’s settings (use the view plain option as WordPress messes up the formating a bit):

.../somewhere/>stty -a
stty -a
speed 38400 baud; rows 29; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff
-iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt
echoctl echoke

So it seems to be reporting all needed information, including some obsolete or unneeded information (such as the terminal’s baud-rate for a terminal running on the console in graphics mode). But like most commands, it has its peculiarities. From the above, we may gather that the parameters are separated by semicolons (;) and that new lines are inserted so to more or less separate parameter categories. But if we resize the window to a very weird shape, like a very narrow, very high window, we see that the newlines change places! The first step to extract the information from stty -a is to get rid of the newlines altogether, using the tr command, replacing newlines ($'\n') by spaces:

.../somewhere/>stty -a | tr $'\n' ' '
speed 38400 baud; rows 29; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop

Fields are fortunately separated by semicolons. Adding:

.../somewhere/>stty -a | tr $'\n' ' ' | cut -d\; -f 2-3
 rows 29; columns 80

So we’re almost done. Now, let us extract the numbers only:

.../somewhere/>stty -a | tr $'\n' ' ' | cut -d\; -f 2-3 | tr -c [0-9] ' '
      29          80

which we wrap in a BASH array:

.../somewhere/> (z=($(stty -a | tr $'\n' ' ' | cut -d\; -f 2-3 | tr -c [0-9] ' ')); echo ${z[@]} )
29 80

Using this in a script lets us get the dimensions of the terminal in characters:

#!/bin/bash

# get the rows and columns
# in the current window
#
res=($( stty -a |\
        tr $'\n' ' ' |\
        cut -d\; -f 2-3 |\
        tr -c [0-9] ' '\
    ))

cols=${res[1]}
rows=${res[0]}

Now, what we have to do is to use the known size of the terminal ($cols and $rows) for pretty-displaying a log and, say, the used disk space. Let the file watch-log contain:

#!/bin/bash

# get the rows and columns
# in the current window
#
res=($( stty -a |\
        tr $'\n' ' ' |\
        cut -d\; -f 2-3 |\
        tr -c [0-9] ' '\
    ))

cols=${res[1]}
rows=${res[0]}

# du will use du_rows rows
du_rows=$( du -h | wc -l )

# the normal log will take
# what's left (after du,
# watch, and maybe a trailing
# white line)
log_rows=$((rows-du_rows-6))

# check if the number of log rows
# is positive, at least, and if the
# terminal is wide enough
#
if [[ $log_rows -gt 0 && $cols -ge 20 ]]
then
    echo "Space Used:"
    du -h
    echo
    echo "Log Tail:"

    # here, add your own stuff to
    # watch over
    #
    tail -n $log_rows watched.log | cut -b -${cols}
    exit 0 # success!
else
    echo "window too small for watching!"
    exit 1
fi

We invoke watch-log through watch. The actual frequency that suits you best is up to you, but to get an update every second, you would invoke: watch -n 1 watch-log. Now, resizing the window produces a seamless update of the information.

*
* *

Working with cut, sed and tr is alien at first, but they will prove most useful in basic or advanced scripting. Here, we used two of them to extract and use the terminal’s resolution (in characters). Another thing that we could have done to beautify the script is to use colors, but I personally think they’re best used in moderation. Maybe we could display the result of du in red should the used disk space exceed, say, 1GB or some other convenient limit, but I will leave that to you.

This week, I’m talking you about a little identity that crops up often in the study of algorithms and which isn’t found in formula compendia—anyway, none that I have. I’m talking about this function:

This is a variation on the Gabriel’s Staircase function that does not have an infinite number of terms. Let us solve it without supposing that .

Let’s warm up by solving a similar function (which will be instrumental later on), the sum . This is known as the geometric series. Put:

and

Let us combine the two:

This is a telescoping sum and terms mostly cancel each other out:

and finally:

There, we’re done for this one. Reversing into is allowed because we multiply both the numerator and the denominator by (thus the whole expression by , so it doesn’t change its value).

Now, back to our main concern, the truncated staircase. Put:

and

So you’re guessing right, we’ll use the same overall trick as we did for the geometric series. Quite so!

then

After much pericombobulations, we, at last, get our solution:

*
* *

Despite all the work, only basic algebra is needed to obtain the desired expression, and, well, a lot of patience. We also note that a difficulty arises when . The denominator is zero, which is bad. But fortunately, is 1, so we have:

which is a sum you should already know:

*
* *

A few friends of mine decided to return to school—well, the university, that is. And all of them have to take (or retake) math classes to enroll in their programs. They’re not all at the same level, but they’re quite decided and working hard to get there. However, I do hear complaints now and then and it’s mostly about how bad introductory-level textbooks are. In one book my friend Vincent showed me, a suddenly becomes a , altering the derivation of the solution in ways that are more tragic than funny. I guess college-level textbooks do not all get that much of a scrutiny before release.

Another complaint I hear is how things are derived. While it may be perfectly acceptable in an advanced textbook to simply state that and move on as you expect your readers to be able to take 5 or 10 minutes to obtain the result by themselves, that’s not something you can do too often in an introductory- or college-level textbook because, guess what, you’re teaching math to people that may not know enough math to know beforehand what’re you’re trying to teach them. Wait, what?

Clear, step by step, derivations of equations are sometimes necessary, and not always for college-level textbooks. Some authors are notoriously vague in derivation. Sentences like “it naturally follows” are proverbially antinomic.

The only difference between coding styles and religion discussions is that coding styles have claimed fewer victims—at least until now. A few post back I discussed color schemes, and this week I’ll be discussing code geometry for enhanced clarity.

A few days back I was discussing with a friend whether or not comments in code should be rather narrow, spread vertically in short lines, or if they rather should be “line long”, that is, about 70 or so, characters wide. He agreed that short comments broken in many lines are easier to read than very long lines. A coworker came to the opposite conclusion: short, broken comments were “stocky”. Of course, like other style matters, that is ultimately to everyone’s own taste; but I wasn’t sure why I found them much easier to read.

My personal theory is that eye movement is minimized with short lines. There’s a certain vision angle in which we seem to be able to just grab a bunch of letters without really scanning them. This angle is not very wide—maybe 5°—and very long lines forces us to scan text jumping over every few words. That’s probably why newspaper, blog templates, and scientific journal all use multiple and rather narrow columns: one can read while essentially scanning the text downward only.

Let us look a piece of code I wrote recently (what it does is somewhat irrelevant right now; let’s say it’s an extra goodie). In my default EMACS view (80×60-something) the code appears:

Using GIMP I illustrated (“artist conception”) the path my eyes take when I read the text:

Now, what would it look like if I used long lines instead? The code would now look like this:

and I suppose my eyes would scan the text like this:

So I think I may improve code legibility quite a lot just by keeping moderately short lines for comments and code. This also implies that indentation must also remain rather shallow—except possibly for Python. Tabs that are 4 space wide now seems too long and indentation too deep. I use a 1 or 2 space variable width tab, as you can see from the above screenshots (I spent some time to tweak EMACS’s CC mode to get that particular setting).

*
* *

Bonus technique for EMACSers: the fill-paragraph-function packs text in a mode-dependant way using the variable fill-column that delimits the maximum number of columns in a line. It is bound to M-q by default. Pressing M-q will cause a paragraph to pack itself in lines of at most fill-column characters. It also behaves correctly in most modes (it understands comments).

Programmers aren’t always the very rational beings they please themselves to believe. Very often, we close our eyes and take decisions based on what we think we know, and based on what have been told by more or less reliable sources. Such as, for example, taking red-black trees rather than AVL trees because they are faster, while not being able to quite justify in the details why it must be so. Programming using this kind of decision I call cargo cult programming.

Originally, I wanted to talk about red-black vs. AVL trees and how they compare, but I’ll rather talk about the STL std::map that is implemented using red-black trees with G++ 4.2, and std::unordered_map, a hash-table based container introduced in TR1.

TR1 std::unordered_map is a map that does not maintain any particular order between the keys of the data it contains. It is therefore implemented as a hash table. The std::map is implemented, at least in G++ 4.2, as a red-black tree. Self-balancing trees change their shape with each insertion in order to maintain most leaves at an equal depth, ensuring an access time. The difference between an AVL tree and a red-black tree is the way the tree is rebalanced, and the red-black tree does about half as much operations as an AVL tree on insertion, making somewhat faster—how much faster remains to be quantified.

So I ran a few simple experiments to compare std::unordered_map and std::map. First, I got hold of the Zingarelli word list, containing some 585,000 Italian words (I can’t find a working URL, but I got the list a few years ago on a Scrabble-related page). I ran three tests: insertion, successful search, and failed search. The list is broken into two parts, one containing 90% of the words, to be inserted, and 10% of the words where kept for the unsuccessful search test.

The insertion test consisted into inserting all of Zingarelli’s list into both data structures, in the most simplistic way: scanning the list sequentially and inserting items one by one.

Insertion times are about the same; so we cannot conclude anything special here except maybe that the insertion time is largely dominated by memory allocation and copy. For the successful search (10,000 tries in each case):

Map look-up is immensely faster with std::unordered_map, a ratio of about 8:1! Failed searches exhibit the same behavior. For ~60,000 failed searches:

We see the same kind of differences here again, but the failed searches are much slower than the successful searches.

When we repeat the experiment with integers (with the same kind of numbers; 500,000 integers of which 10% are randomly chosen for the failed searches), we get essentially the same picture but a massive speedup as strings are rather costly to copy. Indeed, for the insertion:

Now, we see the algorithmic difference between the two algorithms as the time spent allocating and copying strings is eliminated. For successful and failed searches, we get (again for 10,000 look-ups):

and:

The std::unordered_map therefore seems to be much faster than std::map. What have we lost in order to gain this speed? First, a lot of memory as hash table must retain a certain sparseness to sport their average constant-time look-ups; and the ordering of keys. Listing the items sorted in a hash map won’t produce an ordered list, but rather a randomized version of the list. std::map on the other hand, allow lexicographic enumeration of its contents.

*
* *

So you’re reading this and are thinking, mmppfh, of course, it’s a hash table, you nitwit. Well, yes. Maybe so.

But here’s what prompted me to do the test. Red-black trees offer access. But that’s assuming (and quite wrongly) that comparing keys can be performed in constant time. This may be true for simple keys, such as machine-size integers (known in C and C++ as int) but not so for more complex data, like strings and other structures. For string, for example, comparison may still be very fast because the cost of comparing two string only depends on the longest common prefix; if two long strings have differences in the first few characters, comparison terminates rapidly and the cost is moderate. If, on the other hand, the string share a very long prefix, then the comparison algorithm must scan both strings until the end is reached or a difference is found; this can be very long. So, lets be the average common prefix length. The expected search time is now which can grow large if is large.

For a hash table look-up, you must first compute the hash key which can be at best done in linear time in the average key length. In our first case, this length is the average string length. Let this average length be . The number of probe is a small constant that depends on the sparseness of the table and the number of items, , it contains. For each of those probes, a string comparison is performed, leading to an expected complexity of .

Now, it is not clear when . Both cancel, which boils down to . So, in some conditions, it may be possible to make the tree appear faster than the hash table.

On the average, however, the hash map should win becase we expect .

*
* *

A cargo cult is described as:

A cargo cult is a type of religious practice that may appear in primitive tribal societies in the wake of interaction with technologically advanced, non-native cultures. The cults are focused on obtaining the material wealth of the advanced culture through magical thinking, religious rituals and practices, believing that the wealth was intended for them by their deities and ancestors.

Except from the part with ancestor spirits but especially when considering magical thinking, cargo culting applies very often to how programmers write code and take decisions about data structures and algorithms. Choosing a red-black tree over an AVL, or over a splay tree, because we think that it is somehow always better—sometimes because Ancestor X (a more or less reliable source or authority, such as a more experience programmer, a teacher, or some Internet dude) said so—is a form of cargo cult where the programmer does not use rationality to its full extent to make a decision.

When choosing data structures, one must be fully aware of the dual cost of data structures. The first cost is the run-time cost. Theoretical complexity and actual implementation-dependant run-times may be quite different. The second cost is memory usage. Memory is large on modern systems but not infinite. A particularly wasteful method that offers constant-time access to the data may use as much as, say, ten times the memory used by a method that gives you access. If for small data set this 10× memory usage pose no particular problem, it may be quite different with a largish data set. It’s all a very delicate balancing act between run-time performance and scalability.

It’s very hard to trust one’s gut feelings about a data structure and the data put in. Combined with the access patterns, the data structure may yield a very counter-intuitive performance. Rather than giving into magic thinking cargo cult programming, you should always take a little time to validate our assumptions and hypotheses about the data, the data structure, and the access patterns, as data structure behavior is clearly not independent from the data and the access patterns.

Consider this very simple example. We have a simple binary tree and a list of strings. Binary trees offer insertion and access times, so it is, a priori, a good choice. Now, the list of string is composed of words, but it so happens it’s already sorted. If we insert the strings in the order they are in the list, we get a degenerate binary-tree that’s in fact a list! Indeed so: insertions are always performed at the far right of the tree, causing the tree to degenerate into something we could call a vine and then all operations degenerate to linear time. If we randomize the list and insert the words into the tree in that randomized order, we get a ragged tree, but about equally deep everywhere, leading to the expected access and insertion time.

The sorted list / binary tree example is an over-simplistic one, I admit, but it gets to the point: the programmer used a data structure cargo-culted to offer access time, but due to his incomplete comprehension of the data (the sorted list) and of the access pattern (inserting items sequentially from the list), the result was disastrous.

But the thing is, we all do that to a certain extent!

One thing I didn’t notice right away is that the number of female participants (including presenters) at the conference was very high.

In Canada and the U.S., it seems that women are not that interested in the hard sciences like maths, engineering, or computer science. And that’s not because they are kept out of those faculties; quite the contrary: there are numerous incentives and wooing programs; or that they can’t do it: they just don’t care, it seems. Women study more than men (in a 2:1 ratio in universities, at least in Québec) but they do not choose engineering, maths, or computer science; they prefer health and care studies, like medicine, social works, etc.

Here, in Malaysia, there seems to be a large number of women studying in engineering, computer science and maths; at least a great deal more than in Canada. I wonder if we could borrow their strategies to get women to be interested in engineering and sciences or if it is rather the result of a fundamental cultural difference between our two countries. I say I wonder if it’s not cultural because a large percentage of the women (but not all) wore a conspicuous hijab headscarf.

Readers, any ideas/impressions on this?

Language is always fun to use to better effect, whether it is to make your point or break your adversary’s point. All natural languages are rich and contain a number of regional, rare or made-up words. French has a number of them and so does English.

Rare, nonce, or simply made-up words show up in comedy, literature, and even programming. As I am not a native English speaker (which I am sure you gathered by now by reading this blog) I do often read books about English to better my grasp of the anglo-saxon language. Not all of them too serious.

In Forgotten English Jeffery Karcirk presents us a few words with surprising meaning. If bugger today mostly designate someone that is fond of bugging people, we discover that it would still be better to keep the horses well locked in the stables. From boanthropy (thinking that oneself is an ox) to phrenologize (practice phrenology on someone’s skull), you are sure to find a word or two amusing.

But choosing one’s words carefully may help frubbish a text, but one should also refrain from abusing gadzookery (as one may find in, say, Jonathan Strange and Mr. Norell). It is quite uncompuctuously that I urge you to use nonce words—as long as they are perfectly cromulent— to better effect; certainly extending the wealth of words in the English language.

*
* *

I have a few of my own invention, that I rather like:

• Expygeous, ·ly. From ex from, out of, and pyge, Greek for butt. Replaces advantageously “out of one’s butt” in polite conversation. The constants in this equation have been chosen quite expygeously. In verb form, it becomes expygiate. He keeps expygiating answers.
• Gnumplementation. A re-implementation by GNU of an existing piece of software, just for the sake of making it free, regardless of whether or not it is actually useful to do so.
• frobnulate, ·d. To make needlessly complicated; akin to contrived, but with deliberate obfuscation in mind. This frobnulated example only shows the tenuity of reasoning.
• upgraditis. The compulsion to upgrade software as soon as a new version comes out. OMG! Ubuntu 10.4 pre-alpha is out! I’m so dist-upgrading!
• capilotomy, ·omania. The action (or habit) of splitting hairs whenever possible. No, that’s not Frobnisher 4.2, it’s 4.2.012a. (In French, the word would be tétracapilotomomanie, as the expression is “cut hairs in four”)
• technoodle. Someone devoid of technological acumen (in French, technouille sounds just as funny). Oh, that .exe file? I erased it, it was full of random characters when I looked at the contents. You know, with ‘type’

*
* *

Further Readings

Books:

Jeffrey Kacirk — Forgotten English: A Merry Guide to Antiquated Words, packed with History, Fun Facts, Literary Excerpts and Charming Drawings — William Morrow and Company, 1997

Jeffrey Kacirk — The Word Museum: The Most Remarkable Words Ever Forgotten — Touchstone, 2000

On the web:

• Nonce words at wikipedia.
• Blackadder causing much pericombobulations to the pedant doctor Johnson.
• The Doubletongued blog.
• Wikipedia about sniglets.




• The complete list of unwords.

On this last day of ISIEA09, a lot of the participants have already left. This gives me the impression that many participants just left as soon as they had presented their paper. I feel sorry for the last presenters who spoke before almost empty rooms. I think that it is rather rude, nay, even cheap to run away as soon as your paper is presented.

Compounded with the fact that a lot of presenters didn’t even show up—there was a lot of them—the last day at ISIEA09 was rather intimate. On the good side, it meant more time to discuss between talks and some exchanges were rather good. This being said, I think ISIEA should adopt the same ‘no show’ policy other conferences have. Unless you cannot show up because some case of force majeure, your paper is withdrawn from the proceeding and you are banned from the conference for a number of years. That’s harsh, but that prevents situations where 20-25% of the speakers do not even show up.

ISIEA’09 is the most varied conference I attended so far. Usually, conferences are more or less focussed on a specific topic. Here, everything vaguely industrial is a welcome topic: one speaker discussed optimal pump control to avoid cavitation, another an automatic ablution machine using machine vision… I think this kind of conference is very stimulating because you get to discover areas of research you did not necessarily knew about.

*
* *

I presented my paper on the speeding up of motion estimation in video coding using SIMD instructions and approximate metrics—I will put the paper and the slides online when I return. I think the presentation went pretty well, as it drew some attention.

I arrived at Kuala Lumpur for ISIEA’09 yesterday. After a good night sleep (the trip from Montreal takes something like 28h, door to door) I set out to visit a bit. My first impression is that Kuala Lumpur is a safe city, filled with friendly people. I visited the Menara Kuala Lumpur and the Petronas Towers (although I will have to return as the skybridge was already sold out for today).

This is the second time I visit a country where I do not speak the language at all, but the people here know a little English and seem to be willing to help if they can. I like the people here. They’re polite, warm, and industrious.

The conference begins tomorrow. I am eager to see what’s hot on the Asian computer science scene—this is an Asia-centric conference, for a change.