A new hobby

The lack of recent posts is due to (blamed on) four things. First, I have been very busy at job #1 (research). Second, I have been very busy at job #2 (hardware/software development). Third, job #3 (classes) will begin Monday. And fourth, I have a new hobby: cycling!

As mentioned previously, my bike was stolen some weeks ago. It was a fairly standard hybrid affair, produced by Giant. Such bikes are prime targets for thiefs however; I kept it outside (where it routinely was rained upon) and while it was not directly visible from the street, its theft wouldn’t require ninja skills.

I began to look for a replacement. As I researched more I found myself becoming quite interested in cycling in general. In the past I’ve ridden when it was convenient, but for whatever reason the sudden loss of a bike made me very interested in bikes! I decided that what I wanted was a classic 10-speed racer from the bike boom era, either a post-WWII bike or something from the 60s or 70s.

I found the following bike on Craigslist, being sold by a couple in Gainesville. This is not the bike, this is a catalog picture. It is a 1968 Raleigh Super Course (I determined the year by the shifters and brakes).

Raleigh 1968 Super Course catalog page

It’s a great bike. It has original everything except for tires, and it rides great.

This post isn’t really about the bike though, but about the hobby. When I learn a new skill (and to be sure, despite having ridden bikes for many years, I am still learning to cycle) I like to learn how to do it The Right Way. That means I’m learning proper pedaling form, how to work on my cadence, how and when to change gears, and so on.

I’ve learned a few things so far:

1. When I have to stop I need to do three things: shift down with my right hand, unstrap my right foot with my right hand, and brake with my left hand. Invariably it is the unstrapping that I neglect, until I find myself at a stand-still on two wheels, strapped into the bicycle. At which I tip over comically, and end up on the ground (still strapped in).
2. Shifting down is harder than shifting up. To shift up, I simply throw the lever up (these are friction shifters). To shift down I have to pull the lever down until the chain derails, then slide it back up to center the derailer. Too far in either direction and I either shift too many gears or immediately shift back to where I started.
3. Eating and drinking the proper amounts and types of food makes a marked difference in performance. I’ve been focussing on eating multiple smaller meals (breakfast, snack, sandwich at lunch, snack and sandwich in the evening, dinner at night) which makes sure I have the energy when I head out. When I get back, I try to eat a solid meal within an hour (when the body is about 4 times as efficient at converting carbs to muscle). I keep my water consumption even throughout my rides.
4. I get exercise headaches. I always have, and it’s pretty annoying because when they occur I’m out of commission for a few hours. Riding over a painted line on the road with an exercise headache throbbing jars my head and spine to the point of tears – and that’s no exaggeration. I’ve found that the best way to avoid these headaches is to ride with my head up for a short time after drinking anything on the bike, and to never drink large amounts or rest for longer than 5-10 minutes.
5. I hit my stride about 5 miles into a ride. Before that I feel weak, burnt out, as if I’m going slow. I don’t know why this is. After the 5 mile mark, however, I’m feeling better and getting into the rhythm. I stop thinking about my breathing and cadence and just let it happen. At 10 miles I feel like I could go all day (unfortunately most of my rides are at night so 10 miles out, then 10 miles back, is about all I have time for). I think this is because I’m thinking too much during the early part of the ride, but that’s hard to stop doing.

I love the technical aspects though. I love reminding myself not to squeeze the bars too tightly, to adopt the “tipped bowl” position on certain stretches and the areodynamic “humped back” on others. I enjoy practicing judging the proper moment to shift when approaching a hill. I like watching my eyeline, focusing on which muscles I’m using to lift my legs on the back end of a stroke, and all the other technical aspects of cycling. When I catch myself doing one of these things successfully without thinking about it, I’m proud.

I have very weak thighs; Hani (lovingly) compares my legs to that of Big Bird. As a result I much prefer riding on flat roads. The best part of my usual ride is the long flat run of 441 past Paine’s Prairie, especially when I time it so I’m riding back during sunset (the sun sets in front and to the left of me, over the prairie).

