Pages

Showing posts with label Mathematics. Show all posts
Showing posts with label Mathematics. Show all posts

Sunday, March 11, 2012

Two is an Ellipse, Three Chaos

A while back I finished reading one of my stellar Christmas gifts, Mathematics: The Loss of Certainty by Morris Kline. It has the singular distinction among books I’ve read that about a month after I’d finished it, I began to read it for the second time again. Yes, I do; I read books over and over; the good ones; but usually each reading years apart. One of the intriguing discoveries I made in this one, early, is that there is no straight-forward way of calculating with precision the movement of three bodies linked by gravitational attraction, what is known as the three-body problem. Newton tackled this problem after he had elegantly solved the two-body problem—thus, for example, the  movement of the earth around the sun. In such calculations, one assumes that one body is standing still and then measures the other, and the upshot is that the moving body’s orbit is elliptical. But when minimally three bodies are involved, precise prediction of their interacting movements can never be produced simply by the applications of algorithms; only approximations are possible. Imagine that. We can observe, we can measure, but we can’t predict precisely using math.

However splendid the Internet, mathematical subjects are almost never covered well for the amateur. Virtually all are written by mathematicians for other mathematicians. I make this post to note an exception. It is the explanation of the three-body problem by Ask a Mathematician / Ask a Physicist (link). Very nice explanation. The last comment on this article suggests that the problem has actually been solved satisfactorily. That comment is best ignored. The solution there requires that we succeed in summing up an infinite series; but who has time to do that?

Saturday, January 14, 2012

Negative Numbers

Reading a superb book on the history of mathematics (Mathematics: The Loss of Certainty by Morris Kline) reminded me of the extent to which we take things for granted, especially when we learned them very early in life. One subject that used to plague the ancients was negative numbers. So I got to thinking. If we view mathematics as a language, then the meaning of that language rests on an agreement by all the parties using it what different notations mean. So let us look at one possible explanation for negative numbers:

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9

One way to see this series is that negatives belong to one domain, positives to another, and the big divide between them is the zero. When it comes to addition or subtraction, we simply begin at the point indicated by the sign of the first number and then march left or right as indicated by the sign between them and the sign of the second number. Here is 3 + 5:

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
                                     |______________|

Here is 3 + -5. The negativity of the 5 indicates that we need to march to the left.

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
                      |______________|

Now let us take -3 + -5:

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
    |______________|

And its inverse, -3 + 5:

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
                   |______________|

Now I discover what is really a seeming inconsistency in our language—provided, of course, that it is based on equivalent domains separated by a zero. Consider the following. 2 * 2 = 4; this means that we move two positions to the right from 2. And -2 * 2 = -4. That’s also consistent—because, finding ourselves in the negative domain, we move two positions to the left of -2 as shown for both cases here:

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
                |_____|           |_____|

Here the general rule would be that when we multiply, we move in the increasing direction of the domain if the multiplier is positive and in the decreasing direction, still of that domain, if the multiplier is negative. But consider next what happens when we take -2 * -2 = 4 or 2 * -2 = -4. In the negative domain, we should move right if the multiplier is negative; in the positive domain, with a negative multiplier, we should move to the left. As above.  If we applied that rule, both cases would yield zero as shown below.

-9 -8 -7 -6 -5 -4 -3 -2 -1  0  1  2  3  4  5  6  7  8  9
                      |_____|_____|

But they do not. What we do is multiply the two number first and then we assign the sign based on a rule of signs. This is an arbitrary element in our math or, minimally, is no long capable of being tracked in a visual model. The inconsistency continues when we use exponents, which indicate multiplication. For example, both 22 and -22 yield four (one must believe Excel). And -2-2 yields 0.25. Here we still cling to the explanation that multiplication of values of the same sign yields a positive number.

What these results tell me is that our mathematics uses a different conceptualization for the negative numbers than that of a domain. It uses the notion of gain and loss. Thus -22 is positive because it reduces the losses by 4, as does the equivalent -2 * -2. The last answer, 0.25 as the result of -2-2, results because the negative exponent signals successive divisions rather than multiplications. Thus that number means:

-2-2 = (1 / -2) / (-2) = 0.25

