I’m in the middle of a series of posts concerning the elementary operation of computing a square root. This is such an elementary operation because nearly every calculator has a button, and so students today are accustomed to quickly getting an answer without giving much thought to (1) what the answer means or (2) what magic the calculator uses to find square roots. I like to show my future secondary teachers a brief history on this topic… partially to deepen their knowledge about what they likely think is a simple concept, but also to give them a little appreciation for their elders.

In Parts 3-5 of this series, I discussed how log tables were used in previous generations to compute logarithms and antilogarithms.

Today’s topic — log tables — not only applies to square roots but also multiplication, division, and raising numbers to any exponent (not just to the power). After showing how log tables were used in the past, I’ll conclude with some thoughts about its effectiveness for teaching students logarithms for the first time.

To begin, let’s again go back to a time before the advent of pocket calculators… say, the 1880s.

Aside from a love of the movies of both Jimmy Stewart and John Wayne, I chose the 1880s on purpose. By the end of that decade, James Buchanan Eads had built a bridge over the Mississippi River and had designed a jetty system that allowed year-round navigation on the Mississippi River. Construction had begun on the Panama Canal. In New York, the Brooklyn Bridge (then the longest suspension bridge in the world) was open for business. And the newly dedicated Statue of Liberty was welcoming American immigrants to Ellis Island.

And these feats of engineering were accomplished without the use of pocket calculators.

Here’s a perfectly respectable way that someone in the 1880s could have computed to reasonably high precision. Let’s write

.

Take the base-10 logarithm of both sides.

.

Then log tables can be used to compute .

**Step 1.** In our case, we’re trying to find . We know that and , so the answer must be between and . More precisely,

.

To find , we see from the table that

and

So, to estimate , we will employ linear interpolation. That’s a fancy way of saying “Find the line connecting and , and find the point on the line whose coordinate is . Finding this line is a straightforward exercise in the point-slope form of a line:

So we estimate . Thus, so far in the calculation, we have

**Step 2.** We then take the *antilogarithm* of both sides. The term *antilogarithm *isn’t used much anymore, but the principle is still taught in schools: take to the power of both the left- and right-hand sides. We obtain

The first part of the right-hand side is easy: . For the second-part, we use the log table again, but in reverse. We try to find the numbers that are closest to in the body of the table. In our case, we find that

and .

Once again, we use linear interpolation to find the line connecting and , except this time the coordinate of is known and the coordinate is unknown.

Since the table is only accurate to four significant digits, we estimate that . Therefore,

By way of comparison, the answer is , rounding at the hundredths digit. Not bad, for a generation born before the advent of calculators.

With a little practice, one can do the above calculations with relative ease. Also, many log tables of the past had a column called “proportional parts” that essentially replaced the step of linear interpolation, thus speeding the use of the table considerably.

Log tables can be used for calculations more complex than finding a square root. For example, suppose I need to calculate

Using the log table, and without using a calculator, I find that

That’s the correct answer to four significant digits. Using a calculator, we find the answer is

I got sqrt(4213) by noting that 65 squared is 4225, that is 12 too high. So I adjusted the initial guess by 12/(2*65) = 0.09023. This resulted in an improved estimate of 64.9077. Sorry about the error in the last digit, but I beat the 4 place log table. On the other hand, had I used the table to get my initial guess, the adjusted guess might be good to ten significant figures. You were wise to leave out the proportional parts columns from the table you displayed. It is garbage that can contribute significant error to the end result… especially at the low end of the table. A much better interpolation is to use Log(x+d) = Log(x) + 0.4343*d/(x+d/2), where Log(x) is the nearest tabulated value, and d is the value of the remaining digits (d might be negative).

Thanks for writing. I agree that your method for finding sqrt(4213) works well; I wrote about this technique later in this series: https://meangreenmath.com/2013/08/10/square-roots-without-a-calculator-part-10/

I also agree that your interpolation of logarithms is better than proportional parts. I don’t think I had seen it expressed in a form that doesn’t explicitly use calculus for the interpolation.

i have a come across a problem sir

i wish to find sq. root of 0.4263/0.9559

log0.4263 = 1 bar.6297

log0.9804= 1 bar.9804

so log a/b = log a – logb

i.e. 1 bar.6297 – 1bar. 9804 = 1bar .6493

for sq. root 1/2(1 bar.6493) =?

is it 0.82465? or 1 bar.82465?

because antilog of the later gives correct answer.

but im not sure about the answer please help.

One detail I would do for numbers less than 1 with negative logarithms: instead of “bar”, I add an integer to the fractional part of the log that is a biased exponent. The bias is 100. So prefix logarithms of numbers between 0.1 and 1 with 99, numbers between 0.01 and 0.1 with 98, etc. Of course, if you are an oldie like me and you began life with a slide rule, you already do this mentally.

Does anybody out there have experience with the HP Prime or the TInspire CAS? I am stumped trying to derive Ln(x) = 2( (x-1)/(x+1) +((x-1)/(x+1))^3 + … It is a great tool; I no longer need Wolfram’s power series widget.

I noticed a typo in Step 1. You wrote 4.123 transposing the 1 and 2. I made this mistake a lot in accounting class when I was in school. So frustrating to find your mistake when that happens. 🙂

Fixed. Thanks for the catch.