Numerical ODE Solvers

In MATLAB, the suite of numerical solvers for systems of ordinary differential equations are functions that accept variables, including other functions. Since I learned to program MATLAB for my numerical solutions, I am accustomed to this system of passing a function of equations and variables to the ODE solver function. While there is something gratifying in my mind about the distinct separation and, in theory, plug-and-play ease of this system, I cannot help but think that it’s computationally more efficient to have the ODE solver integrated into the numerical application. When people say that they write their own ODE solvers, I always assumed that they meant an ODE solver that accepted a function file of equations and iterated over them, in much the same way as MATLAB. However, it’s finally becoming clear to me that this is not the case, and by ODE solvers, most mean that they are simply hard-coding a numerical algorithm or scheme for iterating their equations. The difference is subtle and may boil down to a difference in computational versus mathematical approaches. In my current project, I am interested in interacting rhythms in biophysical models of neural systems, which requires me to solve large systems of ODEs numerically.

While I make the transition from MATLAB to GNU Octave/R, I’m learning about what implementations are reasonable to translate and what new things I need to learn. Of course, I am interested in maximizing efficiency in the shift, but I have to be careful not to do so at the expense of lost computational efficiency, which happened in my first attempt at using ‘lsode’ as a drop-in solver replacement for a complicated system of ODEs. Since I have decided to ditch graphics in MATLAB in lieu of another system that has fewer four letter words associated with it, the ODE solver was my last true obstacle in the translation from MATLAB to Octave. Now that I am going to solve that problem by “writing my own” scheme, I am that much closer to being completely free and open source in my science.

Saving figures in MATLAB and string concatenation

An economics graduate student and friend of mine recently asked Google out of frustration, “How the hell do I save a plot in MATLAB?” Google, being the unfeeling robot that it is, did not empathize with his question, but many of us certainly can. The useful commands here are ‘print’ and ’saveas’. Here is a qnd guide to them in the ways I use them, with lots of examples.

I always save the raw .fig figures so that I can edit plots in MATLAB without having to regenerate them. To do so, we will use the ’saveas’ command in the following way:

saveas(gcf, '~/Desktop/fig1.fig', 'fig');


The ’saveas’ command in this functional form is taking 3 arguments. The first argument in this example is ‘gcf’, which tells saveas to “get current figure” handle. This is the active or topmost figure window. This can be replaced with a figure handle reference. If you don’t know what that means, then look it up! Figure handles are very useful! The second argument is simply the full path name of our file. Finally, the third argument tells MATLAB to save in the file format .fig. Note the quotes. Respect the quotes. Abide by the quotes.

To save figures in png or eps format, I use the command ‘print’, somewhat non-intuitively. In MATLAB, the print command can print to either a physical device (a printer) or print to a file. We are using the latter in this case, with the example of the eps.

print(gcf, '-depsc', '~/Desktop/fig1.eps');

Again, ‘print’ in the functional form takes 3 arguments here. The first is ‘gcf’, much like in saveas. The second is a device specification. The leading ‘d’ stands for device, I think, and here it tells the print command that the device is a color eps file. Finally, the last argument is the path, much like the second argument of the saveas command. It’s important to note that, as of MATLAB 7.6, there is no native support for embedded fonts in eps files. Journals and possibly collaborators will yell at you. Send a worded letter to the fine folks at The MathWorks in Natick, MA, if you feel this should be included. Alternatively, there is a package on MATLAB Central that may be helpful in this.

As always, other features of these two commands can be found by using the MATLAB help system, either ‘help saveas’ or ‘help print’.

One quick note about path names: throughout MATLAB, strings and variables for strings can be concatenated on the fly using the square bracket notation. This comes in handy with long path names and automating file saving in a script. The notation can be used in the following way:

ext = '.fig';
path = '~/Desktop/';
file_name = 'fig1';

The saveas command now becomes:

saveas(gcf, [path, file_name, ext], 'fig');

Note that there are no single quotes around the variables; the strings in the variables automatically get substituted for the concatenation. Again, variables and strings can be combined here:

saveas(gcf, ['~/', file_name, ext], 'fig');

