Never a time so completely parochial

“There never was a time when those that read at all, read so many books by living authors rather than books by dead authors. Therefore there was never a time so completely parochial, so completely shut off from the past.” — T. S. Eliot

Posts related to T. S. Eliot:

Posts on old books:

Solution to Renaissance problem

The previous post presented a problem first posed by Johannes Müller in 1471.

Where you should stand so that a vertical bar appears longest?

To be more precise, suppose a vertical bar is hanging so that the top of the bar is a distance a above your eye level and the bottom is a distance b above your eye level. Let x be the horizontal distance to the bar. For what value of x does the bar appear longest?

In the following diagram, we wish to maximize the angle θ.

Since tangent is an increasing function, it suffices to maximize tan(θ). Let α = θ + β. Then

\tan\theta = \tan(\alpha - \beta) = \frac{\tan\alpha - \tan \beta}{1 + \tan\alpha \tan\beta}

Now use tan α = a/x and tan β = b/x to reduce the expression above to

\frac{(a-b)x}{x^2 + ab}

Now we have a function of x to maximize. Take the derivative and find where it is zero. The maximum occurs at √ab, the geometric mean of a and b.

However, when Müller proposed his problem in 1471, calculus had not yet been invented, so we can be pretty sure Müller did not take derivatives. I don’t know how (or even if) Müller solved his problem, but the book where I found the problem showed how it could be solved without calculus. The derivation is a little longer, but it only depends on simple algebra and the arithmetic-geometric mean inequality, i.e. the observation that (a + b) /2 ≥ √ab.

Update: Here is a purely geometric solution by George Papademetriou.

Update: See this post for more historical background.

Other posts about the geometric mean:

A Renaissance math puzzle

In 1471, Johannes Müller asked where you should stand so that a vertical bar appears longest.

To be more precise, suppose a vertical bar is hanging so that the top of the bar is a distance a above your eye level and the bottom is a distance b above your eye level. Let x be the horizontal distance to the bar. For what value of x does the bar appear longest?

Note that the apparent length of the bar is determined by the size of the angle between your lines of sight to the top and bottom of the bar.

Please don’t give solutions in the comments. I’ll post my solution tomorrow, and you can give your solutions in the comments to that post if you’d like.

Source

Update: See this post for more historical background.

Fundamental theorem of code readability

In The Art of Readable Code (ISBN 0596802293), the authors call the following the “Fundamental Theorem of Readability”:

Code should be written to minimize the time it would take for someone else to understand it.

They go on to explain

And when we say “understand,” we have a very high bar … they should be able to make changes to it, spot bugs, and understand how it interacts with the rest of your code.

Bad logic, but good statistics

Ad hominem arguments are bad logic, but good (Bayesian) statistics. A statement isn’t necessarily false because it comes from an unreliable source, though it is more likely to be false.

Some people are much more likely to know what they’re talking about than others, depending on context. You’re more likely to get good medical advice from a doctor than from an accountant, though the former may be wrong and the latter may be right. (Actors are not likely to know what they’re talking about when giving advice regarding anything but acting, though that doesn’t stop them.)

Ad hominem guesses are a reasonable way to construct a prior, but the prior needs to be updated with data. Given no other data, the doctor is more likely to know medicine than the accountant is. Assuming a priori that both are equally likely to be correct may be “fair,” but it’s not reasonable. However, as you gather data on the accuracy of each, you could change your mind. The posterior distribution could persuade you that you’ve been talking to a quack doctor or an accountant who is unusually knowledgeable of medicine.

Related post: Musicians, drunks, and Oliver Cromwell

Readability

The Readability bookmarklet lets you reformat any web to make it easier to read. It strips out flashing ads and other distractions. It uses black text on a white background, wide margins, a moderate-sized font, etc. I use Readability fairly often. (Instapaper is a similar service. I discuss it at the end of this post.)

Yesterday I used it to reformat an article on literate programming. For some inexplicable reason, the author chose to use a lemon yellow background. It’s ironic that the article is about making source code easier to read. The content of the article is easy to read, but the format is not.

Readability to the rescue! Here are before and after screen shots.

Before:

After:

I recommend the article, Example of Literate Programming in HTML [Update: link went away], and I also recommend using reformatting the page unless you enjoy reading black text on a yellow background.

