Learning Python (II)

One thing I really like about Python is how it makes manipulating lists quite easily, especially via slices and list comprehensions. List comprehensions, especially in generator notation form, are an easy way to create lists with specific content. Other functional programming languages (such as Mathematica, amongst others) have taught me to use “map” to transform lists. But is it always the clearest and fastest way?

Run, Python, Run!

I still can’t figure out exactly which operations are expensive in Python. My C/C++ can’t help me much because it seems that things aren’t implemented like I’d’ve expected—like lists that aren’t lists, but array lists, leading to for operations you would otherwise expect to be .

But a friend of mine—Olivier—showed me a simple, basic, yet rather effective tool to profile Python programs (I’m not sure if I should say script or not).

/* no comments (part II) */

In a previous installment, I discussed the quality of English in comments, arguing that the quality of comments influences the reader’s judgment on the quality of the code as well.

That’s not the only thing that can make code harder or easier to understand. Today (anyway, at the time of writing), I was working on something where arbitrary-looking constants would constantly come up. I mean, constants that you wouldn’t know where they’re from unless there’s a comment. A clear comment. Let’s see some of those.

Coding Maps (Part I)

Quite a while ago, I discussed map generation in the classic 80s-era game Tunnels of Doom. After a short correspondence with Kevin Kenney himself (who kindly answered my questions; and I hope he is aware that he contributed to the fascination of great many kids in computer science), I manage to, not exactly reproduce his algorithm, but create a number of fun variations.

Tunnels of Doom Combat Screen.

This raises the question as to how do we encode maps efficiently in the computer’s memory, not only for Tunnels of Doooooom but also for any number of other games.

Programming Challenge: Martian Calendar

This week, another programming challenge, but this time considerably tougher than the previous.

His Imperial Majesty, Xórgü of House Nand, decrees that the martian imperial court is in need of a new calendar. The current martian calendar counts 668 days, but it accumulates errors. The martian year, according to His Imperial Majesty’s most illustrious astronomers, is in fact 668.60 (martian) days long.

Programming Challenge: Luminance

A few years ago, I posted on my personal web page a number of programming challenges for my friends. This week, I present one of the old challenges: computing luma from RGB triplets using integer arithmetic only.

Learning Python

When you come from different programming languages like C and C++, where you are used to control very finely what the machine does, learning Python is quite disconcerting, especially when it comes to performance.

Without being exactly an optimization freak, I rather like to use the best algorithms, favoring algorithms over an naïve algorithms/implementations, so you can guess my surprise when after replacing the initial implementation by an implementation I did not observe the expected speed-up.

Python References vs C and C++

As I’ve mentioned before, my new job will ask me to program more in Python than C++, and that’s some what new for me. Of course, I’ve criticized Python’s dismal performance on two occasions, getting me all kind of comments (from “you can’t compare performance like that!” to “use another language then” passing by “bind to external high-performance libraries”).

But it seems that my mastery of Python is still quite inadequate, and yesterday (at the time of writing, anyway) I discovered how Python’s by-reference parameters work. Unlike C or C++ that use explicit syntax to specify what kind of object we’re dealing with (either by value, pointer, or by reference), Python is a bit sneaky.

Suggested Readings: Programming Pearls

Jon Bentley — Programming Pearls — 2nd Ed, Addison-Wesley, 2000, 240 pp. ISBN 0-201-65788-0

(Buy at Amazon.com)

The central theme of this book is efficiency and economy of solutions of programming problems. However, if the book is globally interesting, it would greatly benefit from an update; the proposed programming style—independently of the gist of the solutions— is old school in many respects. The style should probably updated to take modern programming style into account, say, à la Alexandrescu and Sutter for C++.

Initializing Arrays

Initializing large arrays of data before use is always cumbersome but it seems to be unavoidable.

The first types of solutions fill the array with a value that denotes an empty entry. While this sounds straightforward, the choice of that value is not always easy. For floating points numbers, zero may or may not be a good candidate. If convenient (as a zero floating point value is encoded as binary zeroes filling the variable) it may be difficult in some contexts to use because zero may be valid. Fortunately, there’s always the possibility to initialize the array with NaNs, which can be tested and used correctly (but you need the POSIX functions to do that).