How Dangerous is the Samsung Galaxy Note 7? It’s Safer than Driving

Now that the Galaxy Note 7 has been officially discontinued, I’m not sure it’s worth worrying about the failure rate of this device. But there’s something that really bothered me about the coverage of the device’s various recalls and eventual discontinuation (is that a word?), which was that almost nobody seemed to be running the numbers on the actual failure rates.

If you do the arithmetic on the device failure rates, you end up looking at the situation rather differently. This is not to say that the device being discontinued was the wrong decision — all it takes is one person being horribly burned to create a panic and do serious damage to the company, not to mention that person!

Rather, I think it’s interesting to do the arithmetic as a way of exploring how humans think about risk. It may not surprise you to hear that I think we are really bad at this. And oftentimes it’s because we don’t run the numbers.

With that said, let’s look at some numbers.

According to this article on the Galaxy Note 7 recall, there were about 2.5 million devices sold in the initial batch, and, at least in early September, there had been 35 handsets discovered with the issue. A later report said that over 70 devices had overheated.

The best final count I could find is the one from the Consumer Product Safety Commission. According to the CPSC, there have been 92 reports of the batteries overheating.

How much danger was I really in? (I just returned my Galaxy Note 7 yesterday, which I LOVED, which is part of why I’m writing this.)

  • 2.5 million phones
  • 92 incidents of overheating

Turning to my trusty calculator, that looks like a 1 in 26,000 chance of the device overheating:

CL-USER> (/ 2.4e6 92)
26086.957

Expressed as a percentage, there is approximately a 0.004% chance that your device would have been one of the ones to overheat:

CL-USER> (format t "~6$" (* (/ 92 2.4e6) 100))
0.003833

However, let’s make a more conservative assumption that 1000 devices (over 10x as many) would eventually overheat. That’s still 0.04%, far less than one tenth of one percent. Of course, that number “less than one tenth of one percent” was quoted by Samsung themselves during the initial recall:

CL-USER> (format t "~6$" (* (/ 1000 2.4e6) 100))
0.041667

Eventually, the bad PR due to overheating devices grew to be too much, and Samsung discontinued the model.

One lesson of this incident seems to be that you can make a product that is nearly perfect, with a 0.0038% failure rate, but if the failure mode is bad enough (it probably is), and if the media exposure is widespread enough to create a public outcry (it definitely was), you’re fucked. With lines like this one appearing in the Verge, it’s not hard to understand why Samsung realized they had to just kill it:

It’s easy to imagine how terrifying it would be to have a phone begin smoking like this on a plane or on your bedside table. No thanks.

The mobile device hardware industry is brutal. You can’t have a failure that occurs even in 0.0038% of devices. And even if you maintain that near-perfect safety record you still have to compete on price, features, and time-to-market. I really don’t envy those folks.

But what about risk assessment?

What I find most interesting, as I mentioned above, is what this reflects about how humans assess risk. For example, in 2012, 92 people died in car accidents every day, and nobody has ever considered doing a recall of all automobiles sold in the United States for being fundamentally unsafe!

According to the chart linked above, in 2012 there were 10.691 auto accident deaths per 100,000 people, which means that you had a 0.001% chance of literally dying in a horrible car crash:

CL-USER> (format t "~6$" (* (/ 10.691 10e5) 100))
0.001069

Compare this to the 0.004% chance of your phone overheating that we calculated above (based on the 92 incidents figure). Given the rather imprecise way we’ve been slinging these numbers around, let’s just assume there’s a lot of error there, and that the figures are roughly equal.

That’s how we arrive at our conclusion:

You have as much chance of your Samsung Galaxy Note 7 overheating as you did of dying in a car crash in 2012.

(Note: this article and its headline do not constitute a claim that the Note 7 is “safe”, or that you should not return it as recommended, etc. This article is not advice on how to live your life, it’s just an exploration of how humans think about risk.)

Functions, Exponents, and Egg-Producing Hens

What is a function? One way of looking at it is as a rule that maps the elements of one set onto the elements of another. For example, given the set A = {apple, orange, pear}, and the set B = {red, orange, yellow}, the elements of A could map onto the elements of B like so:

         apple -> red
         orange -> orange
         pear -> yellow

The arrow represents the mapping performed by the function. In this case, we might describe the function f applied to x as “get the color of x”. Thus, f(‘pear’) -> ‘yellow’.

Some of my favorite functions are exponential functions, e.g., f(x) = c^x, where c stands for some constant (it doesn’t matter which – it could be 3 or 2.96e12).

Likewise, one of my favorite constants called e. The most practical applications of e have to do with measuring growth rates.