will save the figure now in the home directory. Just know that this option exists — it is useful for me quite often. Hopefully all of this is useful to someone out there in the world, too.

Field testing the Garmin 310XT

People who know about my running problem know that I am also not disciplined. Running is way too fun for me to treat it with real goals and stuff. My goals for running are pretty simple: go somewhere cool and enjoy doing it. Of course I could take the train and accomplish that same task, so there is the component of the sheer motion of running that I absolutely love. The rhythm of running is a beautiful thing to experience, and I am thankful every day that I am able. That said, it also turns out that, perhaps owned to my scientific and analytical nature, I am intensely curious about all the sorts of numbers that one can assign to running. How fast am I going? How far did I go?

When I first got a heart rate monitor (HRM) about three years ago, I was intrigued by the simplicity of the measurement. My first HRM was a Suunto T3, and I managed to wear out the heart rate strap and break it after about a year. As a replacement I moved up to the Polar RS200, a watch that is marketed as running specific and even features a dot matrix running man on the time display. Polar are clearly the heart rate gurus, having invented the technology so many years ago, but the pace of technology has quickly learned to keep up, for the most part. The RS200 was not without its shortcomings, which took me about a year of running to fully appreciate. It only holds the last 16 workouts. It has 3 lines of data. The lap button isn’t fool proof on the run. And most importantly, to get any notion of how speed and distance progress over the course and during a run, one has to rely on a crude approximation given by the speed and distance sensor that attaches to the shoe, powered by 2 heavy AAA batteries that frankly didn’t last a month of running.

It was fun while it lasted, and while I’ve had my eye for awhile on the Garmin Forerunners, I wasn’t ready to go for it until Garmin caught up in the following, relatively minor areas: battery life and heart rate strap comfort. For GPS technology tracking distance and, combined with time, speed, it is incredibly appealing, considering the amount of trail running I do, where it is hard to estimate distance, especially given the amount of time I spend lost and running around in circles. Figuring out pace and “performance” is always tricky, and I admit I like to know at the very minimum how far I’ve gone and how long I was out there.

Enter the 310XT. It sounded like the answer to all of my problems, and I couldn’t have gotten ahold of one fast enough. Just in time to be a pacer at my first ultramarathon, the Vermont 100, I put it through a couple of short runs to get used to it and familiarize myself with it. Additionally, I was able to use it for the entire 17 hours and 22 minutes I was pacing at the race (63 miles) on a single battery charge. While I didn’t quite push it to the advertised 20 hours, 17 is not bad and at least plenty for all races up to about 60-70 miles. I guess I’ll have to have a strategy for 100 milers.

Wolfram Alpha

I dunno, I’m not really impressed:

What could Apple’s ‘Media Pad’ be?

The rumor mill is buzzing with evidence that Apple will soon release two new wireless devices, what amounts to an iPhone micro and an iPod touch macro. It’s clear that the larger iPod touch-like device will not be a cellular device, though it may include the 3G cellular wireless internet technology. I have a specific interest in a tablet-like device whose screen is exactly 7.5″ x 10″. Here’s why.

The problem is that it’s nearly 2010. I seem to recall in the 90s being promised a future full of Jetsons-like gadgets. We are not supposed to have to walk from point A to point B but have those belt things you see at the airport. Cars should be flying by 2010. (Dogs should be talking?) And our offices were guaranteed to be paperless by now! We are quite far from the paperless office, specifically, and I want the Apple’s iPod touch macro to be a media pad that helps fill this gap. What will it need to do to succeed?

1. LED-backlit high resolution LCD: 7.5″ x 10″. It’s the size of a sheet of paper, minus the margins. Small form factor but all screen. And readable.

2. One USB port, 802.11n, bluetooth, mini-DisplayPort, and optional wireless 3G. This is the bare essentials for ports. One USB port for universal connectivity. 802.11n for fast internet access. Bluetooth for connecting external keyboard and mouse if desired (someone will make a kickstand for this simple device). Mini-DisplayPort so it can give presentations. And finally, I say optional wireless 3G because I have absolutely zero intention of buying something that requires a monthly service contract. I simply don’t want it.

3. 8 GB solid state drive. Enough space for applications and some music, perhaps. No moving parts, please.