But if we chart that result, thus moving to the right, because division means decrease,  we should end up with -0.25, not with a positive value. But the number becomes positive because of our rules. The first result is -0.5 which, divided by -2, turns positive—albeit it is still on the negative side of the zero. We get exactly the same result if we solve for 2-2. Thus the notion of a domain, as depicted above, corresponding to some physically imaginable plain, has been “suspended” here. 2-2 should result in 0.25, -2-2 should yield -0.25.

This field might have been so very different if, instead of the concept of negation, we would have viewed negative numbers as differently colored. Call them red

Sunday, November 6, 2011

Japanese Method for Pulling Square Roots by Hand

Take two, you might say. An earlier post introduced this method (link), but while it is perfectly correct as far as it goes, it actually provides a German version of how to solve the problem of squaring. I learned of the Japanese method from Murai Takayuki. A second set of message from Murai finally enabled me to see how the Japanese actually do it. It is presented here. The example I shall use is to calculate the square root of 99—which presents problems when using the German mehod I described earlier.

The Japanese method involves a two-column approach. Calculations on the left side provide inputs for the division-like calculation on the right side. We also obtain successive digits of the actual answer on the left side. The following illustration sums up the method. Click to enlarge, press Esc to return:


As explained in the earlier post, the number is arrayed in digital pairs. The decimal point, if any, must fall on one of the spatial divisions. Therefore, the number 3.099, for example, must be divided 03 . 09 90 not 3.0 99.

The core of this process is the method by which the digits are determined. In the earlier post, showing the European formula instead of the Japanese (e.g. 18 *  ≤ 1800 explained above), two equations are used to calculate first the next digit of the Answer and the sum to be deducted from the last Remainder. Let us take the case, above where the first 4 is obtained. Using the Japanese method, we set up 198 *  ≤ 9900. We can start with the highest digit, 9. Therefore we get 1989 * 9 = 17901. That’s too big. Next we might try 5, therefore 1985 * 5 = 9925. Still too big. The next attempt, with 4, will succeed: 1984 * 4 = 7936. That’s quite simple. We get, at once, both the next digit of our answer, 4, and the sum to deduct, 7936.

The European method begins with a division. The last Remainder (9900) is divided by a number constructed by multiplying 2 * 10 * the already calculated Answer. In this case that number is 99, and 99 rather than 9.9 because the decimal is ignored. 2 * 10 * 99 = 1980. Then 9900 / 1980 = 5. Next we test that number. We take (1980 + 5) * 5 = 9925. But that number is too high. Therefore we reduce 5 by 1 to get 4. Next we apply the new number, thus (1980+4) * 4 = 7936.

As is evident, this process is much more complicated than the method Murai suggests. We have to engage in double-column bookkeeping, to be sure, but everything is clearer, and the procedure is much simpler.

Nice, handy method, readily used with a sheet of paper divided in two and a hand calculator.

For those able to read Japanese an excellent tutorial with live demos is available here from suguru.jp. Google will translate the Japanese into English. The result is so-so but one can make out the sense and follow the numbers.

Thanks Murai. This has been a lot of fun.

Saturday, November 5, 2011

Square Root Extraction the Japanese Way

A comment came today from Murai Takayuki (村井 剛志) in comment on my piece on calculating logarithms by hand. In that post I suggested that a certain weariness also accompanies pulling square roots by hand. Murai wrote: “In Japanese schools we learn a method resembling long division for finding square roots by hand. If you haven't ever heard about this method I would love to tell you about it!!” Now it turns out that I’ve also published here a relatively easy method (link), but I’m always game for new ways—hence I asked for enlightenment and immediately got it by a returning e-mail. The missive took the form of two images. You can see one of them here on the left. Clicking through it will make it big; Esc will bring you back. Murai’s accompanying instructions, alas, were pretty brief: “I think you can figure out how it works with these two images.” I was flattered but baffled. Now it so happens that at least 65 years have passed since I was in school and learning such things; therefore I utterly failed to grasp the progression of numbers. English language web sites all flunked too—as indeed I had expected them to do. Then a brilliant notion came. I tried a web search in German and rapidly found multiple sites able to give me what I needed. As in Japan, so in Germany. Herewith, therefore, the results. (Mind, I could have asked Murai to help as well, but I thought he’d already done enough.) So let us take the problem presented in that image. The other JPEG Murai sent is much the same. In that one the square root of 5 is pulled using the method I describe below.

We want the square root of 628.5049. The first step is to divide the number into pairs from the back as follows:

06 28 | 50 49

