A friend and I figured out why your running product/quotient algorithm behaves the way it does.

**Period of 4**

Your running product/quotient sequence will start as follows:

\[n, \frac{n}{(n-1)}, \frac{n(n-2)}{(n-1)}, \frac{n(n-3)}{(n-1)(n-2)}, \dots\]

After the first multiplication which is a corner case (\(q=1\)), you divide twice, then multiply twice, divide twice and so on. It takes two multiplications/divisions to change from being less than one to more than one and vice versa. Let \(n, n-1, \dots, n-(k-1)\) have already been multiplied/divided in \(q\), that is, we have used \(k\) terms.

If \(k \mod 4\) is 1 or 2, then skip \(\frac{n}{n-1}\) which is greater than one and club 4 terms at a time. Each of these will also be greater than 1. So in both these cases we will choose to divide next.

\[\frac{n}{n-1}\cdot\frac{(n-3)(n-4)}{(n-2)} \textrm{ and } \frac{n}{n-1}\cdot\frac{(n-3)(n-4)}{(n-2)(n-5)}\]

On the other hand, if \(k \mod 4\) is 0 or 3, then club 4 terms at a time without skipping \(\frac{n}{n-1}\). Each of these terms will less than 1 and we will choose to multiply next.

\[\frac{n(n-3)}{(n-1)(n-2)}\cdot\frac{(n-4)}{(n-5)(n-6)} \textrm{ and } \frac{n(n-3)}{(n-1)(n-2)}\cdot\frac{(n-4)(n-7)}{(n-5)(n-6)}\]

Formalizing this is easy using induction (done case by case using mod 4 arguments) and that will prove that the period is 4.

**Convergence value**

We did this for the case where \(n = 4k\) but the other cases should be similar (although messier). Writing out the value of \(q\) as a function of \(k\) we get the following:

\[\prod_{n=1}^{\infty} \frac{4n(4n-3)}{(4n-1)(4n-2)} = \sum_{n=1}^{\infty} \log \frac{4n(4n-3)}{(4n-1)(4n-2)}\]

Wolfram alpha tells us this converges to -0.222251 one of the values you noticed numerically. Here’s the link.

]]>Among the most common programming operators, the only ones that are not “easy” would be exponentiation (when not evaluated left-to-right), integer modulo (maybe interesting) and bitwise XOR (certainly interesting). There’s also the C comparison operators which also work as Boolean operators, but I can’t think of anything more to say about them.

]]>Kirkpatrick’s paper mentions Ising and Nicholas Metropolis but does not mention Glauber.

]]>They’re all related to one another by being in the set of relations. And of course each can have a set of other properties, like symmetry / anti-symmetry, one-to-one / many-to-one / one-to-many, containing vs. membership, transitive, associative, what-have-you.

You might think you still need a key for relations, but really anything that gets you in is not more than two steps away from the set of relations, providing it has any properties at all (which is a relation). In life there’s no such thing as “no stimulus” — that’s a stimulus, too — so you don’t need a special way in.

]]>It’s not so much that humans are bad at estimating probabilities, as that they have a number of “wet-wired” algorithms for dealing with risk, that aren’t necessarily appropriate for modern contexts.

]]>Just to clarify: When I mentioned the possibility of “an automatic control system with … situational awareness”, I was not talking about the SCADA system, nor was I suggesting that operators in Columbus should have been able to close valves in Lawrence. I was thinking of a more sophisticated pressure regulator replacing the existing hardware. As you point out, pressure regulators are largely simple, mechanical devices that sense line pressure and set an inlet throttle valve accordingly. When designs of this kind were introduced in the 1950s, they were the best we could do. We may be able to better now. A regulator could sense when the system is not responding as expected, and then shut the system down.

There’s an analogy in the electric power infrastructure. When a tree limb brushes against a power line, a device called a recloser interrupts the electric current briefly, but then tries closing the circuit again in case the problem was a momentary one. This avoids many nuisance power outages. But the recloser only tries reclosing two or three times before giving up and choosing safety over convenience. There’s no reason the gas system couldn’t be operated on similar principles: If the pressure keeps falling even as the inlet valve is opened wider, it’s a reasonable guess that something is seriously wrong, and a reasonable action is to shut the system down.

I would also like to say, in case I wasn’t clear the first time around, that my aim in writing on this subject is not to assess blame. Mistakes were made in Lawrence–that’s beyond dispute–but I don’t known who made them and I don’t think finding culprits is a useful way of preventing recurrences. We all make mistakes. I would like to see systems designed so that we can make mistakes without killing people or burning down neighborhoods.

In the weeks since I wrote this piece, we have witnessed another example of a control system that may have caused a disaster in spite of the best efforts of human operators. The crash of Lion Air flight 610 in Indonesia appears to have been caused by a control system responding to an erroneous sensor signal, which the pilots were not able to override. This explanation of the accident is a only preliminary hypothesis, but if it turns out to be correct, we may have another case where a little more situational awareness in the control system could have saved lives.

]]>From the timeline, you can see that the manual over-ride system was not up to the challenge:

High-pressure alarm 1 : 4:04 p.m.

High-pressure alarm 2: 4:05 p.m.

Controller reported event to Meters and Regulations in Lawrence.: 4:06 p.m.

Overpressure gas explosion at Lawrence: 4:11 p.m.

Columbia Gas shut down the regulator about 4:30 p.m

What we have here is a system that takes 5 minutes develop an explosive pressure level, but 24 minutes to shut down after an overpressure alarm. OK, perhaps it would have been quicker than 24 minutes if staff hadn’t also been responding to the explosion, but no matter: it was > 5 minutes! (I hope this isn’t read as only a criticism of the gas workers in Lawrence. There’s always much more to it than that.)

Paul, I hope you will revisit the topic when the final NTSB report comes out. Thanks for this!

]]>If you might be interested in writing up your own explanation of the accident, please get in touch with me directly (brian@bit-player.org). I would be happy to consider publishing it here.

]]>