Say for example that you farm chickens for a living. Since your chicken farm is a small one (left to you by your grandfather, perhaps?), you have only 82 chickens. As you know, chickens lay a lot of eggs, so let’s assume that roughly 75% of the eggs are harvested to sell, and your family manages to eat or give away to friends another 5%. This leaves 20% or so of your eggs which will be fertilized and eventually hatch. Assuming a roughly even distribution of male and female chicks, about 10% of the eggs you produce will become egg-laying hens themselves.

Sitting around the kitchen table in the farmhouse one night, you decide that you’d like to double the number of egg-producing hens you have now. You wonder how long it will take, so you get out your trusty calculator and compute the following table:

Year Egg-laying Hens

0 82
1 90.2
2 99.22
3 109.14
4 120.06
5 132.06
6 145.27
7 159.80

It’s not too difficult; you simply multiply your existing number of hens by ten percent and add the result to the principal. Alternatively, you can multiply the total number by 1.1 every year – either way will work, and will eventually show you that it will take about seven years to double your stock of egg-laying hens at your current rate.

What does this have to do with e? Quite a lot, actually. The formula e^rt is used (where r is the rate of change and t is the elapsed time). Since in our chicken farm example the rate of change is 10%, and it takes approximately seven years to double the number of egg-laying hens, we plug in the appropriate values for r and t and find that

e^rt = e^(0.1)(7) = e^0.7 = 2.014

The resulting value, 2.014, is then multiplied by our initial principal to yield an answer of 165.15. Our previous calculations were good enough (about 97% accurate compared to this one), but this method generalizes to other compound growth rate problems. And of course, it’s better for use in a computer program.

References

Turing’s Machine: A Simple Example

blue-square-quilt-opus-lxxi

I

The Turing Machine is a theoretical device first described by the British mathematician Alan Turing 1. It is a computing machine that manipulates symbols on a strip of tape. The tape is divided into cells which contain a predefined set of symbols, and is assumed to be infinite in length.

The machine can only perform a finite number of operations; in the example we’ll discuss here, it can read, write, erase, and move one cell to the left or right.

Strangely enough, this simple machine is powerful enough to compute any function that is capable of being computed (Ibid.).

Whatever computations the machine performs must be defined in terms of those operations. We’ll examine two basic operations, addition and subtraction – how they’re defined symbolically, as well as how they’re computed by the machine itself.

We begin with a strip of tape. On it is printed a representation of the two numbers we want to add. “Filled” cells are represented by the number 1. “Blank” cells are represented by 0. Here’s how we would write 4 followed by 3:

| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

The easiest way to visualize adding the two numbers is to shift the number on the right one space to the left. However, even that simple concept is too complicated for the machine to understand. Therefore we must translate our wishes into a series of finite commands which will be executed in sequence. One way of defining an addition function is to use an instruction table like the following:

SYMBOL/STATE 1 0
0 RIGHT/STATE 0 RIGHT/STATE 1
1 RIGHT/STATE 1 LEFT/ERASE/STOP

