Ever wanted to include a nice illustration from someone else's PDF in your own? (while preserving vector happiness and not resorting to bitmap screenshots--yuck) No longer a problem: Enter InteractiCrop!
Obviously: Make sure to request permission when appropriate, and credit your source! In fact, here's a TikZ snippet that will help you add a credit box to your slide:
\newcommand{\creditto}[1]{
\begin{tikzpicture}[overlay]
\node [xshift=1cm,yshift=0.5cm]
at (current page.south west)
[font=\scriptsize,fill=gray!30,anchor=south west,opacity=0.5]
{#1};
\end{tikzpicture}
}
This past week, I had the honor of presenting a talk on PyCUDA at Nvidia's inaugural GPU Technology Conference.

Please click the following link to view the slides: pycuda-nvidia.pdf.
Update: Nvidia has posted a recording of the session that you may watch or download.
Update 2: Giancarlo Colasante has transcoded the above video into just 16 MB. You may download the resulting video here.
As a math person, you're often faced with the task of communicating about math. Unfortunately, most modern means of communication, be it email, the web or instant messages, aren't really suited to typing math. Fortunately, however, many of these means do allow the use of Unicode, and Unicode allows for certain limited forms of mathematical typography.
Putting Unicode formulas together usually requires a fair amount of patience and some quality time with your favorite character map application. But now there's an easier way: The Unicode Input Helper--or "UIH". Here's an image of it in action:

Using it, you may use HTML entity names with backslashes (such as \int for an integral) to put together the basics of a formula, and then use a searchable list of all known Unicode characters to add the finishing touches. The screenshot gives you an idea. Once you've finished your masterpiece, simply use your computer's copy-and-paste function to get it to where it needs to be.
(Like PuDB, uih requires Ian Ward's urwid library.)
As a side benefit, I think uih makes for a nice replacement for pretty much every character map program--but its original purpose was easy typing of math.
I'm happy to introduce PuDB, a full-screen, console-based visual debugger for Python that I recently cooked up.
Or install it simply by typing
easy_install pudb
into your Unix shell. Here's a screenshot of it in action:

Python has had decent debugging support for a while now, in the form of
But I felt that there was a gap between these offerings--Pdb being very austere, and Winpdb and the IDEs being rather heavyweight. I wanted a comfortable debugger that's easily usable in a shell and doesn't require me to touch my mouse. PuDB uses Ian Ward's excellent Urwid library for its interaction with the console.
Update: Looks like PuDB is slowly growing a community. There's now a mailing list to host discussions.
Here's a waste of time I could just not resist: MIT's Project SIMILE has released a rather nice Timeline Web Widget. Combine that with GitPython and a bit of glue code in Python, and you get a neat, one-page summary of the software work I've done as part of working towards my PhD. Here's a screenshot if you're too lazy to click through:

Note that (nearly) every commit is hyperlinked to the git web frontend, where you can view what was actually changed--just click the title text in the popup bubble.
If you'd like to do this yourself, the code is available, you can get it with
git clone http://git.tiker.net/trees/commit-timeline.git
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.
NOTE: This package is no longer maintained. Work on this continues in ARPACK-NG.
This is a distribution of ARPACK, the well-known sparse eigensolver, with a number of changes:
Note that ARPACK is not my own work, I am only redistributing a modified version. I contacted Rich Lehoucq years ago with a report of the crash bug, but the fix never showed up on the ARPACK page, so I resorted to distributing my own modified ARPACK package. Since ARPACK continues to be useful for my work, but its rather old-fashioned build system kept getting in my way, I one day decided to replace it with a modernized, autotoolized version, so that it can be built on most machines with just the regular
./configure
make
make install
incantation. Additionally, the new build system makes it trivial to build a shared library of ARPACK. Since there doesn't seem to be a proper version-numbering scheme at ARPACK's original site, I've also taken the liberty of starting at version 0.90.
The current source tree can be found in my git repository, and downloaded from here. You may also obtain a copy directly by running the command
git clone http://git.tiker.net/trees/arpack-autotools.git
So after madman is currently orphaned in Debian and might get kicked out of the archive along with xmms kicking the bucket, I just noticed that one of my newer pieces of code made it into Debian: tagpy! :) That's awesome.
To everybody who is holding their breath waiting for a madman update: I still use madman for my own music managing needs, as it still (surprise) is exactly what I want in a music manager. But I simply don't have enough time for serious maintenance. I might switch it to audacious in the near future to keep it working for me, but I'm not promising extensive new features...
All source control is now handled through http://git.tiker.net. Briefly: To obtain the most recent copy of some piece of software, type
git clone http://git.tiker.net/trees/NAME.git
A perty Python clone of Bejeweled. At present, I'm a bit uncertain about whether I may redistribute the sound bits which I used in the game. They're just scavenged from the internet. Until I figure something out, only the parts of the game which are mine are available. Currently, the only way to get this game is to download the git tree.
A solver for Sokoban levels. See this post for details. To be found here.