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

via I Read Dead People

Posts related to T. S. Eliot:

Historical sense
Calendars, Connections, and Cats

Posts on old books:

Firsthand knowledge
Applied topology and Dante

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

tantheta = tan(alpha - beta) = frac{tanalpha - tan beta}{1 + tanalpha tanbeta}

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:

Means and inequalities
The middle size of the universe

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, 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, 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:

Literate programming and statistics
Tricky code

The Tangled Web

The Tangled Web 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 unstand 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:

Three reasons expert predictions are often wrong
The most powerful people are right
Most published research results are false

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:

Medieval project management
Sheet music, DNA, and source code
Do you really want to be indispensable?

Where gargoyles come from

Gargoyles are decoration for drainage. Gothic churches channeled water away from their walls to prevent erosion. The spout often emptied through the mouth of a sculpture.

These spouts are called gargoyles, from an old French word gargouille meaning “throat” (it is related to the English words “gargling” and “gurgling”). Other forms of grotesque sculpture used to decorate churches are commonly referred to as “gargoyles” but, strictly speaking, they are not, because they have no practical function.

Source: The Secret Language of Churches & Cathedrals

Photo licensed from The 3D Studio.

Fermat’s unfinished business

Fermat’s last theorem is so named because it was the last of his asserted theorems to be proved or disproved. But there are variations on another conjectures of Fermat that remain unresolved.

Fermat conjectured that numbers

F_n = 2^{2^n} + 1

are always prime. We now call these “Fermat numbers.” Fermat knew that the first five, F0 through F4, were all prime.

In some ways, this conjecture failed spectacularly. Euler showed in 1732 that the next number in the sequence, F5, is not prime by factoring it into 641 × 6700417. So are all the Fermat numbers prime? No.

But that’s not the end of the story. Now we go back and refine Fermat’s conjecture. Instead of asking whether all Fn are prime, we could ask which Fn are prime.

The next several values, F5 through F32, are all known to be composite. So we might turn Fermat’s original conjecture around: are all Fn composite (for n > 4)? Nobody knows.

Well, let’s try weakening the conjecture. Is Fn composite for infinitely many values of n? Nobody knows. Is Fn prime for infinitely many values of n? Nobody knows that either, though at least one of these two statements must be true!

Here’s why I find all this interesting.

  1. It shows how proof by example fails. Fermat knew that the first five numbers in his series were prime. It was reasonable to guess from this that the rest might be prime, though that turned out not to be the case.
  2. It shows how what appears to be a dead end can be opened back up with a small refinement of the original question.
  3. Like many questions in number theory, the revised question is easy to state but has defied proof for centuries.

Norris’ number

My friend Clift Norris has identified a fundamental constant that I call Norris’ number, the average amount of code an untrained programmer can write before he or she hits a wall. Clift estimates this as 1,500 lines. Beyond that the code becomes so tangled that the author cannot debug or modify it without herculean effort.

Related posts:

Writes large correct programs
Little programs versus big programs
Experienced programmers and lines of code

Cartoon guide to the uninteresting

If you’re not interested in a subject, do cartoons make it more palatable?

My guess is that cartoons may help keep your attention if you’re moderately interested in a subject. If you’re fascinated by something, cartoons get in the way. And if you’re not interested at all, cartoons don’t help. The cartoons may help in the sweet spot in between.

No Starch Press has given me review copies of several of their Manga Guide books. The first three were guides to the universe, physics, and relativity. I’ve reviewed these here and here. Recently they sent a copy of the newest book in the series, The Manga Guide to Biochemistry.

I’m much more interested in physics than biology, so I thought this would be a good test: Would a manga book make it more interesting to read about something I’m not very interested in studying? Apparently not. It didn’t seem that the entertaining format created much of an on-ramp to unfamiliar material.

It seemed like the information density of the book was erratic. Material I was familiar with was discussed in light dialog, then came a slab of chemical equations. Reading the book felt like having a casual conversation with a lawyer who periodically interrupts and asks you to read a contract.

Someone more interested in biochemistry would probably enjoy the book. Please understand that the title of this post refers to the fact that I find biochemistry uninteresting, not the book. If I had to study a biochemistry book, the Manga Guide to Biochemistry might be my first choice. At times I’ve found biochemistry interesting in small doses, describing a specific problem. But it would be nearly impossible for me to read a book on it cover to cover.

O’Reilly’s “Head First” series is similar to the Manga guide series, though the former has more content and less entertainment. I enjoyed the first Head First book I read, Head First HTML with XHTML & CSS. Maybe I enjoyed it because the subject matter was in the sweet spot, a topic I was moderately interested in. The cartoons and humor helped me stick with a dry subject.

