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.

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.”

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.

Iteration	Result of Equation	Result x Result
1	1.7825	3.1773062500
2	1.7692303647	3.1301760832
3	1.7691806020	3.1300000025
4	1.7691806013	3.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.