One of my goals is to ride the Horse Farm Hundred, a century organized by the Gainesville Cycling Club. Right now I can ride 20 reasonably flat miles without much burden, and don’t have the daylight to try much more. I think I could probably do 30 or 40 without blowing up, but I need a frame pump to bring along before I try. I don’t fancy having to hitchhike back to Gainesville with a busted tube. I’m getting better quickly, however, so with any luck I’ll be up for a century next year.

Ultimately I’m not that great on a bicycle. I can’t sprint, I struggle up hills, and I have an unfortunate tendency to forget I’m strapped in and find myself on the ground looking foolish at a red light (or behind two chatty students on campus who just wouldn’t listen to my requests to step aside). But I enjoy it a lot, and it’s good exercise, and I love learning about and practicing the technical bits.

Advertisement

 

Progress update

Today’s post is a competition: I have code running, the results of which I need to see to proceed. When the program terminates I will wrap up this post; thus the briefer this update, the faster (and better) my program must be!

Thrice I’ve attempted to write up comprehensive summaries of what I do, both at school and at work. Thrice I failed; I think that the topics are too involved to summarize succinctly. I always find it difficult to choose a “stopping point” in any explanation: ask me a technical question and I may open with “In the beginning…”

At school I am writing code to prove a particular statement. Originally my goal was to prove error bounds on an existing program that used an approximate technique; I would have shown that no amount of rounding error that could have occurred was great enough to cause the program to say “no” when it meant “yes”. At some point I determined that the program could be written to answer the question exactly, without approximation, and so started work on a new version.

Tap on the hourglass and it’s several weeks (months? I don’t have a good grasp of time estimation.) later. As of today, all of the functionality is in the program and theoretically it is a complete “first run”. (My boss likes to say that a program is only “done” when you can’t stand to look at it anymore, so this code is far from finished!). The new program answers the question without approximating and also runs significantly faster than the old program.

The next step is to write a paper on the purpose, methodology and results of the program. I have yet to establish the exact scope of this paper; I am very new to this work and most of what I do involves ten steps of gathering background information before taking one step forward.

Today, then, is a bit of a milestone as I have a somewhat complete suite of programs that produce some actual results. Granted, I’ll probably look back in 6 months and think “gee, that took me how long?”, but there it is.

Things are progressing slower at work. One of the the company’s main products relies on a component for which production has ceased (but will remain available for a while); my job right now is to design the next version of the product, replacing the component in question, and supporting an additional feature (a faster speed). I have been working on this since January and reached my second functional prototype a few weeks ago.

I should stop and say something about school-versus-work: my main priority is school and my research. I work part-time, which accounts for some of the slow progress. Research is more intellectually stimulating and interesting, while work is more physically rewarding. I can prove a theorem at school and then go home and see my device function – the combination keeps both subjects fresh. I find that when I’m just getting tired of looking at my code run at school I’m ready to go home and start work, and when I’m just starting to grow weary of paging through the USB spec at work I’m ready to head to school and get back to math.

Back to the subject of work. I finished my second prototype and began the next stage of design. Unfortunately I am being bogged down by intermittent bugs that are dependent on external behavior. For the past few days I have been fighting with this problem and have yet to make any headway.

I find that my progress at work comes in short bursts of enormous productivity which are then halted by difficult-to-detect mistakes. I will likely spend the next few days working on the current problem, but then complete the rest of the third iteration of the code in a series of marathon sessions over the weekend. Knowing this doesn’t make the bugs any less frustrating, however.

So while work moves slowly I have reached an important point in my research. With any luck I’ll find a breakthrough at work in the next few days and make progress on writing the paper for school.

My code has terminated, telling me I am finished with this post. The program yielded the expected answer: 12. Gee, all that work for 12? I could have told you that!