When I tried another Head First book, I was hoping for more that same push to keep going through tedious content. The books clearly had the same template though with different content. What was interesting the first time was annoying the second time, like hearing someone tell a joke you just heard. So at least for me, the Head First gimmick lost some of its effectiveness after the first book.

Career advice regarding tools

J. D. Long wearing a Panama and smoking a Dominican

A few weeks ago, J. D. Long gave some interesting advice in a Google+ discussion. He starts out

Lunch today with an analyst 13 years my junior made me think about things I wish I had known about the technical analytical profession when I was 25. Here’s some things that popped into my head:

The entire list is worth reading, but I want to focus on two things he said about tools.

  • Use tools you don’t have to ask permission to install (i.e. open source).
  • Dependence on tools that are closed license and un-scriptable will limit the scope of problems you can solve. (i.e. Excel) Use them, but build your core skills on more portable & scalable technologies.

I would have disagreed a few years ago, but now I think this is good advice.

In the late 90’s I used mostly Microsoft tools. That was a good time to be a Microsoft developer. Windows was on the rise; Unix and Mac OS were on the ropes. Desktop applications were the norm and were easier to write on Windows. Open source software was hard to install and hard to use. People who used open source software often did so for ideological reasons, not because it made their work easier.

Of course times have changed. Mac recovered from its near death experience. Unix didn’t, but it has been resurrected as Linux. The web made it easier to write cross-platform software. And above all, open source software has matured. The open source community is more positive, focused on promoting good software rather than trying to give some corporation a stick in the eye.

Now the advantages of open source are clearer. There’s not the same hidden cost in frustration that there was a few years ago. Now I would say yes, it’s a great advantage to use tools you can install whenever and wherever you want, without having to go through a purchasing bureaucracy.

It’s interesting that JD equates open source with scriptability. Open source software often is scriptable, not because it’s open source, but because of the Unix aesthetic that pervades the open source community. Closed source software is often not scriptable, not because it’s closed source, but because it is often written for consumers who value usability over composability. Commercial server-side products may be scriptable. If I were to restate JD’s advice on this point, I’d say to keep composability in mind and don’t just think about usability.

I appreciate JD’s attitude toward applications such as Excel. He’s not saying you should never defile your conscience by opening Excel. Some tasks are incredibly easy in Excel. The danger comes from pushing the tool into territory where other tools are better. There are still some in the open source community who believe that opening Excel is a sin, but I’m much more in agreement with the people who say, for example, that Excel isn’t the best tool for statistical analysis.

Portability is funny. In the early days of computing, there were no dominant players, and portability was important (and difficult). Then for a while, portability didn’t matter if you were content with only running on the 95% of the world’s computers that ran Windows. Now portability is important again. Windows still has a huge market share on the desktop, but the desktop itself is losing market share.

And portability matters for more than consumer operating systems. JD mentions portability and scalability in one breath. You may want to move code between operating systems to scale up (e.g. to run on a cluster) or to scale down (e.g. to run on a mobile device).

There’s also the aspect of career portability. You want to master tools that you can take with you from job to job. I would be leery of building a career around a small company’s proprietary tools. If I were in that situation, I’d learn something else on the side that’s more portable.

In closing, I’ll give the rest of JD’s career advice without commentary. These points could make interesting fodder for future blog posts.

  • Be a profit center, not a cost center.
  • Use tools you don’t have to ask permission to install (i.e. open source).
  • Dependence on tools that are closed license and un-scriptable will limit the scope of problems you can solve. (i.e. Excel) Use them, but build your core skills on more portable & scalable technologies.
  • Learn basic database tools.
  • Learn a programming language.
  • Your internal job description may say, “Analyst” but get something else on your business cards. Analyst is so vague as to be meaningless. My external title is currently “Sr. Risk Economist.” I like the term “Data Scientist” for now. I expect that term will be meaningless in 5 years.
  • Large organizations do not properly appreciate agile and smart analytic types. Time at large firms should be seen as subsidized learning. Learn lots, but get out.
  • Ensure you can explain any of your projects to your wife or non-technical friends. It’s good practice for board meetings later in your career.
  • Be sure you know the handful of things that you can do better than most anyone else. Add something to that list every year. Make sure you can explain these things to non techies.
  • Be a profit center, not a cost center. At least be as close to the profit center as possible. The chief analyst for the sales SVP is closer to the profit center than an IT analyst supporting billing operations.
  • Get really good at asking questions so you understand problems before you start solving them.
  • Yes, that bit about being a profit center not a cost center is in there twice. It should probably be in there 5 times.