If you’re anything like me, you go to Brown University and really like Till Tantau’s Beamer LaTeX package for making slides. Unfortunately, Beamer’s theming can be a bit obstinate, and figuring out how to give your slides a Brown flavor (yum!) can be tedious.

Luckily for you, I just spent some time and put together a template that you can use for exactly that purpose. This is what it looks like:

slides-0.png

I’ve also attached a sample PDF to this story.

Download

You can download a tarball of the most recent version or browse the source code. If you like, you can also directly get a git checkout:

git clone http://git.tiker.net/trees/brown-beamer.git

Instructions

To use this template, obtain the source tree, edit slides.tex, then change to the out directory and type ./make.sh. (If you’re on Windows, maybe you can send me a batch file that does the same thing.)

In this recent paper, Finite Volume guru Randall J. LeVeque addresses an issue that is near and dear to my heart: Computational Scientists must start thinking about the reproducibility of their results.

Scientific results obtained by experimentation are expected to be reproducible. This has long been demanded of published results in, for example, physics or chemistry. Yet, scientific computing, while often experimental, has been strangely exempt from this requirement. This ought to change.

In his paper, LeVeque formulates several demands to be placed on scientific codes:

• Availability in source code form. Codes used to obtain results in published research must be available for other researchers to inspect. While LeVeque is not as clear about this point, I would like to emphasize that this availability should be of the same kind as that of the paper advertising results obtained by the code. In most cases, this means that the code should be downloadable from the same place as the paper. (There should not be access restrictions on the paper either, but that’s a different issue.)

• No dependencies on for-pay software. For widest availability and reproducibility, it is preferable to not have scientific codes depend on commercial, for-pay software. That notably includes Matlab.

• Readability. Codes should be written mostly to be read, not so much to be executed. We need to grow an understanding that code is a valid expression of the ideas that it contains. The more apparent these ideas are from the code, the better.

Given these constraints, he arrives at virtually the same toolset that I’ve been using for a while now, consisting of Python, numpy, matplotlib and VisIt.

I am hoping that this issue gets the attention it deserves. I’ll try to do my part.

I’m happy to announce the availability of PyUblas and its companion package PyUblasExt in version 0.92. While PyUblasExt is available for the first time in released form, these are the changes made to PyUblas:

• Sparse wrappers are now not compiled by default. You have to request them using --with-sparse-wrappers at configure time.
• Provide implicit to-/from-python conversion for Ublas’s vector, bounded_vector, and matrix types.
• Provide from-Python converters for Numpy’s array scalars.
• Instantiate converters for a much wider range of element types.
• Fixed compilation without -DNDEBUG.
• Plus a slew of other cleanups and fixes.

Responding to a patch from Bill Nottingham, I’ve uploaded TagPy 0.94.1. It fixes building TagPy against TagLib 1.5 and also fixes a mis-wrap of the clear method of the Map type.

In case you were wondering, 0.94 was a dud, but by the time I realized that, I had already uploaded the tarball to the Python Package Index, which made it unchangeable. :(

Additionally, I’ve decided to only upload new releases of TagPy to its page in the Python Package Index. Easier maintenance, yay! :)

Yay, here I go again. (Update: and again) There were a few small wrinkles in Synoptic 0.91 (and 0.91.1) for which I felt it warranted to push out a followup release, aptly called 0.91.2. It fixes the following things:

• Depend only on Python 2.4 by reverting to Python Paste’s WSGI httpd.
• Speed up page load by serving all javascript as one big clump.
• Change JS/CSS load order to fix history slider size.
• (new in 0.91.1) unbreak daemon mode in Python2.4
• (new in 0.91.1) launch browser from background thread, to avoid deadlock.

Download from PyPI

I’m happy to announce the first truly public release of Synoptic, my own web-based dynamic note taking application. If you find yourself lost in a jumble of either paper notes, text files on a hierarchical file system, or an overgrown Tomboy wiki, and find yourself craving order, categories, and simplicity, Synoptic may well be for you.

So go check it out! :)

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 the true killer name, to me, came 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.

Priceless. :)