I've rolled another new Boost bindings snapshot, dated 20080405.

This time around, I've done a bit more than update to current svn. I've tried to scavenge past contributions from the Ublas mailing list that got dropped on the floor. I've created a new version control tree where I intend on maintaining these changes:

http://git.tiker.net/?p=boost-bindings.git;a=summary

For starters, I've picked up:

• Jesse Manning's gels* routines.
• Vardan Akopian's gbsv routines.
• Georg Baum's non-std::complex<> fixes.
• Georg Baum's Fortran naming override.

If there's anything I've missed, or if you have a contribution to the bindings sitting on your disk waiting for submission, please email me now! The bindings are a tremendous resource, let's try to not let them wither away.

How should scientific codes be constructed? Scientific codes are often experimental in nature, and therefore need to be easy to change, and, of course, quick to develop in the first place--who wants to invest any more than necessary into an idea that might not work out after all? On the other hand, computational scientists are an impatient bunch: Once the method stabilizes, or it becomes clear that it is generally useful, more and more demands get placed on a prototype code, most of all speed. It is clearly desirable to respond to these demands in an evolutionary manner. Why rewrite an entire code, possibly in a different language, if only one small part is responsible for most of the run time?

One answer that I have found to address these problems well is what I call hybrid development. Nearly all my code these days is "hybrid". Now what does that mean? That means, I start developing in a high-level language that is quick to modify and separates me from the more menial tasks of coding, allowing me to code and test an algorithm quickly. The cost for this quick development turnaround is that the initial prototype is often fairly slow because many small operations are performed in the (often interpreted, instead of compiled) high-level language. This is an effect that everybody who has developed larger-scale code in MATLAB or similar environments has seen. Often, the bulk of the run time is concentrated in 10% or less of the entire code. In this case, the sensible solution is to replace the slow part of the high-level code with a lower-level compiled implementation, while keeping as much of the existing high-level code intact. This is the idea of hybrid development.

MATLAB supports this idea to some extent with its MEX mechanism. There are however many more powerful tools on the market (and available for free) that make hybrid development easier and faster by orders of magnitude. In a future installment of this mini-series, I will highlight the software environment I use for my hybrid codes, and point out what I believe its advantages over other solutions are.

If you're willing to exchange a bit of memory for a lot less strain on your wrists, let alone work speed, this is your lucky day. In this post, I will describe how I've tuned my everyday work environment to a point where it feels completely unnatural for me to have to move my hands away from the home row. And that's a good thing--the less often my hands have to go anywhere, the less I am at risk of having painful wrist trouble later in life.

So what's the are the keys to all these benefits? You might laugh, but in fact they are H, J, K, and L. Namely, the cursor motion keys in Vi. It may seem strange to tell people to use H to move to the left, J to move down, K to move up and L to move right, when there are these handy arrow keys right next to where your hands typically sit. But the problem is that your hands have to move quite a ways, and if you're like me, you also flex your wrist somewhat unnaturally just to reach those. On the other hand, HJKL are right there on the home row, if you touch type. No wrist movement required.

Now, much of what you do every day on your computer involves moving around. So why not make use of these convenient motion keys in as many places as possible? Read on for a slew of suggestions.

I had a good laugh off this list of unintentionally offensive product names. As the title hints, Barf detergent is up there. But there's one name that takes the cake. It hails from Germany, as it had to. To be precise, the electronics firm Trekstor decided to name the black-colored addition to their "iBeat" line the Trekstor i.Beat Blaxx.

The name sounds convoluted enough that, no doubt, it took lots of effort-by-committee to find it. And all of that just to get the whole thing catastrophically wrong. Sounds somewhat typical of Germany to me...

If you're choosing between Obama and Hillary, here is a compelling argument brought forward by someone who knows what he is doing. (transcript)

I couldn't agree more. Go ahead, spread this! :)

Since I've received a number of calls for help with regard to my software packages, in particular MeshPy and PyLinear, I've decided to create a public forum for these requests for help. Here they are: the MeshPy forum and the PyLinear forum.

Here's to years of useful discussions! ;)

Have a friend who does not believe CO₂ emissions are real and may be harmful? Show them this:

I've pushed out yet another version of TagPy. This time it is to mop up after some rather unhelpful default in TagLib. That is, unless you have the magic lines:

import tagpy.id3v2 as id3v2
id3v2.FrameFactory.instance().setDefaultTextEncoding(tagpy.StringType.UTF8)

in your code, the generic API tag.artist = u"*some funky unicode string*" will write Unicode tags as Latin1 if the previous ID3v2 tag was also Latin1-encoded. This will of course destroy your carefully crafted unicode string. Therefore I urge all users to include these lines in their code, in order to avoid such trouble.

All that's new in 0.93 is the wrappers that make this call possible.

I tought about making the above code the default for TagPy, but I wasn't sure whether that was the right thing to do, seeing as how this default would deviate from TagLib.

1,662,780How Many Germs Live On Your Keyboard?

(xkcd is great.)

Complex analysis on YouTube:

Yup, too cool not to share. :)