Scary Code

November 9, 2010

If you code a lot in a week, you’re bound to make some (possibly) amusing typos. Almost every time, the typo is detected by the compiler and an error is issued, but sometimes you manage to (mis)type valid code! And I recently make one of those typo and I started wondering how far we can push this idea in writing really, really, really, really ugly code.

Read the rest of this entry »

Or a Whale, II

August 17, 2010

Tomorrow’s flowers are in the seeds of today.

Chinese proverb

Read the rest of this entry »

Or a Whale.

August 10, 2010

   Do you see yonder cloud that’s almost in shape of a camel?

   By the mass, and ’tis like a camel, indeed.

   Methinks it is like a weasel.

   It is backed like a weasel.

   Or like a whale.

   Very like a whale.

Hamlet, Act III

William Shakespeare

Read the rest of this entry »

One Does not Simply Rename Into C++

July 13, 2010

Programming is in many ways more art than science—I do not want to start that debate in this post—in that you need more than mere functionality and correctness to have great code. For code to be great, it has, amongst other things, to be beautiful in that strange, vague, language-specific way.

As you know, this blog is C and C++-centric. Those are the two main languages I use both for personal and for professional projects. I resisted the transition from Pascal to C a long time, for many reasons. One was that at that time C compilers were flimsy, while we had a couple of really great Pascal compiler, such as Turbo Pascal—quite the upgrade from my Apple II’s USCD Pascal. Another was that I found C just ugly, clunky, and primitive; it was terse and inelegant. But over the years, I learnt to like the way C gives you pretty good control on what code is generated—not that you can predict right down to the assembly instructions what the compiler will generate; but you still have a very good idea if you understand even vaguely the underlying machine.

Read the rest of this entry »

Is Python Slow? (Part II)

June 8, 2010

In a previous post I expressed my worries about Python being excruciatingly slow and I used a toy problem to compare the speed of Python to programs in other several languages, including C.

Of course, all kind of people complained that I couldn’t compare a dynamic, interpreted language with static, compiled languages. First, let met tell you that I sure can. First, the goal was to measure speed, and not the effects of type system of the language (although logically correlated) nor the programming paradigm: the amount of CPU used to solve a given problem was the primary (if not only) point in interest.

But to be fair to Python, I extended the tests to other interpreted, dynamic languages, such as Lua, Perl, PHP and JavaScript. I also added Pascal and Haskell in the compiled languages groups.

Read the rest of this entry »

Radix Sort on Floating Point Numbers

March 9, 2010

Phimuemue, in a recent post (at the time of writing, anyway) present his variation on sorting floating point values using radix sort. His implementation wasn’t dealing with the pesky sign bit so I offered a slight modification to his algorithm as a comment on his blog. But for some reason, he did not allow to post it.

So I’ll present my solution here.

Read the rest of this entry »

Bundling Memory Accesses (Part I)

January 19, 2010

There’s always a question whether having “more bits” in a CPU will help. Is 64 bits better than 16? If so, how? Is it only that you have bigger integers to count further? Or maybe more accessible memory? Well, quite obviously, being able to address a larger memory or performing arithmetic on larger number is quite useful because, well, 640KB isn’t all that much, and counting on 16 bits doesn’t get your that far.

AMD Phenom

But there are other advantages to using the widest registers available for computation. Often, algorithms that scan the memory using only small chunks—like bytes or words—can be sped up quite a bit using bundled reads/writes. Let us see how.

Read the rest of this entry »

Why Validating Input so Hard in C?

January 12, 2010

Validating input from file or keyboard is probably the most difficult thing to get right in C. Not only is it difficult to get right regardless of the programming language, C really doesn’t do much to help you. There’s the standard library, mostly accessible through the two headers <stdlib.h> and <stdio.h>. However, the facilities provided by the C library are rustic at best. They haven’t aged well, and they’re clunky.


For this post, I will limit I/O validation to grabbing input from text files, whether through a redirection, pipe, file, or console input. I may discuss binary or highly structured formats like XML in a later post, but let us first limit ourselves to a few simple cases.

Read the rest of this entry »

#defines are EVIL

November 17, 2009

The C (and C++) preprocessor is a powerful but dangerous tool. For sure, it helps with a number of problems, from conditional code inclusion to explicit code generation, but it has a few problems. In fact, more than a few. It is evil.


The C preprocessor (hereafter CPP) should be used with extreme care. For one thing, the CPP doesn’t know about the language it is applied on, it merely proceeds to the translation of the input using very simple rules, and this can leads to tons of hard to detect—and to fix—problems.

Read the rest of this entry »

Generating Random Sequences (part I)

September 29, 2009

Every once in a while, we need a random sequence. Whether to test a data structure’s performance or to run probabilistic unit tests, the provided rand primitive from your favorite programming language has several limitations. First, it’s been known for a while that if most implementations of the C standard library rand() function are not very random, despite being “good enough” in great many cases. Second, and more importantly, it does not allow you to easily control the period nor to generate a permutation on 0\ldots n-1, for example.


There are many methods of generating pseudo-random number sequences. Not all exhibit the same properties and, accordingly, a method may be more useful in one case and perfectly useless in another. High quality pseudo-random number generation is a notoriously hard endeavor, but there is a number of very simple algorithms that will get you out of trouble for certain specific tasks. Let us consider, for example, the example where the pseudo-random generator must generate the numbers in 0\ldots{}n-1 exactly once, in a random order, of course, in exactly n draws.

Read the rest of this entry »


Get every new post delivered to your Inbox.

Join 74 other followers