Ancient understanding of tides

In his essay On Providence, Seneca (4 BC – 65 AD) says the following about tides:

In point of fact, their growth is strictly allotted; at the appropriate day and hour they approach in greater volume or less according as they are attracted by the lunar orb, at whose sway the ocean wells up.

Seneca doesn’t just mention an association between lunar and tidal cycles, but he says tides are attracted by the moon. That sounds awfully Newtonian for someone writing 16 centuries before Newton. The ancients may have understood that gravity wasn’t limited to the pull of the earth, that at least the moon also had a gravitational pull. That’s news to me.

Computing log gamma differences

Statistical computing often involves working with ratios of factorials. These factorials are often too big to fit in a floating point number, and so we work with logarithms. So if we need to compute log(a! / b!), we call software that calculates log(a!) and log(b!) directly without computing a! or  b! first. More on that here. But sometimes this doesn’t work.

Suppose a = 10^40 and b = a – 10^10. Our first problem is that we cannot even compute b directly. Since ab is 30 orders of magnitude smaller than a, we’d need about 100 bits of precision to begin to tell a and b apart, about twice as much as a standard floating point number. (Why 100? That’s the log base 2 of 10^30. And how much precision does a floating point number have? See here.)

Our next problem is that even if we could accurately compute b, the log gamma function is going to be approximately the same for a and b, and so the difference will be highly inaccurate.

So what do we do? We could use some sort of extended precision package, but that is not necessary. There’s an elegant solution using ordinary precision.

Let f(x) = log(Γ(x)). The mean value theorem says that

f(a+1) – f(b+1) = (ab) f‘(c+1)

for some c between a+1 and b+1. We don’t need to compute b, only ab, which we know is 10^10. The derivative of the log of the gamma function is called the digamma function, written ψ(x). So

log(a! / b!) = 10^10 ψ(c+1).

But what is c? The mean value theorem only says that the equation above is true for some c. What c do we use? It doesn’t matter. Since a and b are so relatively close, the digamma function will take on essentially the same value for any value between a+1 and b+1. Therefore

log(a! / b!) ≈ 10^10 ψ(a).

We could compute this in two lines of Python:

from scipy.special import digamma
print 1e10*digamma(1e40)

More numerical analysis posts

Fault-tolerant systems are faulty

Richard Cook wrote an excellent article How Complex Systems Fail. The author packs a lot of ideas into four pages, divided into 18 points. Here are his first five points.

  1. Complex systems are intrinsically hazardous systems.
  2. Complex systems are heavily and successfully defended against failure.
  3. Catastrophe requires multiple failures – single point failures are not enough.
  4. Complex systems contain changing mixtures of failures latent within them.
  5. Complex systems run in degraded mode.

Cook (no relation) elaborates his fifth point:

A corollary to the preceding point is that complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws.

Complex systems are necessarily fault-tolerant. If they weren’t fault tolerant, they likely wouldn’t survive long enough to become complex. Unfortunately, the down side is that fault-tolerant systems are always faulty.

We want our software to be fault-tolerant, but it is very difficult to tolerate faults without encouraging and concealing faults. (Think of badly formed HTML, for example.) Fault tolerance can work smoothly if you have a well-defined range of faults that your system is designed to tolerate. But misguided attempts to tolerate errors can mask problems, delaying but not preventing failure, making the failure harder to diagnose and repair.

Some systems must be complex and fault-tolerant. But when we decide to make something fault-tolerant, especially if there is a realistic alternative to make it simpler, we should be aware of the consequences.

Related post: Obscuring complexity

Software albatross

The only way to completely wash your hands of a piece of software you’ve written is to change employers, and sometimes even that doesn’t work.

Why is this? The primary reason is that it is very difficult to transfer software from one person to another. Good development processes help, but only so much. It’s difficult to hand over even the best code because you need more than code. It’s hard to jump into someone else’s code because it’s hard to jump into someone else’s head.

Taking over a software project is like taking over a novel. Editing to fix typos and grammatical errors in a completed novel is relatively easy. Taking over a half-finished manuscript is much harder. It might be easier to throw away the manuscript and write your own novel from scratch.

When someone does take over an unfinished book, it’s often someone intimately connected to the author. For example, J. R. R. Tolkien’s posthumous works, such as The Children of Húrin, were completed by his son and literary executor, Christopher Tolkien. The younger Tolkien had much more to work with than a set of notes. He knew the author and knew how he thought.

Because projects are so hard to transfer, the path of least resistance is simply to never transfer projects. Often projects are officially transferred to someone else but return like a boomerang when difficulties arise. Each project a developer works on adds some residual responsibility until he or she hits a ceiling of complexity and can no longer do new work. At that point, the developer either settles into maintenance mode or changes employers.

Thanks to John Z. Fields for recommending the title of this post. Literary allusion explained here.

Related posts

AeroPress coffee

People have been telling me to try an AeroPress for a long time, and I finally gave in. The deciding factor was that the AeroPress is entirely plastic and presumably unbreakable. When we broke yet another glass beaker in our French press, I decided it was time to try an AeroPress. (Next time I buy a French press, I think I’ll get one made of metal or shatterproof plastic.)

Compared to a French press, the AeroPress is faster to use and easier to clean. The taste is different, somewhere between the taste of French press coffee and espresso. This isn’t surprising since an AeroPress is somewhere between a French press and an espresso maker. Like a French press, you pour hot water over the grounds. Like an espresso machine, you use pressure to extract oils from the coffee.

More coffee posts

When do binomial coefficients have integer roots?

Binomial coefficients are hardly ever powers. That is, there are strong restrictions on when the equation

{n \choose k} =m^\ell

has integer solutions for l ≥ 2.

  • There are infinitely many solutions for k = 1 or 2.
  • If k = 3 and l = 2, there is only one solution: n = 50 and m = 140.
  • If k is 4 or larger, there are no solutions.

(Binomial coefficients remain unchanged when you replace k with nk. So when we say there are no solutions for k ≥ 4, we also assume n-k ≥ 4.)

Source: Proofs from the Book

How things break

Venkatesh Rao wrote a blog post today Stress Failures versus Decay Failures. It reminded me of three other resources I recommend on how things break. The first is about how things literally break. For example, why the steel in the Titanic was brittle.

The other two are about how complex systems break.

The Artist’s Guide to GIMP

Learning how to edit images has been on my to-do list for a long time. I do some very basic editing with Paint.NET, but I keep meaning to learn to use GIMP.

I heard years ago that GIMP is terribly complicated and that I should learn Photoshop instead. I tried Photoshop—not extensively, but I spent some time with it—and I tried GIMP. My conclusion was that image editing is complicated. Image editing software is complicated, but not unnecessarily so. If you expect image processing to be as easy as word processing, as I suppose I implicitly did, your expectations are unrealistic.

The only way I’m going to learn image editing is by doing it. But a book can help, and I expect The Artist’s Guide to GIMP will help more than other GIMP resources I’ve read. That’s because this book puts a little more emphasis on problem solving strategies and techniques and a little less emphasis on software features. As Michael Hammel says in the introduction,

This is a book about process, not buttons or menu paths. … Don’t get bogged down in the mechanics of the tool. Focus on the task at hand. I’ll point you to the GIMP components necessary to finish the job.

The first chapter is about tools more than process, but I suppose some of that is inevitable at first. The rest of the book really is more about process. And there’s plenty of information about buttons and menu paths, but the book is organized by task and process comes before tool details. This is what I want from a book. I can read online documentation, but that documentation won’t tell me what I ought to be looking up. I look to books to get me started in the right direction.