The first step is by eyeballing, the other steps are by using two formulae.

Step 1: Determine the closest square to the first group. In our case that is 4, 2*2. The root we used is also the first digit of our answer.

Step 2: Deduct the actual number from the first pair, thus 06 - 4. Next pull down the next pair of numbers awaiting action and place them alongside. Here is how it looks:

Note that the root of that 4 is now the first digit of our answer, already in place. The \/ symbolism ahead of the first digit is meant to represent the square root symbol (√).

Step 3: This step and all successive iterations have the same requirement. We want to do two things in this and every succeeding step, if necessary. First, we want to calculate the next digit of our answer. That is done by Formula 1:

[1] Next digit = Int(R / (20*A))

R here is our Remainder (2 28 above) and A is our current Answer, thus the 2 following the equals sign above. The Int means that whatever answer we get will be only the integer part. In this particular instance the formula fleshes out as 228 / (20*2) or 228/40 = 5.7. The Int prefix renders the answer as 5. That is the next digit of our answer.

Next we want to calculate the number to deduct from our Remainder. The formula for that is the following:

[2] New Deducter = ((20*A)+L)* L

Here L is the Last digit to be added to Answer, 5 in this case. The formula fills in as follows: ((20*2)+5)*5 = 45*5 = 225. This is our New Deducter. We put it in place and add the Last digit to the answer. Here is what it looks like now:

Step 4: Notice that after deducting the New Deducter from the last Remainder, we also crossed the decimal point. For this reason we now also add a decimal point to our Answer.

The two formulae we used in the last step are employed again. Formula 1 produces zero. Here the actual numbers: 350 / (20*25) = 350 / 500 = 0.7 = 0 when chopped to an integer. That 0 is our new digit, the Last digit to be added. Formula 2 also produces a 0 as our New Deducter: ((20*25)+0)*0 = 500 * 0 = 0. Our calculation now looks as follows:

Step 5: In this case Step 5 happens to be the last. Note, again, that we have deducted the 0 and were left with the same number. But we’ve also pulled down the last pair to be considered in our calculation. And we’ve added the 0 to our Answer. Here the two formulae used for the last time:

Formula 1: 35049 / (20*250) = 35049 / 5000 = 7.0098 = 7.
Formula 2: ((20*250)+7)*7) = 5007* 7 = 35049.

Notice that in using these formulae, we ignored the decimal point in the Answer. Our New Deducter now has the same value as our last Remainder, hence we are done. In other cases we can stop as soon as we are happy with the number of digits we have produced. The final picture:


With this explanation, Murai’s presentation will become quite clear—and the derivation of those initially mysterious numbers like the 45, 500, and the 5007 will be evident. Come to think of it, the real virtue of this method is that it is very easily rendered into a quite brief algorithm in Visual Basic. Those who know that language will need no help from me in writing the subroutine.

Added later: In playing with these algorithms, I discovered an interesting problem when applying it to the square root of 99. The layout then is the following:

\/99 | 00 00 00 00 00 = 9
     81
  18   00


The nearest square to 99 is 81. That leaves 18, and the first digit of our answer is 9. Adding two zeroes to the Remainder, we get 1800. Then, applying Formula 1, we get 1800 / (20 * 9) = 1800 / 180 = 10. But the square root of 99 is actually 9.94987… per Texas Instruments calculator. Therefore Formula 1 seems to misfire. The rule here appears to be that if the answer to Formula 1 is 10, it must be reduced by one. If we make that adjustment and proceed to the next step using 9 instead of 10, the answer comes out correctly. But my sources do not mention this rule. Perhaps Murai can come to our rescue…

Added Even Later: I received appropriate instructions from Murai Takayuki. The method finally makes sense. To make it plain I provide a new post (link) titled “Japanese Method for Pulling Square Roots by Hand.”

Thursday, April 28, 2011

In Case You Wondered…

Very recently I discussed fractional exponents. In that routine I used only multiplications, divisions, and pulling square roots. But what about pulling square roots by hand? There is a simple formula for that. Alas, it is iterative. Here it is:

square root (eventually) = ½ * ((number /guess) + guess)

A straightforward “guess” is simply to divide the number by two. Let me demonstrate this formula by iteration. Let’s say that we want the square root of 3.13. That will be our number. Half of that is 1.565. That will be our guess.

