Running goals for the new year
Let’s look back at the last decade of running, shall we? Let’s make it a 12-year Doublewood, or else this decade’s running would really only include two years.
1998: I ran 4-8 miles each morning before school, which started at 8:30 am. It was the last time I was ever considered a morning person.
also 1998: I ran my second race in my life, a Twilite Fun Run 5K held by a local radio station. I spent the entire race chasing some 12 year old kid who was faster than I was. My first memorable race was actually in first grade, a footrace probably about 30 or 40 meters, and I slid into third place. It would be my only podium finish in my running history. Oh, there were three competitors.
1999-2007: I probably ran a good 50 times between 1999-2008.
2008: I logged 581.9 miles from June 15 to December 31. The longest run was 18 miles. The longest week was something in the 63 mile range.
2009: I’ve thus far logged 1,058.6 miles from April 19. Considering the weather report for the next couple of days, there’s little chance of logging very many more, since I go in these spurts of fighting the good fight against the weather and being ultralazy with it. Anyway, I paced for 53 miles (and ran about 63 miles) at the Vermont 100 miler and met some great folks. I went on to run the Vermont 50, my first official ultra, under pretty horrible conditions, and despite it being a frustrating experience, it was an incredibly rewarding one. 2009 Update: Total miles for the calendar year are 1,069, after today’s fun snow storm run!
My running goals for 2010 are, in no particular order:
1. Continue running healthy and consistently
2. I should be able to bag 1,500 miles from Jan 1 to Dec 31, if I can fulfill No. 1
3. Run Mt Washington Auto Road (7.6 Miles, +5,000 ft.)
4. Run (2) 50 Milers (Vermont and … ?)
5. Run (1) 100 Miler (Vermont?)
I feel like these are actually a reasonable set of goals. I came into the bitter cold of January of this year running sporadically, injured, and not logging miles from Jan to Apr. Here’s to a year of healthy running for all. See you on the trail!
Race training: just one hill
New England runners will surely catch the reference to the mother of all “hill” races in the Northeast: the Mount Washington Auto Road Race. It’s a 7.6 mile race that climbs almost 5,000 vertical feet. There are those among us who love running hills and running in the mountains, and this is sounds like a grand ol’ time for us. So far, this is really the only road race I’m interested in right now. Unfortunately for me, I don’t have the best training ground in flattened Boston for success at ol’ Mt Washington, and winter weather awakens the laziness in me far too frequently. But I can solve both of those problems by putting a temporary hold on my feud with the Dreaded Treadmill, which is actually pretty useful in simultaneously flipping off the winter windchill of -16°C and allowing me to do sustained runs on an incline. The best I can do locally have been my series of hill runs that are more like roller coasters than reasonable hills. Practically in my backyard is actually the best local hill, Summit Ave, which rises a measly 250 feet or so over the pedestrian 0.42 miles. It’s plenty hard, actually, but I really need to be able to run a bunch of Summit Aves, in a row, without having to backtrack down the hill every not-even-half mile. I’m no Rickey Gates (current champion), but I’d like to be able to run Mt Washington strongly. So today I guess I officially started my Mt Washington Auto Road “training,” with a simple but effective 15 minute session on the treadmill at 10% grade, followed by a short rest and then a climb from 6% to 15% in 1% increments every 10 seconds, just to get a feel for the variety. This was plenty hard, and I’m not even in the worst hill running shape ever. It’ll be a fun goal to aim for. Anyone who wants to run hills with me is always welcome!
Numerical solver design
Numerical solver design is a topic that I know next to nothing about. I always say I know a tiny bit of MATLAB very well, but lately in my push to become MATLAB-independent, I’ve been trying to remove bits of proprietary code from my own simulations. (My transition from MATLAB to Octave failed in part because of memory issues in Octave. So I’m now looking at Python as my potential free software savior.)
The biggest hurdle has been my usage of the suite of numerical solvers for ordinary differential equations (ODEs) in MATLAB. These are fast, vectorizable to some extent, and take advantage of some parallel processing on multicore machines. However, using their solvers presents a number of problems when one wants to understand the ins and outs of their algorithms. It’s not that this information isn’t there (using ‘type’ or ‘help’), but the problem with going through code that isn’t yours is an ugly one that isn’t going away soon. Additionally, it’s never been completely clear under what circumstances MATLAB’s solvers start to make use of multiple cores and why that process should be accurate, despite seeing evidence of multicore usage at some level of scale in my own code, with ode23s. And there are some things that I don’t know if MATLAB’s solvers can do well. For instance, I have MxNxT matrices of a dynamical variable connecting M model cells of one type to N model cells of another type, saved over all T time steps. Tracking all of these variables and the some ~20 other variables of varying lengths becomes a real code nightmare in vector forms without name labels, which are available in structs. Of course, there is speed in vectors that isn’t available in structs — speed that I am willing to sacrifice for sanity.
The real bottom line for me is being able to write some MATLAB code that I can easily translate into a Python environment eventually. This process will take a lot longer than I had hoped. By writing solvers now, I hope to be able to take them with me and get some insight into solver design for future projects.
Using structs in a solver. In MATLAB’s ODE solvers, they require a strict type of vectorization that has time in one dimension and all of the dynamical variables in the other dimension. I have synaptic weight matrices that are MxNxT, for M of cell A going to N of cell B, throughout time T. Because of the dimensions of these are tricky to code in MATLAB directly without a lot of transposes and other confusing situations, I was hoping to use structs to name my matrices and make it easy to write vector field equations in a clear manner without having to write confusing converters. It’s not completely out of laziness that I want to avoid doing this; rather, another conversion step introduces one more place where error can be introduced.
It turns out that using structs is not a good idea with the separate solver/vector field design, since it seems like you’d spend too much computational time translating anyway. Translating once in a difficult way but gaining speed is far better than translating thousands of times in an “easy” way, at some unknown expense of speed. I might try next a two-matrix approach: one for class A cells and one for class B cells, which does not make this a general solver but will allow for easier vectorization.
Variable passing to a function using a solver. In Matlab, one thing I had trouble learning early on was the method by which one passed variables to the vector field file via the solver. The syntax might look like:
[t, y] = solver('vf', t_range, y0, [], var1, var2, ...);
For the outputs, we have simply the t vector and the numerical solution y for the system, which is specified in the vector field function, in this case ‘vf’. The range of times and the initial condition y0 should be passed to the solver, which uses ‘vf’ to solve the system. Now if the function ‘vf’ requires inputs, which is not uncommon, in order to pass them to ‘vf’, you have to pass them through the solver first. If you want to pass ‘var1′ and ‘var2′ to ‘vf’, notice that you cannot simply specify these variables after the ‘y0′. Instead, in this example, there are empty brackets. These empty brackets are actually part of the solver’s input syntax to allow options to be passed to the SOLVER and not to the VF. The reasons for this are very clear to me, as I code my own solver and recognize that this is exactly how my solver ended up being coded. The solver needs the ability to accept options, and they need to come into the fixed location here. Any additional arguments passed through the solver can then be understood as variables to the vector field. While it seems reasonably obvious, I understand it much better after having tried to figure out this design from first principles.
The kilomile
A lot of runners chase the 1,000 miles per year distinction. It’s kind of a nice, round number, so it’s a fun goal to aspire to. I’ve been logging miles on RunningAhead since mid-June of 2008. Today, on a run with RH, I completed my 1,000th mile (i.e. the kilomile), which ended precisely (plus/minus) at GYT’s house, complete with finishing line tape, applause from a live studio audience (or a recording thereof), and donuts. More specifically, I had a Boston Creme filled donut and a curious red one that may have been a Red Sox themed donut. I stayed for the Boston Creme donut and had to take the red one to go but finished it on the run home. I go on these long stretches of donut cravings, which have recently been supplanted by a muffin craving. The inter-event intervals of muffin consumption (which is not some horrible muffin-related disease as the name may suggest) is far too long, since I feel like it must take a special occasion (like KRMS birthday surprise) to go to Wakefield MA and get muffins. Anyway, I feel strongly that there is a class of pastry related cravings that this runner has that actually can be satisfied by any member of the genus Pâtisserie, though sometimes the craving is specific, most often for Pâtisserie frittericus.
Oh, to anyone with whom I’ve run over the past kilomile, many thanks. I’ve run with dozens of people in that time for just a few miles and just once. I’ve run with a few people very long distances just a few times. And I’ve run with several people, short and long distances, many times. Here’s to a thousand more miles with you all. Let’s share a donut.
Some stats:
Apr 19 – Dec 6: 1000.8 miles (logged)
Total time: 168+ hours
Longest month: September, 235.3 miles
Shortest month: October, 50.6 miles (guess who overdid it in Sept?)
Longest single run: 63 miles
FIFA World Cup 2010 Group Predictions
Today the FIFA World Cup 2010 South Africa groups were drawn. I don’t have my finger on the pulse of football as much these days, so most of this will be more established wisdom than anything particularly groundbreaking, but here goes some early predictions. Of course, anything can change from now and next summer, so it’s all tentative.
Group A:
I don’t think the hosts have ever missed the Round of 16, and yet in this draw there are so many situations in which that scenario seems likely, on paper. But with the whole continent behind them, and hopefully with a little more disorganization and all eyes on the hands of French strikers (ahem), I think that South Africa do have a chance at moving forward. Of course, any good American understands that our friendly rivalry with our southern neighbors means that we do not wish them well, and actually, it’s not hard to imagine Mexico getting ousted in the opening round. Uruguay are back into the Finals after a long hiatus, and they are certainly not the dominant footballing nation that they once were, long ago. Nevertheless, where my head might be inclined to think that French Coach Raymond Domenech and his squad might get their act together in seven months, my heart is really hoping that the hosts and Uruguay move into the next round: one for the home team and one for old time’s sake.
Group B:
Speaking of hearts, it’s difficult to see the outcome of Group B objectively. While Argentina might be an obvious choice to advance at the top of the table, their seemingly ill-placed faith in Diego Maradona at the helm could lead to their early exit — the shame of a nation. Of course there’s always a chance that El Diego takes them to their former glory à la 1986, but that’s a very long shot that I’m not putting money on. And I do have the next several months of trash talking with my Nigerian friends to look forward to, but in reality they are a strong squad who could do interesting things in South Africa, especially with their effective home field advantage. But my heart is true; there’s no way I can discount the speed and tenacity of a fiery South Korean squad who are pretty stable and no doubt motivated in part by the North Korean presence in the tournament. I guess for the sake of some peace over the next few months with the Nigerians, I’ll say Nigeria and South Korea advance, while Argentina make the first round exit due to their skipper. Oh, how I hate to bet against Argentina, though, my adopted nation. It will be Argentina and South Korea. Nigeria, you are going down in 2010! Bring it!! Also, see you in 2014, Greece. It’s not personal.
Group C:
I think it’s clear that the favorites are England and the United States. One/two ranking is important for the Round of 16, and I will give the upper hand to England, especially with the critical loss of Charlie Davies recently to a non-fatal but horrific car accident (here’s hoping for his full recovery). It could however come down to a goal differential if England and the USA tie, since England are traditionally poor performers in the World Cup (that isn’t hosted in their backyard, ahem).
Group D:
While Germany and Australia are the favorites here, there is a lot of young Ghanian talent, and I would not be surprised if Ghana were able to best either Australia or, dare I say, Germany. Germany will likely advance, but Australia despite their scrappy play may just turn up slightly short, which is a minor tragedy since they’re a talented squad.
Group E:
With a group of the always-powerful Dutch, I expect them to come out on top. They got a friendlier draw this year, compared with their Group of Death draw in 2006. The real fight will come for that second spot, and I hope that Cameroon enjoys home field-like advantages that propel it to the top of that stack. Having such an incredible striker as in Eto’o cannot hurt that cause.
Group F:
Italy in theory should have no trouble moving forward, and I expect to see a lot of Italian defense after they score once or twice early in each game. I suppose Paraguay are the logical next pick, but honestly, so long as Italy advance, it doesn’t matter a whole lot to me.
Group G:
This group contains North Korea, who are making their first World Cup Finals appearance since 1966, when they famously beat the Italian powerhouses 1-0 and managed to give up a 3-0 advantage to Portugal. Expect Brasil and Portugal to easily take this group, though I suspect that Cote d’Ivoire will not go silently into the night, and I also will make the not-so-bold prediction that Cote d’Ivoire will come close to beating Brasil, a team who show up in big games but seem to only manage to barely arrive in early round play. This is in contrast to Portugal, who start strong in tournaments but traditionally fade late. I expect Portugal/Brasil to go 1/2 in that order.
Group H:
In the group containing Spain, Switzerland, the Honduras, and Chile, I suspect most are thinking Spain and Switzerland. But really in my mind, that second place berth into the Round of 16 is probably a crapshoot at this point. I think the Honduras have the ability to surprise at the world’s biggest stage; they could be an interesting dark horse team in 2010.
I honestly don’t see a crystal clear Group of Death in 2010. There are a lot of quality sides however vying for Round of 16 spots in some form or fashion, and this may be either one of the most entertaining finals ever … or one of the dullest.
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.

