1. 2010
    Apr
    25

    Calculating terminal speed

    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

    $$h_0 = \frac{v_T^2}{2g}$$

    (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

    $$h_0 = \unit{147}{\meter} = \unit{482}{\foot}$$

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

  2. 2010
    Apr
    22

    Velocity addition: a myth?

    On the episode of Mythbusters aired a couple weeks back, Kari, Grant, and Tory set out to test the myth that if you have a car driving forward at, say, 60 miles per hour, and you shoot a ball out the back at the same speed, it will fall straight down. Now, if you know anything about physics, your first thought upon hearing this might have been the same as mine: “huwhah?” The idea that velocities of equal magnitude and opposite direction cancel each other out in this way is a pretty fundamental result…

  3. 2010
    Apr
    06

    Shockwave reflection

    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 …

  4. 2010
    Mar
    30

    Soda Cup Killer

    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,

    $$\vec{F} = \ud{\vec{p}}{t}$$

    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 …

  5. 2010
    Mar
    10

    Catching spam comments

    Here’s something worth sharing: I get a lot of comments on this blog. Well, not a lot really, but probably on the order of a hundred every week or so. All of them are spam. And they all have one really obvious thing in common: they’re all written in HTML. So they all start with <p>, which makes them really easy to identify. Now there’s something to put in my spam filter, whenever I get around to making a decent one.

    EDIT: now silly me… it’s my comment posting/formatting code that adds in the <p>, not the spambots. So that tactic goes out the window. But I’m still pretty sure I’ve never actually gotten a legitimate comment. (If you know otherwise… leave a comment? ;-)

  6. 2010
    Mar
    10

    Maybe this blogging thing isn't working so well after all

    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 …

  7. 2010
    Feb
    08

    More git for newbies: merge vs. rebase

    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 …
  8. 2010
    Jan
    30

    Acclimating to Git

    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 …

  9. 2010
    Jan
    18

    SIP/PyKDE

    I just tried to test a plasmoid written in Python and got the initially confusing error message

    the sip module implements API v7.0 but the PyKDE4.plasma module requires API v6.0
    

    It wouldn’t be noteworthy except that my usual technique of Google-searching to find someone else who had previously encountered (and solved) the problem turned up nothing, except some discussion on the ArchLinux forums that didn’t seem to be too closely related. Anyway, for the benefit of the internets: this happens when the version of SIP you have installed is a new one, released since the introduction of the version 7 API, but your installation of PyKDE is an old one that still thinks it’s working with the version 6 API. The solution? Upgrade to the latest version of PyKDE, or recompile it if you installed from source. On Gentoo, a simple

    emerge -1 kde-base/pykde4
    

    did the trick.

    Just so it’s out there.

  10. 2010
    Jan
    12

    The most complicated simple way to count paper

    In an introductory TA meeting today we had to split up a large pile of survey consent forms for the students to fill out later these week — 24 to each section, for 4 sections per TA, that’s 96 sheets of paper. Well, who wants to count out 96 sheets of paper? So my friend had the good idea of optimizing the procedure by weighing 12 sheets and calculating the mass we’d need to fill out the required 96. OK, but of course we needed to properly arrange the papers on the scale so they weren’t partially being held up by the attached cables, and then, being physicists, we’re no good at mental math ;-) suffice it to say we were pretty nearly the last ones out.

    And that was a lousy story. Oh well, guess you had to be there…