Not Even My Wife Reads This

I had an almost-working solution to Project Euler Problem 101 which failed due to floating-point roundoff error. So I wrote my own Python Rational class, with lots of overloaded methods like __add__ and __div__ to handle all the infix math operations. This was not fun, and I never quite got my Rational class perfect, just good enough to let me finish the problem.

The next day, I thought of using gmpy for another Project Euler problem, because it has an is_prime function that's fast for big numbers. (It returns 0 for composite, 1 for prime, and 2 for probable prime.) And while I was reading the docs, I found the mpq rational type inside. Which would have saved me an hour of pain.

Anyway, if you're ever doing math problems in Python, read all of the documentation for both gmpy (the Python library) and GMP (the C library it wraps). GMP is billed primarily as a bignum library, which you don't really need in Python since Python comes with infinite-precision longs. But there's a lot more to it than that.

I've been reading the Gardner Dozois annual best-of short SF collection for 21 years now. (Started with #3, and I still haven't found the first two volumes.) Usually takes me most of the year to get through it, since it's a big fragile paperback that doesn't travel well, and the end of every story is a convenient stopping point. (And then I start something else that's harder to put down in the middle.)

Finally finished number 23. As usual, most of the stories were good this year. I thought the best ones were the stories by Gene Wolfe, Neal Asher, and Dominic Green. There was no single standout classic, though.

Recommended, if you like SF at all. Short story collections aren't that popular, which is a shame because the ratio of ideas per page is excellent.

My daughter Talia is five. She likes board games. Unfortunately, she mostly prefers truly awful ones, like Candyland and Chutes and Ladders, which are 100% luck and quite frustrating for adults to play. (Yay, we're almost to the end. Oh no, not that card that randomly sends me back to the start and makes me endure another 15 minutes of this nonsense.)

I visited boardgamegeek.com and looked for ratings for kids' games, hoping there was something not too hard for her that I could at least tolerate. Of course, no kiddie games actually got ranked near the top overall — that would be like expecting a juice box to rate high on a wine snob site — but the most recommended was a game I'd never heard of called Gulo Gulo, a dexterity game involving wolverines stealing eggs from a vulture. I was a bit skeptical because I thought she'd have a hard time winning a dexterity game against adults, but I bought it anyway.

It's been a hit. Talia has wanted to play it multiple times almost every day since. It's got cute little colorful figures for the players (they're supposed to be wolverines but they look more like bears to me), and cute little colorful eggs, and the main play mechanic is pulling a particular egg out of a bowl without knocking over a stick or disturbing the other eggs. Turns out that little kids are pretty good at this — small fingers are often more useful than adult coordination. The games only take about 10 minutes, and she wins almost as often as I do.

Recommended, if your kids are old enough to not swallow small objects, but too young for games that require reading or deep thinking.

At work I'm currently using Git and Subversion and Mercurial for version control. Other people there are using Bazaar and CVS. Too many programs to learn! We need to eventually standardize on a primary third-generation distributed tool to replace Subversion, but it hasn't happened yet.

There are lots of opinions on which third-generation distributed version control system should replace Subversion. (I like Mercurial a lot, respect Git's power despite its ridiculous learning curve, and haven't used Bazaar enough to have a strong opinion about it, except that it used to be unusably slow.)

Here's one data point you won't see in all the comparisons: code size as measured by sloccount:

Why is Subversion more than triple the size of any of its main competitors? C, two backends, language bindings, separate libraries for client and server, Apache / Webdav integration, separate admin tool, yadda yadda yadda. Do you really need all that?

Why is Mercurial less than a third the size of any of its main competitors? It's in Python, and there's definitely an aversion to feature creep, to the point where lots of features that would be core in other programs are extensions in Mercurial. (Note that the extensions that are bundled with the project are included in its SLOC number, while the ones you'd need to download separately are not.) What else? It is missing some features compared to, say, Git, but it's sure not missing two-thirds of them. Why is Bzr, which is also written in Python and has a roughly comparable feature set, three times as big?

How important is lean code? What features can the Mercurial team implement by the time Subversion merge tracking is done and stable? Is there actually anyone who can name all 143 programs that git put in my /usr/bin/ directory?