July 2008

I ran across this quote from John Tukey a couple days ago:

An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem.

Too often approximate problems take on a life of their own and we forget that they were approximations. We worry about numerical results to many significant figures when the original model might be doing well to get within 20% of reality. Better to produce a crude solution to a more realistic problem. As G. K. Chesterton said, anything worth doing is worth doing poorly.

On the other hand, you’ll probably face less criticism if you produce exact solutions to unrealistic problems than if you produce approximate solutions to realistic problems. At least that’s what I’ve seen. I suppose this is because it takes less understanding to find fault with your solution than to evaluate your choice of problem to solve.

The latest Science at NASA podcast explains how one might make a telescope on the moon out of local material. Peter Chen has constructed a prototype 12 inch telescope primarily using simulated lunar soil. He estimates a Hubble-sized telescope could be constructed from lunar soil and about about 130 pounds of material from Earth.

Audio and transcript available here.

The latest Pixel8 podcast has an interview with world-class debugger and former Green Beret John Robbins.

John Robbins is a terrific speaker and author. In the podcast interview he gives some background on how he became an expert troubleshooter. He and shares some war stories of how he saved companies from bankruptcy by finding the bug no one else could find and gives some general debugging advice.

Sometimes people demand a web application when a piece of paper would do just as well. People have thought I was out of my mind when I suggested a task could be done on paper at 1% of the cost of developing a custom web application. I guess paper is just vulgar.

