I’m starting a new daily tip Twitter account: RLangTip. This account will have one regularly scheduled tip per day, Monday through Friday, on the R language and related topics. I’ll also throw in a few unscheduled tweets now and then.
If you’re interested in R, you may also be interested in other daily tip accounts such as ProbFact, StatFact, and CompSciFact.
Some say that aerodynamics can’t explain how a bumblebee flies. Perhaps that was once the case, but as far as I know there are no difficulties now. The bumblebee story persists as an urban legend. And it makes a nice metaphor for things that work better in practice than in theory.
Here’s the passage that brought the bumblebee story to mind.
Almost every software engineering principle that has become generally accepted as useful and valuable, Emacs flouts. The code is 24 years old, huge, and written by hundreds of different people. By rights, the whole thing should blow up. But it works—and works rather well.
This comes from Jim Blandy’s chapter in Beautiful Architecture. Blandy explains that Emacs’ architecture has allowed it to thrive despite some apparent disadvantages. Emacs is mostly written in its own programming language, Emacs Lisp.
Emacs Lisp has no object system, it’s module system is just a naming convention, all the fundamental text editing operations use implicit global arguments, and even local variables aren’t quite local.
In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.
TeX is another bumblebee project. Like Emacs, it has thrived for decades without following currently fashionable software techniques. Knuth implies in this presentation that TeX would have been a dismal failure if it had used technologies that are trendy now.
Donald Knuth explains how he combines theory and practice:
This has always been the main credo of my professional life. I have always tried to develop theories that shed light on the practical things I do, and I’ve always tried to do a variety of practical things so that I have a better chance of discovering rich and interesting theories. It seems to me that my chosen field, computer science — information processing — is a field where theory and practice come together more than in any other discipline, because of the nature of computing machines. …
History teaches us that the greatest mathematicians of past centuries combined theory and practice in their own careers. …
The best theory is inspired by practice. The best practice is inspired by theory.
Taken from Selected Papers on Computer Science.
Related post:
“Casting out nines” is a trick for determining the remainder when a number is divided by nine. Just add the digits of the number together. For example, what’s the remainder when 3679 is divided by 9? The same as when 3+6+7+9 = 25 is divided by 9. We can apply the same trick again: 2+5 = 7, so the remainder is 8.
The “casting out” part of the name refers to the fact that you can ignore 9’s along the way because they don’t effect the final sum. In the example above, we could see that the result would be 7 by “casting out” 36 and 9.
Casting out nines works because 9 is one less than 10, i.e. one less than the base we use to represent numbers. The analogous trick would work casting out (b-1)’s in base b. So you could cast out 7’s in base 8, or F‘s in base 16, or Z’s in base 36.
Why can you cast out (b-1)’s in base b? First, a number written is base b is a polynomial in b. If the representation of a number x is anan-1 … a1a0 then
x = anbn + an-1bn-1 + … + a1b + a0.
Since
bm – 1 = (b – 1)(bm-1 + bm-2 + … + 1)
it follows that bm leaves a remainder of 1 when divided by b – 1. So ambm leaves the same remainder as am when divided by b – 1. If follows that
anbn + an-1bn-1 + … + a1b + a0
has the same remainder when divided by b – 1 as
an + an-1 + … + a1 + a0
does when it is divided by b – 1.
Here are some common patterns in Unix command options. This is a summary of the patterns Eric Raymond describes here.
| Option | Typical meaning |
|---|---|
| -a | All, append |
| -b | Buffer,block size, batch |
| -c | Command, check |
| -d | Debug, delete, directory |
| -D | Define |
| -e | Execute, edit |
| -f | File, force |
| -h | Headers, help |
| -i | Initialize |
| -I | Include |
| -k | Keep, kill |
| -l | List, long, load |
| -m | Message |
| -n | Number, not |
| -o | Output |
| -p | Port, protocol |
| -q | Quiet |
| -r | Recurse, reverse |
| -s | Silent, subject |
| -t | Tag |
| -u | User |
| -v | Verbose |
| -V | Version |
| -w | Width, warning |
| -x | Enable debugging, extract |
| -y | Yes |
| -z | Enable compression |
Here are five posts on mythology, using the word “myth” three different ways.
First, classical mythology:
Why Shakespeare is hard to read
Jupiter’s magic square
Next, myth as a false idea:
Two myths I learned in college: bathtub drains and airplane wings
And finally, myth in the abstract sociological sense:
Software development and the myth of progress
The myth of the Lisp genius
While I was looking up the Tukey quote in my earlier post, I ran another of his quotes:
The test of a good procedure is how well it works, not how well it is understood.
At some level, it’s hard to argue against this. Statistical procedures operate on empirical data, so it makes sense that the procedures themselves be evaluated empirically.
But I question whether we really know that a statistical procedure works well if it isn’t well understood. Specifically, I’m skeptical of complex statistical methods whose only credentials are a handful of simulations. “We don’t have any theoretical results, buy hey, it works well in practice. Just look at the simulations.”
Every method works well on the scenarios its author publishes, almost by definition. If the method didn’t handle a scenario well, the author would publish a different scenario. Even if the author didn’t select the most flattering scenarios, he or she may simply not have considered unflattering scenarios. The latter is particularly understandable, almost inevitable.
Simulation results would have more credibility if an adversary rather than an advocate chose the scenarios. Even so, an adversary and an advocate may share the same blind spots and not explore certain situations. Unless there’s a way to argue that a set of scenarios adequately samples the space of possible inputs, it’s hard to have a great deal of confidence in a method based on simulation results alone.
Seth Godin uses linchpins as a metaphor for people who are indispensable. These people hold things together much as a physical linchpin holds together a mechanical system. But the metaphor works in a couple ways that I don’t believe the author intended.
First, linchpins are invisible. When was the last time you looked at a complex mechanical system and your eyes were immediately drawn to a linchpin? People who hold things together are often unsung heroes. They do such a good job that they don’t draw attention to themselves. People who prevent fires are harder to notice than people who put out fires.
Second, and more importantly, linchpins have to stay in place. Remove a linchpin and something comes apart. A human linchpin can never be promoted or work on new projects because they’re indispensable right where they are. Managers may show their appreciation for a linchpin, or they may react out of fear and resentment when they realize their dependence. They may even do a weird mixture of both.
Seth Godin’s Linchpin book was a fun read. I just wish he had picked something other than linchpins as his metaphor for people who are highly valued. And I wish he hadn’t used the word “indispensable.” Too often indispensable people are not highly valued.
Here’s a recent discussion from Math Overflow.
Q: I have some data points and, when I plot them on R, it looks like a normal distribution. I want to know how well my data fits the normal distribution. What kind of test should I do?
A: There’s actually a much broader question that you should be asking yourself here: does it matter whether your data really is normally distributed, or will the procedures that you’re going to perform on the data be reasonably robust in the presence of a distribution that is only approximately normal? …
The person asking the question was already satisfied that his data were approximately normal. So it was time to move on to the next question: Does what I want to do next work well for approximately normal data? (There’s no point asking whether your data is normal; it’s not. Normality is an idealization.)
We’re often tempted to add decimal places to the answer to one question instead of moving on to the next question. Maybe we don’t even realize what the next question should be. Or maybe we do know but we want stay with the familiar. In either case, this quote from John Tukey comes to mind.
An approximate answer to the right problem is worth a good deal more than an exact answer to an approximate problem.
Related post: What distribution does my data have?
Here’s an interesting phrase:
superficial convenience at the expense of real freedom
This comes from the conclusion of the 1998 essay The Elements of Style: UNIX as Literature by Thomas Scoville. The author sums up his preference for UNIX culture by saying he prefers the “freedom and responsibility that UNIX allows” to the “superficial convenience” of Windows NT.
I’m not interested in arguing here the relative merits of Unix and Windows. I’m more interested in broader ideas that spin off from the quote above. When is a convenience superficial? How well does convenience versus freedom explain technological controversies?
I could see substituting “short-term convenience” for “superficial convenience” and substituting “long-term efficiency” for “real freedom.” But that may lose something. Thomas Scoville’s terms may be more nuanced than my substitutions.