A good way to understand these instructions is by seeing the machine operate. Let’s step the machine through the behavior defined by the table and see what happens (The machine is represented by the `<0>’ hovering above the tape, where 0 is the state the machine is in according to our table):

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In the above image, our machine is in STATE 0 and therefore keeps moving to the right whenever it encounters a marked cell (as defined in the table of behavior).

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

When the machine (still in STATE 0) encounters a blank cell, it writes to the cell, switches to STATE 1, and moves right.

<1>
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In STATE 1, the machine keeps scanning right, maintaining its current state. It continues right for as long as it reads dotted cells.

<1>
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

Upon encountering an unmarked cell (while still in STATE 1), its
final action is to shift one cell to the left, erase, and stop.

<1>
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

We are now left with 7, the answer. Note that at no time did the machine understand the nature of what we call “addition”. It simply followed the instructions formalized in the table of behavior. It has no notion of its environment beyond the cell in front of it (It has no “memory”). It can only perform actions: read, write, erase, and move.

II

We’ve seen how to add two numbers using a simple Turing machine. Now let’s write a table of behavior for subtraction.

At this point, I challenge you to step away from the computer and do this yourself. You will learn more by attempting this than you will by reading about it here. Please do not come back until you have given it a try.


Welcome back. I assume that you’ve written a table of behavior for the subtraction operation. There are a number of tables that will work; here is one:

SYMBOL/STATE 1 0
0 RIGHT/STATE RIGHT/STATE
0 1
1 RIGHT/STATE RIGHT/STATE
2 1
2 LEFT/STATE 3 LEFT/STATE 5
3 ERASE/LEFT/STATE
4
4 ERASE/RIGHT/STATE LEFT/STATE 4
1
5 ERASE/LEFT/STATE
6
6 ERASE/STOP LEFT/STATE 6

Let’s trace the execution of the machine one step at a time as it subtracts 3 from 4.

In STATE 0, the machine moves to the right as it encounters filled cells. When it encounters a blank cell in STATE 0, the machine moves right and changes to STATE 1.

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In STATE 1, the machine responds to a filled cell by moving right, and changing to STATE 2. In STATE 2, it shifts left and changes to STATE 3.

<2>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In STATE 3, if it encounters a filled cell, the machine will erase,
move left, and change to STATE 4. In STATE 4, if a blank cell is
read, the machine moves left and remains in STATE 4.

<3>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In STATE 4, when it encounters a filled cell, the machine erases, moves to the right, and changes to STATE 1. It then repeats (or recurs, if you will) through the steps shown above. We can see this in the next several illustrations.

<4>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

All is as it was before. The machine is once again in STATE 1, poised above a filled cell. As before, it will shift right and enter STATE 2.

<1>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<2>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

This time, however, the machine encounters a blank cell while in STATE 2. It shifts left and enters STATE 5.

<2>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<5>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

In STATE 5, the machine will erase the filled cell, shift left, and enter STATE 6. STATE 6 specifies that the machine will continue to shift left and remain in STATE 6 as long as it encounters blank cells.

<5>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<6>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

When the machine in STATE 6 encounters a filled cell, it will erase that cell and then stop. The subtraction is complete and we are left with the answer: 1.

<6>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<6>
| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

III

Here is the process shown in full without any verbal explication. The movements of the machine follow a predictable pattern. Note how the behavior of the machine during the transition between STATE 2 and STATE 5 as it nears the end of the computation resembles the base case of a recursive function 2. It’s quite beautiful.

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<0>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<2>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 1 | 0 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 1 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<2>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 0 | 0 | 0 | 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<3>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<4>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<1>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<2>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<5>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<5>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<6>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<6>
| 1 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

<6>
| 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |

For a nice introduction to Turing Machines (among other things), I recommend Paul Hoffman’s book Archimedes’ Revenge.

(Image courtesy Melisande under Creative Commons license.)

Just for Fun: Estimating pi with Scheme

../img/double-star-from-pentagon-backlit.jpg

A while back I shared some Perl code for calculating the circumference of a circle without knowing 𝛑. Just for fun, and due to my longtime infatuation with all things Schemish, I’ve written a little pi approximator in Scheme. It uses the idea that we can approximate a circle using smaller and smaller triangles stacked on top of each other. (See previously for a better explanation with a picture.)

And now, the code!

;;;; pi.scm -- Estimate the value of 𝛑 using smaller and smaller
;;;; triangles.

;;; Call it like so: (pi-estimate n), where n is the number of
;;; iterations you'd like to go through. It doesn't take many to get
;;; pretty accurate.

(define reference-pi 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679)

(define (circumference radius)
  (* 3.14159 2 radius))

(define (square x)
  (* x x))

(define (hypotenuse a b)
  (sqrt (+ (expt a 2) (expt b 2))))

(define (pi-iter radius a b count maxcount)
  (let* ((hyp (hypotenuse a b))
         (newbase (- radius (sqrt (- (square radius)
                                     (square (/ hyp 2)))))))
    (if (= count maxcount)
        (/
         (* 2 hyp (expt 2 (+ 1 count)))
         (* 2 radius))
        (pi-iter radius newbase (/ hyp 2) (+ count 1) maxcount))))

(define (pi-estimate iterations)
  (pi-iter 128 128 128 0 iterations))

(Origami image courtesy Melisande under Creative Commons license.)

How to calculate the circumference of a circle (without knowing pi)

Some time ago I posted the following little challenge to www.reddit.com/r/programming:

Dear Proggit: Imagine that you must devise a method to calculate the circumference of a circle of any radius. The catch? You are unaware of the existence of Pi.

The other catch? You must begin right now. You may use only what tools you have in front of you (text editor, calculator, pencil and paper with compass(!)), without looking anything up. That means no Google searches, no Wikipedia, no formulas in a book, nothing.

Once you have devised a method, please write a small program in the language of your choice that performs the calculation (the more accurate, the better). Bonus points will be awarded for brevity, cleverness, etc.

I will post my little solution sometime tomorrow. Enjoy!

One final note: If you are a total geometry/math wizard who thinks this is lame, please refrain from posting; I want this to be a fun problem for those of us who will get something out of it.

https://logicgrimoire.files.wordpress.com/2012/09/wpid-circle-diagram.png

Below is my method for calculating (or rather, estimating) the circumference of a circle without using pi. This method involves summing the lengths of the hypotenuses of smaller and smaller triangles, as shown in the diagram above.

Begin by cutting the given circle into quarters. Using the radius r, find the hypotenuse of triangle A using Pythagoras’ method. Cut the hypotenuse in half; using that, and the radius, you can calculate the length of line segment Q. Subtract Q from r, and you have the length of line segment P, which is one side of the right triangle B. That, combined with half the hypotenuse of A, will allow you to calculate the hypotenuse of B. Continue, calculating the hypotenuses of smaller and smaller triangles. Sum as many lengths as are required to cover the quarter-circle arc, and multiply by 4 (or multiply the current length by 2^(n*+1), where *n is the number of iterations of the method you’ve performed).

Below I’ve provided an implementation in Perl. Note that the Perl interpreter doesn’t optimize away recursive function calls (that I know of), so you could in theory blow up the stack. In practice, it only takes a few iterations to arrive at a reasonable estimate, so it’s not a problem.

#!/usr/bin/env perl

use strict;
use warnings;
use autodie;
use Math::Trig ':pi';

my ($radius, $maxiter) = @ARGV;
my $iterations = 0;

sub main {
  my ($radius, $a, $b) = @_;
  my $hyp = hypotenuse($a, $b);
  my $newbase = $radius - sqrt($radius**2 - ($hyp / 2)**2);
  $iterations++;
  die "Current hypotenuse is $hyp after $iterations iterations\n"
    . "Estimated circumference: " . $hyp * (2**($iterations+1)) . "\n"
      . "Actual circumference: " . ($radius*2) * pi . "\n"
        if $iterations == $maxiter;
  main($radius, $newbase, ($hyp / 2));
}

sub hypotenuse {
  my ($a, $b) = @_;
  return sqrt($a**2 + $b**2);
}

main($radius, $radius, $radius);

As you can see, we pretty much mirror the textual description given above, but in code. We then compare our work to the “real” value of pi using the Perl core’s Math::Trig constant. Save the above into a file named circ.pl, and you can run it like so:

mel@foo:~$ ./circ.pl 4 12 # Given a radius of 4, run through 12 iterations
Current hypotenuse is 0.00306796150057116 after 12 iterations
Estimated circumference: 25.132740612679
Actual circumference: 25.1327412287183

I might not want to try to calculate planetary orbits using this kind of rough estimation, but for 99% of real-world cases, it’s good enough.

How often will a bus jam the Lincoln Tunnel?

https://logicgrimoire.files.wordpress.com/2012/09/wpid-sierpinski.jpg

I commute into Manhattan four or five days a week. Like a lot of people who ride the bus, I really really hate it when the Lincoln tunnel gets jammed. Even though there are tow trucks standing by at all times (from what I can tell), it seems to cost you about 30-60 minutes of commute time. Because it happens often enough to be a pain in the ass, I’ve been thinking lately about how the numbers play out.

As it turns out, there are statistics on bus usage in the lincoln tunnel available on the port authority website:

…in 2009, the XBL averaged 1,791 daily buses…

Since we’re talking averages, i’m going to assume that the weekday load is heavier than on weekends due to commuters. that should bring the average up a bit. The product of 1,791 buses * 7 days is 12,537 buses each week. Guesstimating that 85% of those buses pass through the tunnel Monday through Friday gives us 10,656 buses divided by 5 days for a weekday average of 2,131 buses.

That’s a lot of buses to push through a tunnel each day. But what about during peak commute times? The signage along the road says that the XBL is open from 6am to 10am. Since the statistics from the above website refer only to the XBL, we can infer that all of their measurements come from those morning commute hours. (There is no special commuter lane for buses leaving the city in the evenings that I’ve seen.) Therefore I’ll assume that these statistics refer only to the peak AM commute.

You might infer from the picture on the Port Authority website that there is only one lane leading up to and through the tunnel. I can confirm this. Not only is there only one bus lane, but it’s one lane that stretches quite a ways back from the tunnel and into New Jersey. Once inside the lane, you may not change into another lane, either (this is probably obvious, but worth noting).

What about bus reliability? How often do buses break down? Let’s be generous and assume that any given bus will make this trip successfully 99.9% of the time. This means that the bus will only break down once every 1,000 trips through the lane. I’d estimate that the XBL is ~3 miles long, measured beginning at the EZPASS out in Jersey and ending when the bus has entered normal city traffic around 40th street. Once inside the city proper, a bus can still stall and create problems in the tunnel, but we’ve got to end our measurement somewhere.

According to the multiplication rule 1, we can get the probability that none of the 2131 buses going through the XBL will stall (that is, that they will all make it) by taking our probability that any given bus will make it and raising it to the 2131 power. This gives us 0.999 ^ 2131, yielding 0.119. This means that there is only an 11.9% chance that all 2131 buses will get through the XBL on any given weekday morning without stalling or breaking down!

But is this true? My anecdotal experience over the past few months of commuting says yes. I’ve had to sit through a number of traffic jams coming into the city in the mornings. As a result, I’ve switched to an earlier bus in order to avoid most of the peak commuter buses.

(Image courtesy Melisande under Creative Commons license.)

Footnotes:

1 wonderfully described in John Paulos’ book Innumeracy