Source-Level Versioning?

When you develop software, you’re always dealing with dependencies, and, if you’re lucky (or have made a quite enlightened choice of dependencies), you don’t have to worry too much about version numbers. But what if you do?

Patching the Environment for ‘exotic’ Libraries

Every time I add a development library (or any other application) that is not found in my distro‘s repositories, I ask myself how troublesome it will be. If you’re really lucky, it comes in a package (and repository) compatible with the target distribution (like a Debian package or a RPM) and everything is just fine: you install it from the package manager, and that’s it. But if not, you have to download a tarball from some (more or less trusted) location like Sourceforge. It usually comes with a rather well designed set of configure, make, and (sudo) make install scripts that reduces configuration to little more than launching the configuration script, check for any unmet dependencies, add them and rerun the configuration script until they are all met, and then make install performs a smart, standard location install and you’re done. You won’t have the automagical upgrades with everything else, but you can go on with your life.

Then again sometimes you have to install a library (or application) that either has a half-baked installation script, or is incompatible with your distro, or, cerise sur le gâteau, both. And, just to aggravate you just fine, it installs to a non-standard location requiring you to specify include and library paths in your make files or just to invoke the application. And, of course, default location will change from from /usr/local/shared/thislib/ to /usr/shared/include/thislib between version 2.1.5 and 2.1.6, just to make sure to break just about everything you set up.

Random Points on a Sphere (Generating Random Sequences III)

Last week, we discussed how we could generate uniform random points in a triangle using a (tiny) bit of linear algebra, mostly the parallelogram rule, and a random variable uniform on . It required a tiny bit of math and was computationally very simple.

This time, let us see how we can generate uniformly distributed random points on a sphere.

Random Points in a Triangle (Generating Random Sequences II)

In the first post of this series, I discussed a method to generate a random (guaranteed) permutation. On another occasion, I presented a method to recycle expensive random bits. Today, I will discuss something I had to do recently: generate random points inside a triangle.

Damn you, Saint-Exupéry!

The Ubuntu Linux distribution is putting a lot of efforts into streamlining the interface and provide a greater user experience. While there’s clear progress, there are a number of things that are still really missing. The guys at Gnome and at Ubuntu are maybe taking the motto perfection is not when there’s nothing else to add, but nothing else to remove a bit too seriously. Every release shows more and more features but less and less user configurability.

Well, to be honest, I have always found my way around those limitations by hacking directly configuration files, the gconf-editor registry-like thingie, and writting scripts to set automatically configurations for which there were no other way—or just not documented, which is the same as far as I am concerned.

Amongst the extra thingies, there are many keyboard shortcuts, but not all of them are configurable. For example, if there’s a way from Gnome to configure which keys you want to use to control LCD or keyboard brightness or to display power information, it’s pretty damn well hidden. On my Dell mini, there’s a nice key with a battery icon on it. If I press it, Gnome displays in the OSD a concise battery status. But on my macbook pro, there’s’nt such a key and I have no way of telling Gnome (from Gnome itself) to use the F4/Gauge key to act as the Show Battery key.

POCS and Color Spaces

If you’re doing image processing, you’ve probably had to transform your image from one color space to another. In video coding, for example, the RGB image is transformed into YPrPb or YCrCb so that most of the visually relevant information is packed into the Y component which is essentially brightness. Subsampling the chroma bands (Cr and Cb) provides additional means for compression with little perceptual quality loss. While the human eye is very good at detecting brightness variation, it’s not very good at detecting subtle changes in chroma, either saturation or hue.

The thing is that very often, there are color space transformation matrices found in text book but they’re not, due to rounding (and other possible errors), always exactly inverses of each other. This week, I will discuss how we can use projections onto convex sets (POCS) to make sure that reduced precision matrices are exactly (within a given precision) reversible.

Suggested Reading: Patterns for Parallel Programming

Timothy G. Mattson, Beverly A. Sanders, Berna L. Massingill — Patterns for Parallel Programming — Addison-Wesley, 2005, 356 pp. ISBN 0-321-22811-1

(Buy at Amazon.com)

If the Gang of Four changed the way we discuss about software design by introducing a catalogue of basic software patterns, this books vies to extend it to parallel patterns. But let us be clear, it’s not a book about parallel algorithms; no, it discusses parallelism in very general terms and present the few prototypical application types and how they can be efficiently broken down by data structure, command flow, and synchronisation, while remaining rather high level.

Being Shifty

Hacks with integer arithmetic are always fun, especially when they’re not too hard to understand (because some are really strange and make you wonder what the author was thinking when he wrote that). One such simple hack is to replace divisions or multiplies by series of shifts and additions.

However, these hacks make a lot of assumptions that aren’t necessarily verified on the target platform. The assumptions are that complex instructions such as mul and div are very slow compared to adds, right shifts or left shifts, that execution time of shifts only depends very loosely on the number of bit shifted, and that the compiler is not smart enough to generate the appropriate code for you.

One Does not Simply Rename Into C++

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.

#defines are EVIL (part II)

In a previous post I discussed some aspects of the C preprocessor (hereafter the CPP) that are evil. Turns out that this week, I had another problem related to a bad usage of the CPP. It didn’t take long to fix, but I can understand why it could be long to figure out.

And while the bug was caused by a careless use of the CPP, I think there’s a couple of simple things we can do to help avoid these.