IterationResult of EquationResult x Result
11.78253.1773062500
21.76923036473.1301760832
31.76918060203.1300000025
41.76918060133.13

In the first iteration, the guess is 1.565. In each successive iteration, the guess used is the result of the last operation. Thus in Iteration 2 the guess is 1.7825. And so on. We stop as soon as result times result is our number.

The bigger the number, the more iterations. The square root of my year of birth (1936) is 44. That took 9 iterations. The square root of 9,876,543.21 is 3142.696804—and that took 15 rounds of what are simply three of the four basic arithmetic operations of multiplication, division, addition, and subtraction.

If you absolutely insist on doing things by hand, it is easy to automate square root pulling in Visual Basic or whatever language you prefer. And such a subroutine could be built into the code I’ve devised (and point to in the earlier posting) to make the operation as “pure” as possible.

Tuesday, April 26, 2011

Hand Calculation of Fractional Decimal Exponents

You have probably looked at numbers like this one: 30.7 and wondered how one actually calculates a number like that. We understand exponents as meaning multiplication of the number by itself exponent times. Thus 32 means 3 x 3. But how do you render that when the exponent is a fraction? Suppose that it was 30.2?

This is not a practical question. Any decent spreadsheet or scientific calculator (Excel or TI-36X in my case) can produce the number in the flash of an eye. But sometimes we wonder how it is really done. This question started to irritate me a while back. In the process I discovered that I shared this irritation with lots of other people. And if they go on the Internet, they will not, repeat, will not, get a satisfactory answer. The answers that are on offer are trivial. They never address questions like the above—three to the power of 0.7. At best you will be told to use log functions or log tables. And that works. But I got to wondering how log tables were calculated. That turned out to be a bit of a nightmare presented here a while back.

Since then I’ve discovered that there are no straight-forward ways to solve that puzzle above except by methods just as complicated as finding the log of a number by hand. When the exponent is an integer value, the process is serial multiplication. To be sure, if the exponent is big, you’ll be at it for a while, e.g. 3139. It turns out that if the exponent is a fraction, the process is serial root pulling. And if a whole number and an fractional power are both present, e.g. 32.7, you have to engage in both operations. First 3^2=9 (by multiplication), then 3^0.7 (by root pulling), equal to 2.15766928, and the last action required is to multiply those two numbers (9 x 2.15766928) in order to get the answer, 19.419.

I went through a dog-in-a-junk-yard process of finding an algorithm that did not itself involve doing anything beyond multiplication, division, and pulling square roots. No powers or exponential functions, no logarithms, common or natural. Finally I hit on the idea of using the very same method the eighteenth century Euler used to find logarithms—to solve for the value of a number raised to a fractional decimal exponent.

I will explain the method here. I first did it using Excel, as before. Next (the process is mind-numbingly slow), I automated it using a Visual Basic program. Both are in an Excel spreadsheet that you can download here.  If you have problems, e-mail me. You can find my e-mail in the About tab. The spreadsheet also has the Visual Basic program embedded within it, accessible by Alt-F11; it also handles negative fractional exponents.

Here is how the process works. And for my example I am using 30.7.

It occurred to me that every number to the power of 1 is that number itself, thus 31 = 3. At the same time one to the zeroeth power (10) is also always 1. This gave me the anchorage for applying Euler’s method—two values that, as it were, bound any fractional decimal. 0.7 is greater than 0, the exponent of 1 and is less than 1, the exponent of any whole number to be raised.

Therefore I started with three numbers. The first is 1. The second is the number to be raised. Third is the decimal fraction to which I want to raise the second.

I arranged the first two as follows:

Col ACol B
NumbersPowers
10
31

I wished to raise 3 to the power of 0.7. (30.7) 0.7 then became my target in Column B — and the value corresponding to it in Column A would then become my answer.

The first two, and their powers, are knowns. Their powers are obtained without any calculation. The number and the target are supplied by the user, in this case me.

The procedure is as follows:

In Col A we multiply 1 * 3 and take the square root of the result (=1.7320508). The formula is SQRT(1*3).

In Col B, we add 0 and 1 and then divide by 2 (0.5). The formula is (0 + 1)/2

The results are entered as the next item in each column:

10
31
1.73205080.5

Our target is 0.7. In the next step, we look in Column B for one value that is higher than the target and one that is lower— and then repeat the process. In this case the next step is to obtain the square root of (3 * 1.7320508) and to divide (1 + 0.5) by 2. The results are shown below. Needless to say, if our last value is the target, we don’t have to go on.

