Month: August 2012

Size of ancient and modern bureaucracies

Posted on by John

According to The History of Rome, episode 126, Diocletian increased the size of the Roman imperial bureaucracy from around 15,000 people to around 30,000.

I wanted to compare the size of the bureaucracy that ran the Roman Empire to the size of the bureaucracy that runs Houston, TX. This page suggests that the city of Houston has about 68,000 employees. But far more people work for government in other capacities than work for the city. According to Table 1 of this page, the latest estimate is that 361,800 in the Houston MSA work in the government sector. And about 22 million people work in the government sector nation wide.

Please don’t leave comments saying the Roman Empire and Houston are not directly comparable. Of course they’re not. But still, a very rough comparison is interesting.

Related post: Pax Romana

Software idioms

Posted on by John

From Alan Perlis:

Since large programs grow from small ones, it is crucial that we develop an arsenal of standard program structures of whose correctness we have become sure — we call them idioms — and learn to combine them into larger structures using organizational techniques of proven value.

George Boole, Claude Shannon, and information

Posted on by John

Paul Nahin writes books that are somewhere between popular and academic. His books are popular, but not light reading. They tell a story, but they go into more detail than most popular books. (I haven’t read everything Nahin has written, but I’ve noticed this pattern in his books I have read.)

Nahin’s latest book is The Logician and the Engineer: How George Boole and Claude Shannon Created the Information Age (ISBN 0691151008). The title may be a little misleading. The book includes brief biographies of Boole and Shannon, but it is more about the ideas of Boole and Shannon (and others) than about the lives of these men. It discusses logic and information theory, and contains a fair amount of history, but it is not a rigorous historical account. Nahin uses Boole and Shannon a device for writing his book, something like the way Douglas Hofstadter uses Gödel, Escher, and Bach in Gödel, Escher, Bach.

The Logician and the Engineer dives into logic and probability from the perspective of an electrical engineer. The book moves seamlessly between abstract mathematics and electronic circuits. You don’t need to know much about electronics before reading the book, but you will see how logic concepts correspond directly to hardware. This is the heart of the book, and it is well done.

The last chapter of the book quickly discusses thermodynamics, and quantum computing. You could say The Logician and the Engineer is a book about basic electrical engineering, sandwiched between a historical introduction and a view of the future.

Other posts about Nahin’s books

Vague priors are informative

Posted on by John

Data analysis has to start from some set of assumptions. Bayesian prior distributions drive some people crazy because they make assumptions explicit that people prefer to leave implicit. But there’s no escaping the need to make some sort of prior assumptions, whether you’re doing Bayesian statistics or not.

One attempt to avoid specifying a prior distribution is to start with a “non-informative” prior. David Hogg gives a good explanation of why this doesn’t accomplish what some think it does.

In practice, investigators often want to “assume nothing” and put a very or infinitely broad prior on the parameters; of course putting a broad prior is not equivalent to assuming nothing, it is just as severe an assumption as any other prior. For example, even if you go with a very broad prior on the parameter a, that is a different assumption than the same form of very broad prior on a2 or on arctan(a). The prior doesn’t just set the ranges of parameters, it places a measure on parameter space. That’s why it is so important.

More posts on Bayesian statistics

Follow up on recent posts

Posted on by John

Here are a few updates on recent blog posts.

Bicycle skills has been the most popular post of the summer. The title only makes sense after you’ve read the post, so I wondered whether many people would read it.

Changing the way I type has gone well.

  • Although I prefer my new keyboard, I don’t have any difficulty using a standard keyboard when I need to.
  • The space bar on the new keyboard made a lot of noise at first, but it’s quieter now that it has been broken in.
  • Using the Control and Alt keys with the opposite hand of the letter they modify took more effort to get used to than the new keyboard, but this has helped me relax my hands while I type. Modifying the control keys helped me change habits, and so did practicing with Shortcut Foo.

My previous post gave four reasons why more people don’t roast coffee beans. I got lots of interesting comments from people who do roast their own coffee beans, including my favorite from Ben Cutler.

I like my new AeroPress. I’ve experimented with various ways of using it, but I basically follow the instructions that come with it.

Roasting coffee beans

Posted on by John

My daughter asked me yesterday whether I’d thought about roasting my own coffee beans. I told her no, that I thought that for whatever reason people didn’t often roast coffee beans at home, but I didn’t know why.

Today I asked an expert about this, someone who roasts and distributes coffee. He said that you can roast coffee at home, but most people don’t for these reasons.

  1. You can roast coffee in an ordinary oven, but the quality of the roast will be uneven.
  2. You can buy a machine for roasting coffee beans, but these machines are expensive and don’t roast much coffee at a time.
  3. It’s hard to find green coffee beans unless you are buying in wholesale quantities, e.g. 100 pound bags.
  4. The smell is overwhelming.

The last point surprised me. I imagined the smell of roasting coffee beans would be wonderful, but apparently it’s too much of a good thing.

Update: See the comments for different views and suggestions.

Bicycle skills

Posted on by John

A while back I wrote about learning things just-in-case or just-in-time. Some things you learn in case you need them in the future, and some things you learn as needed.

How do you decide whether something is worth learning ahead of time, or whether it is best to learn if and when you need it? This is a common dilemma, especially in technology. There’s no easy answer. You have to decide what is best in your circumstances. But here’s a suggestion: Learn real-time skills and bicycle skills in advance.

A real-time skill is something you need for live performance. If you’re going to speak French, you have to memorize a large number words before you need them in conversation. Looking up every word in a English-French dictionary as needed might work in the privacy of your study, but it would be infuriatingly slow in a face-to-face conversation. Some skills that we don’t think of as being real-time become real-time when you have to use them while interacting with other people.

More subtle than real-time skills are what I’m calling bicycle skills. Suppose you own a bicycle but haven’t learned to ride it. Each day you need to go to a store half a mile away. Each day you face the decision whether to walk or learn to ride the bicycle. It takes less time to just walk to the store than to learn to ride the bicycle and ride to the store. If you always do what is fastest that day, you’ll walk every day. I’m thinking of a bicycle skill as anything that doesn’t take too long to learn, quickly repays time invested, but will never happen without deliberate effort.

When you’re under pressure, you don’t learn bicycle skills. You don’t make long-term investments, even if the “long-term” is 30 minutes away. I’ll just walk, thank you.

What are bicycle skills you need to learn, things that would save time in the long run but haven’t been worthwhile in the short term?