A typical web application involves three machines (client, web server, database server) and at least five programming languages (HTML, CSS, JavaScript, SQL, and some business logic language such as C# or Java). That’s a lot of complexity and a lot of possible points of failure. The complexity is often justified for large projects, but sometimes for small projects it’s just not. Sometimes paper is simpler and more robust.

On the Windows PowerShell blog, Jeffrey Snover links to a article in Linux Magazine by Narcus Nasarek comparing Windows PowerShell and Linux’s bash shell.

The article’s sequence is unexpected. Not until near the end of the article does Nasarek get to the main difference between PowerShell and bash: PowerShell pipes objects, not text. Nasarek says regarding PowerShell’s object pipeline “Bash cannot compete here.” He says that the disadvantage of bash in this regard is that “it relies on the abilities of external programs to handle data structures.” That is an understatement. The disadvantage of bash is that it requires fragile, ad hoc text manipulation to pluck data out of the pipeline.

Nasarek is being fair to PowerShell, but he was limited by space. He had only two pages for his article, and only about half of those two pages were devoted to text.

CaringBridge offers “free, personalized websites that support and connect loved ones during critical illness, treatment and recovery.” The site is sponsored by donors, not advertising.

When he was diagnosed with cancer four years ago, a friend of mine set up a password-protected web page to let us know the latest updates on his treatment and diagnosis. I appreciated his doing this. He could easily set up his own site, but not everyone knows how to do that. CaringBridge lets people who are not as technically inclined set up their own site. Patients can upload photos, exchange messages with friends, etc. About 100,000 families have set up web sites through CaringBridge so far.

Wendell Berry on the publish-or-perish ethos of modern universities:

If a tree falls in the absence of a refereed journal or a foundation, does it make a sound? The answer, in the opinion of the imitation corporate executives who now run our universities, is no.

From Life is a miracle: an essay against modern superstition.

It appears that someone has found a flaw in Xian-Jin Li’s proposed proof of the Riemann hypothesis according to the Not Even Wrong blog. (Hat tip: Ars Mathematica)

This doesn’t mean that all is lost. Andrew Wiles’ first attempt at proving Fermat’s Last Theorem was flawed, but he fixed it. Perhaps Li can patch his proof. If not, he may be able to salvage a proof of something valuable short of the Riemann hypothesis.

The news of Li’s proof and its refutation underscores a point I made in an earlier post about proofs of false statements. Namely, “… in mainstream areas of math, blunders are usually uncovered very quickly.” The Riemann hypothesis is very much in the mainstream, and it looks like a blunder was uncovered within 24 hours.

Here’s a quote from a recent blog post from Tom Peters:

You will be remembered in the long haul for the quality of your work, not the quantity of your work—the quantity part is just your defective ego talking—no one evaluates Picasso based on the number of paintings he churned out.

Xian-Jin Li claims to have proven the Riemann hypothesis, one of the most famous open problems in math. His paper is posted arXiv.

The Riemann hypothesis is no obscure conjecture. It’s a natural question and central to number theory. For years mathematicians have been proving theorems of the form “If the Riemann hypothesis is true, then …” and so if Li’s result is correct, many other new results follow. Also, if the proof holds up, Li wins a $1,000,000 prize from the Clay Institute for solving one of the Millennium Problems.

Hat tip: Isabel Lugo

Update: Looks like there’s a flaw in the proof.

Update 5 Feb 2009: Another proposed proof.

I ran across the book Team Moon by Catherine Thimmesh when I took my kids to the library.

The book’s subtitle is “How 400,000 People Landed Apollo 11 on the Moon.” This children’s book focuses on the thousands of people who worked behind the scenes of Apollo 11. It highlights some of the things that went wrong or could have gone wrong. One of the early pages of the book quotes the speech that was prepared for President Nixon to read if the mission had failed.

Fate has ordained that the men who went to the moon to explore in peace will stay on the moon to rest in peace … These brave men, Neil Armstrong and [Buzz] Aldrin, know that there is no hope for their recovery. But they also know that there is hope for mankind in their sacrifice.

Grim words for a children’s book. And yet without some explanation of the dangers they faced, it’s impossible to appreciate the astronauts’ bravery. When I was a child, I was puzzled by talk of brave astronauts. In my mind, astronauts simply got on board a rocket the same way I got in a car. What was brave about that? It didn’t occur to me that they might not return safely.

Team Moon reminded me of Undaunted Courage by Stephen Ambrose. The image of the Lewis and Clark expedition I had from childhood was about as naive as my image of astronauts. I pictured a couple men with coonskin hats in a canoe going on a little trip, not 33 soldiers on a three-year mission. (The name “Lewis and Clark” doesn’t help, implying that they were the expedition rather than the leaders of the expedition.) I didn’t appreciate the scope or danger of the voyage until I read Ambrose’s book as an adult. I hope someone writes a children’s book in the style of Team Moon about the expedition if there’s not already such a book.

I posted some notes this evening on working with probability distributions in Mathematica and R/S-PLUS.

I much prefer Mathematica’s syntax. The first time I had to read some R code I ran across a statement something like runif(1, 3, 4). I thought it was some sort of conditional executation statement: run something if some condition holds. No, the code generates a random value uniformly from the interval (3, 4). The corresponding Mathematica syntax is Random[ UniformDistribution[3,4] ].

Another example. The statement pnorm(x, m, s) in R corresponds to PDF[ NormalDistribution[m, s], x ] in Mathematica. Both evaluate the PDF of a normal random variable with mean m and standard deviation s at the point x.

It’s a matter of taste. Some people prefer terse notation, especially for things they use frequently. I’d rather type more and remember less.

Some programming languages are much easier to come back to than others. In my previous post I mentioned that Mathematica is easy to come back to, put Perl is not.

I found it easy to come back LaTeX after not using it for a while. It has a few quirks, but it’s basically consistent. The LaTeX commands for Greek letters are their names, lower case names for lower case letters, upper case names for upper case letters. The command for a mathematical symbol is usually the name a mathematician would give the symbol. Modes always begin with \begin and end with \end.

Python also has a consistent syntax that make it easier to come back to the language after a break. Someone has said that Python is similar to Perl, except that the word “except” does not appear nearly so often in the Python documentation.

It’s more important that a language be internally consistent than conventional. Each of the languages I mentioned have their peculiarities. Mathematica uses square brackets for function argument arguments. LaTeX uses percent signs for comments. Python uses indention to denote blocks. Each of these take a little getting used to, but each makes sense in its own context.

A special case of consistency is using full names for keywords. Mathematica always spells out words in full. For example, the gamma distribution object is named GammaDistribution. I don’t mind a little extra typing. I’d rather optimize for recall and readability than minimize keystrokes since I spend more time recalling and reading than typing. (One flaw in LaTeX is that it occasionally uses unnecessary abbreviations. For example, \infty for infinity. The corresponding Mathematica keyword is Infinity.)

Mathematica was first released June 23, 1988. I started using Mathematica not long after it came out and used it for a few years. Then for several years after that I didn’t touch it. When I began using Mathematica again several years after that, I was afraid that like Rip Van Winkle, I’d find many things had changed while I was gone. Instead, I was pleasantly surprised how easy it was to start using it again.

Mathematica syntax is simple, consistent, and predictable. They got this right twenty years ago and stuck to it. They’ve managed to grow over the years without alienating users, even those of us who take a long hiatus from using the product. I’ve used Mathematica more or less regularly over the last few years, but I’ll still go for weeks at a time without using it. It’s easy to pick up every time I return to it. (The opposite of my experience with Perl.)