Manage the Magnitude - And Other Developer Lessons from Slide Rules
Develop | Posted February 18, 2014

Slide rules aren’t just old-fashioned computing devices. They’re useful tools for getting work done – and can help us calibrate our goals, too.

How much building material do we need? Should we mix up 25 bags of cement, 250, or 2,500? That’s the sort of question that engineers need to know instinctively before they reach for a spreadsheet, Mathematica, pocket calculator, AutoCAD, smartphone app — or slide rule.

It’s essential to have a feel for the magnitude of a problem’s solution. That’s one of the lessons that the slide rule can teach software developers. Before you look to solve a problem precisely, you should have a feeling, deep in your gut, as to what a proper answer should look like.

As someone who started his computer science career by programming calculators like the HP-67 and the TI-59 back in high school, I was exposed to slide rules at the tail end of their era. I never relied upon them in the field, but over the years have amassed a pretty sizeable collection of slipsticks (as they’re also called), ranging from a little Pickett N600-ES 6-inch speed rule that was favored by early Apollo astronauts  to a four-foot wooden rule that used to hang in a Texas classroom. I have a Nestler 23 model that was enjoyed by scientists like Albert Einstein and rocket engineer Werner von Braun.

Slide rules inspire me. Plus, they’re always fun to whip out at cocktail parties or tech conferences.

Here are five lessons that I’ve learned from my study of slide rules – and which apply to developers today.

[caption id="attachment_18534" align="aligncenter" width="456"] The intersection of math and mobility: Alan decides to “log” a few miles with his Pickett classroom slide rule.[/caption]

### 1. At the end of the day, it’s all about calculating a number.

Slide rules are practical. They multiply. They divide. (They don’t add or subtract.) They do roots, powers, tangents, natural logarithms. Specialized models help calculate the angle of a gun barrel, or figure the monthly payment for a 10-year fix-interest loan.

Mathematicians rarely use slide rules because mathematicians, oddly enough, don’t care about numbers. They care about equations and theorems and proofs and relationships. Mathematicians want to know symbolically how to solve for x if you are calculating the velocity of a projectile. They rarely if ever care that x in your specific scenario works out to 5.67 feet per second.

Slide rules are used to solve for the actual number. So are most software programs. We design algorithms and code equations into our source code. When the software executes, a number must pop out somewhere, either to be given to the end user or to be used in some other programmatic way (such as in a video game’s animation). Just as an architect could use a slide rule to discover how many square feet of paneling to order for an apartment building’s interior walls, so too our software’s users generally use our software because they want a real answer to a real question.

### 2. We must manually manage the magnitude of our results.

Slide rules are notorious for not understanding the concept of the decimal point. It’s left up to the engineer to keep track of the magnitude of the result in his head (or by writing it down on a sheet of paper). To put it another way, it’s all scientific notation. The slide rule handles the mantissa, and the engineer manages the exponent.

An architect should have a rough feel for how many square feet of tiles are needed before she sits down to figure out the exact number, no matter what type of manual or automated tool is used. Is it a few dozen? A few hundred? A few thousand? A few tens of thousand? When the architectural software (or spreadsheet or whatever) comes back and says 3,250 square feet, that’s got to pass the sniff test.

Let’s say that we are carpeting an space that is 52 feet by 317 feet, and we want to know how many square feet of carpet to order. We can tell, by inspection, that it’s a bit more than 50 x 300, or 15,000 square feet. That’s easy. Duh. When we do the math on our calculator, it tells us 16,484. That smells right. We know that 1648.4 would be too small, and 164,840 would be too big.

In the slide rule world, we’d reformat the calculation to (5.2 x 10^1) x (3.17 x 10^2), and then split it apart:

• Let the slide rule do the 5.2 x 3.17 multiplication. That gives 16.484. The slide rule would show that as 1.65, by the way, but the way the scales work shows that the result was larger than 10 – in other words, 1.65 x 10^1.

• It’s left to us to manage the exponents – specifically, to add the exponents. We add up the exponents of 10^1 and 10^2, which comes to 10^3, and add the extra 10^1 as shown above. That gives us 10^4.

Bring the answers together, and the result is 1.65 x 10^4, or 16,500. Bingo!

A working engineer (or carpeting installer) should have that order-of-magnitude feel before picking up the calculator. Or the slide rule. Otherwise, he can’t trust the results. (And he will have a lot of spare carpeting on his hands.)

### 3. Beware of worshiping false precision.