4. Touch gesture controlled but with stylus input. While it’s clear that multitouch is the future of a specialized device like this, the stylus input will be key, though auxiliary. The stylus will be crucial for utilizing the Ink Well software already part of Mac OS X.

5. Operating System. It’s clear that this device will have to run some variant of Mac OS X. As I see it, Apple have 3 options for an operating system. They can go with the iPod touch/iPhone model of downloading apps from a controlled source (iTunes store). They can go with the full Mac OS X model and open the device up to any software on OS X. Or they can go the Microsoft route and brand yet another version of OS X with ambiguous “Media Center” differences and confuse branding on their stellar OS. To me, the full OS X model is the way to go here. The primary reason for this is users should be able to run all of the wonderful software available to OS X currently, without limitation. Merging contents of the iTunes store will make that space confusing, as apps compatible with the iPhone/iPod touch will likely not be compatible (at first) with the new media pad device. Nevertheless, I can completely see Apple erring on the side of control in this case, for at least the perceived reason of protecting the 3G network from malicious programs. Of course, as with all attempts at DRM type control, this can and will be circumvented. Why confuse the space unnecessarily for marginal benefits?

6. Software – PDF Reader Example. There is one piece of software that I’m going to focus on, in order to give an idea of what such a media pad device can accomplish. It’s a simple PDF reader, on its face. PDFKit driven, the model in my mind here is Skim.app, a freely available program that takes full advantage of PDFKit’s annotation and note-taking capabilities. Consider being able to underline, write notes, and mark up PDFs on the go in a digital format, where your notes are automatically converted into text and your underlining/highlighting is automatically converted into digital underlines. Saving this file will make all notes transportable to other devices or printable. Furthermore, one can zoom text effortlessly with the multitouch features already demonstrated in multitouch trackpads on Apple laptops and on the iPod touch/iPhone. To be able to keep a library of PDFs on this device will solve the problem for paper that the mp3 player solved for music: while a CD player requires carrying CDs and cumbersome switching, the mp3 player can now have dozens or hundreds of albums in a convenient form factor. The Media Pad device will allow us to become more mobile with more documents.

7. A few other issues. Give us a thin bezel, please. Battery life should be reasonable. The device should be thin. While a sync feature would be in line with the iPod touch model, I still prefer a full on OS X device model. Perhaps there could be a compromise here. It’s also clear that this device will require its own special developer tools to take advantage of stylus transduction and multitouch interaction. Apple will do well on this, if their past is any indication. Finally, I think Apple needs to seriously look at their anti-aliasing to make this device very readable on screen. e-Paper is not the solution, until refresh rates and color are both substantially improved; however, e-Paper is very readable.

I’ve been thinking about a device like this to solve many of my problems as a scientist whose life of reading revolves largely around the PDF article. I suspect that other professions also could use something like this, especially in the software model in which any arbitrary application can be created to take advantage of this device.

Mac OS X Exposé – flip through different applications

Here’s a quick tip for Mac OS X Leopard’s exposé feature that I just encountered by accident. If you activate Exposé, in either the application windows or all windows mode, you can use splat+tab or splat+~ to move back and forth between open windows of each application. This is very useful when you have dozens of windows open, because they are now contained within each individual application space.

Note: splat is also known by its inferior names as “command key” or “apple key”

.bashrc by example

The learning curve for .bashrc is very broad and takes patience or a very good tutorial. Here’s a happy medium between those two.

Basics:
Bash is a shell that allows you to enter commands at the command line. It’s a very robust program that allows scripting, variables, and a whole host of other features you may/may not ever use. If you’re interested in learning about it, there are a lot of great books on the subject.

If you don’t know what shell you are running on Mac OS X or if you’re new to Linux, try opening a Terminal window and typing this:

echo $SHELL


That will tell you the full path of the shell program you are using. For instance, mine is ‘/bin/bash’.

Bash reads from several files in a prescribed order, depending on various circumstances. This can allow for customization or be very confusing, depending on how sophisticated you want to be. I’m only now getting a sense of why that could be useful, but let’s ignore that for now. I tell bash to basically look at one file for all my shortcuts, etc., so that’s what we’ll set up here.