10
31
1.73205080.5
2.2795051 0.75

Once more we find the two values that bracket our target most closely (0.5 is lower, 0.75 is higher) and once more undergo the process.

What we are looking for is 0.7 in column B. When it appears, we’re done—and our answer is in Column A.

This process is automated as a computer algorithm in the spreadsheet I offer for downloading. The program is set to run maximally 35 iterations. It may cycle fewer times if the exponent in Column B matches our target to 10 decimal points. In the case shown above, the answer after 35 cycles is:

10
31
1.73205080.5
2.2795051 0.75
. . .
2.1576692790.6999999997

My TI-36X Scientific Calculator produces 2.15766928; so does Excel. Both round one decimal earlier.

Now it turns out, of course, that in “real life,” meaning life before electronic calculators, finding square roots was an equally painful and slow process of division and multiplication until the right number of digits was found. Which tells me why, in the post-Renaissance period western humanity’s mad nerds (whose characteristics I seem to share) developed all kinds of helpful tables, not least root tables and the logarithms.

Have as much fun as I did!
---------------
Added later: In this later post I describe the process of getting your own square roots by hand as well...

Friday, April 22, 2011

Legislated Pi

I mentioned the other day (here) meeting a lawyer once who could not believe in the indestructibility of matter. Today I chanced across an amusing but true story in Jan Gullberg’s Mathematics from the Birth of Numbers. The story concerns the value of π, which is 3.141593…. That number times the radius of a circle multiplied by itself produces the area of a circle. The dots behind the digits indicate an irrational number. It never terminates and does not have a repeating pattern of decimals. It’s an awkward number—was so especially before electronic calculators came into use—yet used in all manner of ways in math. It was also of great interest for those who thought that they could gain fame and glory by squaring the circle.

Well, the story has it that a physician in Indiana, around about 1896, concluded that simplifying π to the value of 3.2 could greatly benefit humanity in all manner of ways. Indeed he thought that he might make money from this idea. With that in mind he found an influential person in Indiana’s state legislature who introduced a bill defining π as having the value of 3.2 hereafter. The state house passed the bill 67 to 0. As luck would have it, a professor of mathematics just happened to be present at the legislature when the Senate was about to begin its debate on this bill. In a pause of the debate, he succeeded in persuading several senators that the bill was nonsense. The upshot was that the debate was postponed “until a later date.” The legislature of Indiana has not since returned to the subject.

My author generously omits all names in this account, except the name of the state; however, humility is indicated for each and every one of us, no matter where we live. There is truth in saying that we get the legislatures we deserve.

Saturday, April 9, 2011

Calculating the Log of a Number by Hand

I’ve become interested in logarithms—for a reason. Sometimes, like others, I use log scales to show graphics. The reason is that they make it easier to highlight some features of the data. In the process of writing a still unpublished post on that subject, I got to looking deeper at the origins of logarithms. My own penchant is to understand things from the bottom up. Thus I became aware of the fact that one finds very few resources on the Internet that go deeply into ancient things—whereas the easy and superficial is almost over-documented. My initial wonder arose over fractional exponents. Let me get into that first.

We know that the log of numbers of the common (base 10) logarithm are “powers of ten.” The log of 10 is 1; it is not multiplied by anything. It is the base. But 100, which is 10 x 10, is written as 102 and the log of 100 is 2. Log 1,000 is 3, 10,000 is 4, and so on. On multiples of 10, count the zeroes and you know the logarithm of the number. But what about other numbers? If I ask my spreadsheet or calculator for the log of 2, the answer will be 0.30103. Put another way, it means that 2, expressed as a power of 10, is that fraction, and that 10.30103 equals 2. But while the logs of 10 and its multiples make sense, and in every case tell me how often to multiply 10 by itself, how does one handle a fractional log? How do I get from 10.30103 to obtain the answer, 2, without using a logarithmic table? I can’t picture how a number might be multiplied by itself a fractional number of times.

My quest to understand the logs thus began by looking at its originator, John Napier (1550-1617), to see how he came up with those fractions. But it turns out that Napier’s initial logarithm was base 10,000,000—and while tracking his calculations is possible (here is his own account of it)—I was looking at an example of our own now dominant log to the base of 10. In what follows, therefore, I am echoing Leonard Euler (1707-1783), and more specifically a fine article by Ed Sandifer available here the content of which I am here rendering for the amateur. In that process, as I will show, one doesn’t really calculate these logs; one finds them, painstakingly, by pulling roots. First I’ll show a spreadsheet that calculates the log of 2. Next I will explain it.

