The blogosphere has been abuzz with analysis of last week’s episode of Mythbusters, in which they tested Jamie’s assertion (from a previous episode) that two cars crashing into each other at 50 miles per hour is the same as one hitting a wall at 100 miles per hour. OK, well, that turned out to be wrong.

I didn’t have the time to write about it just after the episode and there’s no point in me repeating what’s been said about it elsewhere, but I do want to point something out: the reason it was wrong is that in one case, a car crashes into another car, and in the other case, it crashes into a wall. The car and wall react differently in the collision — the car compresses, the wall doesn’t, so when there are two cars involved, the energy of the collision gets split between them. There isn’t any fundamental difference between two objects crashing together at 50 miles an hour and one object at 100 miles per hour crashing into a stationary one.

I would have liked to see the Mythbusters test one car at 100 miles per hour crashing into …

In the 22,000 Foot Fall episode of Mythbusters, Adam did a calculation of how long it should take for a falling person to reach terminal speed. It occurred to me that there’s a wrong (but simple) way and a right (but complicated) way to do this calculation — I wonder which one was used on the show to come up with 487 feet?

First, the simple way. From numerous tests in previous episodes, the Mythbusters know that the terminal speed of a person falling through air is about 120 miles per hour. Based on that, you could try to figure out the fall height it takes to achieve that speed using the formula

(It’ll become clear later on why I’m calling the height \(h_0\)). This formula comes from the kinematic equation \(v^2 = v_0^2 + 2ad\) with initial velocity \(v_0 = 0\), final velocity \(v = v_T = \unit{120}{\mileperhour}\), and acceleration \(a = g = \unit{9.8}{\frac{\meter}{\second^2}}\). Plugging in the numbers and calculating gives

That’s reasonably close to what Adam got on the show, so I’m guessing this is the method …

The latest episode of Mythbusters features a myth with a deep physical explanation… no pun intended! Well, maybe. Anyway, the myth is that by diving under the water, you can escape injury from an explosion occurring above the surface. Adam and Jamie tried to solve this puzzle by experiment (what else), and their results seemed to show that the myth might actually be true, but I want to look at it from the theoretical standpoint: why might being underwater protect you from an explosion?

There is actually a not-too-obscure answer to this puzzle, and it has to do with refraction and reflection. These are phenomena that occur when a wave (of any sort — light, sound, or whatever) crosses a boundary between two media in which it has different speeds. Part of the wave bounces back (that’s reflection) and part of it continues through, but in a different direction (that’s refraction). Exactly how much of the wave’s power is reflected and how much is transmitted through, as well as the new direction of the transmitted part, depends on the angle of the incoming wave with respect to the surface, and also on the relative speed of the wave …

The Mythbusters are back! In their first episode of the new season, Adam and Jamie tested the myth that a cup of soda casually thrown out a car on the highway can smash through a windshield and kill the person sitting behind it. (Technically busted, but still really dangerous!)

One of the major factors that determines whether or not a projectile (like the cup of soda) will be able to smash a windshield is the force exerted by the cup on the glass. On the show, the Mythbusters used a piezoelectric force sensor to directly measure the force exerted when a cup of soda/ice/slush impacted on a steel plate, but we can also try to calculate the force using Newton’s second law,

First some simplifying assumptions are in order. I’m going to start by assuming that (1) each part of the cup and its contents continues to move at constant velocity up to the moment it impacts the plate, and that (2) after impacting the plate, the soda/ice/slush flies out in a direction perpendicular to its initial trajectory, along the plane of the plate. Of course, I wouldn …

I haven’t posted anything in a month. Not that it matters, since nobody really reads this, but in case you’re looking back at my archives from 5 years in the future and wondering why I haven’t posted anything in a month… I’ve been busy. Writing long involved posts takes more time than I have in the middle of a busy semester of grad school.

What I’ve actually noticed is that I tend to make Facebook status updates frequently. Or, well, at least there are little snippets of things that would work well as Facebook status updates, but I wind up not posting them because they’re boring, and besides, that’s what Twitter is for. Maybe I should have joined Twitter. Hmm… now what if I had my own Twitter? Well, hopefully at some point soon I will. I’m rewriting my website yet again, and this time I’m making a few key improvements: (1) it works (2) it looks better (3) no outdated content (4) probably microblogging, and it should — no, will, because I’ve done it and I know that it works — be easier to add more cool features in the future …

One of the things everybody points out about git is that it’s a fairly complex system. Of course, other version control systems like Subversion are complex as well, but git doesn’t seem to do as much as the others insulate you (the user) from what’s going on “under the hood.” Case in point: the difference between merging and rebasing.

Merging was a simple enough idea (not) to get used to when I was using Subversion. Basically the idea is this: you have your copy of the versioned material (in Subversion: the working copy), and somewhere else there’s a remote copy of the material (in Subversion: the repository). When both your local copy and the remote copy have been modified since they were last synced up, you have two sets of changes to the same data: your local changes and the remote changes. If you’re going to sync your copy to the remote copy again, you need to combine those two sets of changes. The way Subversion does it for you is a two-step process (which in Subversion terminology is called “updating”):

1. Compute what (remote) changes were made to the remote copy since you last synced …

I’ve been watching git with interest for a while now, because the concept of a distributed version control system — one where you don’t need to contact a central server to make a record of your recent changes — would go pretty well with a lot of the things I use version control for. (Not just source code, but managing homework and papers that I type up in LaTeX) I’ve been stuck on Subversion for a while, mostly because I have a nifty GUI for Subversion for which no worthy equivalent exists for Git, but lately I realize I’ve been using the standard command-line client most of the time. So why not take the opportunity to switch over to git? (Plus, I wanted to get a nifty new toy to play with ;-)

One thing about git which took a couple days to really figure out is the idea of having a repository in every working copy. They say this in all the documentation but somehow I never quite got it until trying it, so I’ll repeat: a git working copy is like an SVN working copy with its own built-in, private repository. In SVN, when you commit …