Readability did a good job until about half way through the article. The article has C and HTML code examples, and perhaps these confused Readability. (Readability usually handles code samples well. It correctly formats the first few code samples in this article.) The last half of the article renders like source code, and the font gets smaller and smaller.

I ran the page through an HTML validator to see whether some malformed HTML could be the source of the problem. The validator found numerous problems, so perhaps that was the issue.

I haven’t seen Readability fail like this before. I’ve been surprised how well it has handled some pages I thought might trip it up.

I ended up saving the article and editing its source, changing the bgcolor value to white. It’s a nice article on literate programming once you get past the formatting. The best part of the article is the first section, and that much Readability formats correctly.

Instapaper

Instapaper reformats web pages similarly. It produces a narrower column of text, but otherwise the output looks quite similar.

Instapaper did not discover the title of the literate programming article. (The title of the article was not in an <h1> tag as software might expect but was only in a <title> tag in the page header.) However, it did format the entire body of the article correctly.

I find it slightly more convenient to use the Readability bookmarklet than to submit a link to Instapaper. I imagine there are browser plug-ins that make Instapaper just as easy to use, though I haven’t looked into this because I’m usually satisfied with Readability.

Related posts

The Tangled Web

The Tangled Web (ISBN 1593273886) is a security book that you may find interesting even if you’re not interested in security. The first half of the book is an excellent explanation of how Web technologies work in theory and especially in practice. This material is included in order to discuss security implications, but it’s interesting on its own. The second half of the book is directly devoted to Web security.

The author, Michal Zalewski, has a colorful writing style. His book is serious and loaded with technical detail, but that doesn’t stop him from turning a nice phrase here and there.

Here’s an excerpt from The Tangled Web that I particularly liked, one that explains why security concerns on the Web differ from previous security concerns.

In the traditional model followed by virtually all personal computers … there are very clear boundaries between high-level data objects (documents), user-level code (applications), and the operating system kernel … These boundaries are well studied and useful for building practical security schemes. A file opened in your text editor is unlikely to be able to steal your email …

In the browser world, this separation is practically nonexistent: Documents and code live as parts of the same intermingled blobs of HTML, isolation between completely unrelated applications is partial at best …

In the end, the seemingly unlikely scenario of a text file stealing your email is, in fact, a frustratingly common pattern on the Web.

Why experts exaggerate

Seth Roberts writes this morning:

How can you tell when an expert is exaggerating? His lips move.

Some people will misunderstand his point. Roberts is not saying experts exaggerate their conclusions per se. He’s saying experts exaggerate their confidence in their conclusions.

If an expert says that playing a harmonica decreases your risk of influenza by 10%, she’s probably not making that figure up out of thin air (though I am). There probably was some data that implied the 10% figure. It’s not that the data suggested 5% and the scientist said “Let’s call it 10%.” But the quality and quantity of the data may not justify rushing out to buy a harmonica.

One reason experts exaggerate their confidence is that they may be at a loss for words to explain their degree of uncertainty to a popular audience. Journalists can understand “Harmonica playing is good for you” though they probably cannot understand confidence intervals, Bayes factors, or the differences between retrospective versus prospective experiments. (The experts may not really understand these things either.)

Another reason for exaggeration is that you don’t get the attention of the press by making tentative claims. This creates an incentive to suppress uncertainty. But even if experts were transparent regarding their uncertainty, there would still be a selection bias: experts who are sincerely more confident are more likely to be heard.

There are numerous other reasons experts may be wrong, some psychological and some statistical.

I liked the first comment on Roberts’ post:

I tended to rate my colleagues partly by how often the words “I don’t know” passed they lips. Often = good.

Related posts

Why did we do this?

Here are a few thoughts on institutional memory from a talk by Admiral Hyman G. Rickover.

When important decisions are not documented, one becomes dependent on individual memory, which is quickly lost as people leave or move to other jobs. In my work, it is important to be able to go back a number of years to determine the facts that were considered in arriving at a decision. This makes it easier to resolve new problems by putting them into proper perspective. It also minimizes the risk of repeating past mistakes.

I’ve never seen this done effectively. I’ve been part of business and non-profit organizations that kept good records, but I don’t recall anyone ever looking back through the records to review why a decision was made.

This is especially a challenge in software development where the myth of progress runs so strong. Newer is always better. The people before us were stupid, so why should we go back and read what they thought? Or maybe they weren’t stupid, but they were working with version 10.5 of FooBar. Now we’re up to version 11.2 and so everything has changed.

Related posts