The cheapest pocket calculator, even back in the 1970s, would solve problems to within eight decimal points. A slide rule, however, generally only gives three or four decimal points of precision, based on the size and quality of the rule, and of the skill of the operator.

Frankly, in the real world, three or four digits of precision is about the right amount. The eight or more digits from a pocket calculator, and even greater precision in a lot of software, exceeds the error in our real-world measurements.

Take the carpeting calculator. We have three digits of accuracy at most for our input data of 317 feet and 52 feet. (After all, we don’t really know if it’s 316.8 feet or 317.4 feet.) We can trust three digits. If you multiply those together, you can’t trust more than three digits either. In other words, while the calculator or Excel or AutoCad or some carpet-laying app tells us that 52 feet x 317 feet is 16,484 square feet, that’s too precise for our carpet-buyer. All we know is that we need “between 16,400 and 16,500 square feet” of carpet. In other words, it is best to order at least 16,500 square feet.

A slide rule operator, squinting to figure out exactly where the digits are, can generally feel really good about two digits of precision, and fairly good about three. Four digits? Fuggedaboutit.

In the real world, you almost never need more than three digits of precision. For anything. Cooking. Medicine. Carpeting. Tiles. Calories in a diet. The gallons or liters of water in a swimming pool. Yes, in some areas – such as calculating the thrust for a rocket launch, or the exact payoff amount for a mortgage – you may need more precision. But in those cases, engineers used slide rules to get very fast, very good approximations, which would do until almost the final moment. (Before calculators, bankers used books of look-up tables.)

Electronic calculators appeared in the 1970s. The first models did simple addition, subtraction, multiplication, and division, and they started edging out adding machines. When models from Hewlett-Packard and Texas Instruments started doing square roots, exponents, logarithms, and trigonometry, those so-called “slide rule” calculators killed the real slide rules. Electronic calculators were faster, they didn’t require the skills that slide rules required, and they took care of managing the magnitude. Calculators also appeared to be more accurate, with their eight digits of precision. From a numerical perspective, they indeed were more accurate.

However, working engineers knew that it was false precision: In real-world problems, the extra digits were meaningless. Today, we have forgotten that.

### 4. We have to understand, at a visceral and visual level, how the math works.

My slide rule collection has dozens of models. Some are quite simple. Others, like my Pickett Model 14 (designed for the U.S. military’s field artillery) have specialized calculation scales. One of my slide rules  has more than 34 scales!

When you have a pocket calculator, or use spreadsheet functions like atanh (calculate the inverse hyperbolic tangent), you push a button and there’s a result. You may know what an inverse hyperbolic tangent is, or you may not; perhaps you are copying the formula or algorithm out of a book.

With a slipstick, you may also be working a problem out of a textbook, professional handbook, or field guide. However, you’re unlikely to get the right answer unless you not only know what that math operation is, but also how the scale works and how it relates to the real world. (Many slide rule manufacturers created wonderful instruction books for their instruments.)

It’s my own gut feel, but I think that seeing the calculation, and actually performing the calculation yourself gives the operator a better feel for whether it’s the right calculation and what it means.

If you are coding math-library functions into your algorithms, do you truly understand what the library does, how it works, its limitations, and its precision? Do you know how to verify if is returning a result that fits the real world? And in a larger sense, even when you aren’t working with mathematical calculations: How do you know when you have the right answer? Does it mean you are asking the right questions? It is something to think about.

### 5. Math is fun – and math is fundamental.

The term “computer” used to mean a person who did computation – that is, calculations. Once upon a time, many of us used computers primarily for math. That was in the era of punch cards, of course – long before computers were used for data processing, for document management, for image processing (which of course is math), office automation (Excel – math again), communication (email), social networking, and ultimately, of course, watching cat videos on YouTube.

When I started programming, what I had access to were programmable calculators — and so most of my programs were math oriented. In the 1970s and 1980s, I wrote and shared many programs with the HP and TI community, most of which were oriented around number theory and geometry, such as calculating areas of arbitrary polygons or finding the most efficient ways to generate Pythagorean triples. Great fun. When I moved over to bigger machines, including IBM mainframes, again, much of my work involved math.

Whether today we are using computers to navigate Facebook’s social graph, or launching Google’s search algorithm with a query on our smartphone, running MATLAB or asking merging photos using high-dynamic-range imaging, math is still at the heart of our computing experience. It’s just hidden. Playing with slide rules reminds us where we came from.