Euler begins with two numbers the log of which is known from the outset, 1 and 10. The number 2 is between these two. Their logs are 0 and 1. Euler proceeds by multiplying 1 and 10 and pulling the square root. One times 10 is 10, and the square root of that is 3.16228. He performs the identical operation on the logs. Adding logs is to multiply them, therefore 0 + 1 = 1. This he divides by two, equivalent to pulling the square root. The result is 0.5. One can check this result by using a calculator. Sure enough, log(3.16228) is 0.5. The operations are placed under labels: A, B, and this last one, under C. Now, let us understand. He is looking for 2. His first result, 3.16…, is greater than 2. He next multiplies the two values closest to 2 on either side, thus the 1 in A and 3.16.. in C. He multiplies them and pulls the square root again, placing this result (1.77828) into row labeled D. Next he performs the same operation in the log column: 0 + .5 = .5 divided by 2 = .25. And, sure enough, checking that we find that log(1.77828) is .25. So now we’re on our way. Using this method, we proceed to find the two values above to either side of 2 and as close to it as possible. Those two are in rows C and D. Using those we proceed to the next step. I think I’ve gone far enough to make the procedure clear.

When continued, and the illustration documents the steps, we finally get, in row T, the answer we are looking for. We get the number 2 and, in the log column, the value of .301029. The actual number Excel gives me, if I take it out to 20 decimal points (the command typed in the cell is =log(2)) is .30102999566398100000; Excel shortens that to .30103.

Let me here indicate the Excel commands used. In the column labeled Actual, the formula in cell B8 and subsequent cells, references changing as indicated by the comment, is:

=SQRT(B7*B6)

In the column labeled Log, the formula in cell C8 and subsequent cells, references changing, is:

=(C6+C7)/2

The reader might fault me for not pulling my square roots manually. Sorry. I cut myself some slack there. That too is a lengthy process with large numbers, but I do know how to do that.

Finding the first few logs is difficult and time consuming. But later the very nature of the exponents makes the job go faster. Adding logs is multiplication, deducting logs is division. Having the logs of 1, 10, and 2, we can rapidly proceed thus:

• The log of 5 is obtained by dividing 10 by 2, thus 1 - .30103 = .69897.
• The log of 4 is easy too, 2 x 2, thus .3013 + .3013 = .60206.
• The log of 8 is 4 x 2, therefore .30103 + .60206 = .90309.
• The log of 20? No problem. 2 x 10 = .30103 + 1 = 1.30103.
• The log of 40? It is 1.60206.
• And 400? It is 2.60206. Simple, 100 x 4, 2 + .60206.

And so on. Prime numbers divisible only by 1 and themselves require the long process. 3 and 7 require slow calculation. But after that it is easy to calculate the log of 6, 9, 12, 14, 60, 70, 90, and so on. Not that we have to. A thirty dollar calculator or an Excel spreadsheet has them all. But it is valuable to understand things from the ground up.

One learns in this process that the integer portion of a log number always refers to multiples of ten (thus of the base), and the fractional parts to “fractions” of ten. The fractions are obtained by division, obtaining roots, the integers by multiplication.

In this process I also came to understand that logs are a geometrical series; the terms change by the same ratio. In a log base 10, the geometrical progression is represented by 10: 10, 100, 1000, etc. In a log base 2, the progression is by 2: 2, 4, 8, 16. In the first, integer logs will be exact multiples of 10—all other numbers will be or have a fractional component. In a log of base 2, integer logs will be multiples of two. The unchanging ratio is multiplication by the base or division to detect the root of the base.

In arithmetical series, the terms always change by the same amount. In the decimal system that amount is 1 or a fraction of 1. When a geometrical series is used to index an arithmetic series, the advantage is that multiplication and division of the indexed arithmetical series may be replaced by adding or deducting logs. This very much increases the efficiency of manual calculation—which was Napier’s motivation for developing logarithms in a time when mechanical calculators, and never mind lightning speed electronic devices, were still far in the future.

I’ll indulge my fascination with this subject in future posts as well—and perhaps they will help others too.