Bad Graphs!

One of the good things of the peer review process is that if you publish, you’re eventually going to have to review papers for conferences or journal in your (perceived) area of expertise. Sometimes you get pearls such as “the resulting results of algorithm X are resulted” (true story), or “the dynamics of the attorney of yes no plasmodium” (also true), but sometimes bad science comes from the bad presentation of results.

This is also a (essentially true) story. So I’m reviewing a paper that proposes some kind of method for predicting the value of (some) parameter that minimizes some error function. The method is fast, but not analytic. The graph in the paper looks something like:

iPod Touch Movies?

I got myself one of those “retina display” (960×640) 5th gen iPod Touch for the New Year. First impressions are that it’s rather well integrated, responsive, and has a number of fun applications. It’s even usable as an X/SSH thin client with a 10$ App.

With Permissions of Emily Carroll

But then you try to see how far you can push the use of the device with Linux (my primary operating system) and find that the support is dismal. The support is already not that impressive with Apple‘s iTunes running on Mac OS X. iTunes is really slow even when running native (i.e., without virtualization) and also does some very stupid things such as preventing you from copying a PDF you downloaded from the web back on the computer even though it has no DRMs—a behavior defective by design. Another limitation is in the iPod itself: the video formats supported are very limited.

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.

No more Ads.

Apprently, my blog have been sucessful enough for WordPress to spam ads here and there. That’s fair, I suppose, as they have to pay for the infrastructure and all, but nevertheless I bought the No Spam Package to get rid of them. When I’m looking for information there’s not much I hate more than those add-ridden sites that have like, one 15 lines paragraph of text surrounded by 10 of those stupid Evony adds (or worse) with a “next>>” link somewhere in the midle of the junk. I hope you’ll keep envoying my (mostly) add-free blog^*.

^* Except for my occasionnal Amazon-linked suggested readings, which I find quite whorish already.

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.

Save the Planet: Kill Flash!

The browser-embedded Flash player (or a derivative) is the preferred small (and low quality) video delivery mechanism on the web-based Internet. While I completely understand the usefulness of such a player (or at least the amusement it procures), I can’t fathom why the hell it’s so resource hungry. That damn thing sucks an inordinate amount of CPU to play tiny videos! What’s wrong with this thing?

Is Python Slow? (Part II)

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.

Things I never, ever, want to hear. Ever.

Things I never, ever, want to hear. Ever.

• In theory,… No, I don’t want to know what you think the code does, I want to know that it actually does—especially if you’re the one that wrote the code. If you haven’t verified, validated by actually testing stuff in a systematic manner, you have failed. Have you validated the functions with stringent unit testing? No? then get out of my face and go write code to test your code. Validate your hypotheses. Always.

Foiled!

QuickSort, due to Hoare, is one of the best comparison-based sorting algorithms around. There are a number of variations, but the vanilla QuickSort does a great job… most of the times.

Indeed, there are occasions where QuickSort leaves its expected run-time to reach run-time, its worst case. But what does it take to push QuickSort into its worst behaviour?