Taking square roots by hand

[absael]

I don't remember now why, but I wanted to take a square root in my head this morning. The first digit and a guess at the second were easy, but after that I found myself relying on a very hazy recollection of some convoluted method that seemed rather counter-intuitive, at least in contrast to the method that I had just used to obtain the first 2 digits. I saw no reason why the method that I had used couldn't be extended to obtain as many digits as desired, yet I couldn't find any reference to it.

Let's say that we want to find the square root of 62. A quick check shows that 7 is too small and 8 is too big, so we write down 7. Now (and this is the “intuitive” part that led me to this solution), we can see that 62 is pretty close to 64, the square of the next number after 7. In fact, it's a lot closer to the square of 8 than it is to the square of 7, so I guessed that the next digit was 8 (in other words, it appeared to me that 62 was about 80% of the way between 49 and 64).

Of course, in order to calculate the next digit, we'll have to do better than guess. We subtract 49 (the current square) from 62 (the target) and obtain 13. Subtracting 49 from 64 (the next square), we obtain 15. So 62 is 13/15 of the way from 49 to 64. 13 divided by 15 is 0.86, so the next number is indeed 8 (9 would be too big).

Okay, so now we need to see what percentage of the distance between 7.8 and 7.9 the next digit should be. We square 7.8 and obtain 60.84. We are 1.16 away from our target of 62. Squaring 7.9 gives 62.41. 62.41 minus 60.84 is 1.57. 1.16 divided by 1.57 is 0.73, so the next digit is 7.

We'll do one more. 7.87 squared is 61.93. Our difference between the square and the target is now 0.07. 7.88 squared is 62.09. The difference between the current square and the next square is 0.16. To see what distance the next digit covers between 7.87 and 7.88, we divide 0.07 by 0.16 and obtain 0.43. The next digit is 4.

7.874 squared is 61.999876. We're really close now, so it looks like the next digit will be a zero. In fact, the next 2 digits are zeros.

I suppose it comes down to personal preference, but this method just makes more sense to me than any other I've seen. Have any of you been taught this method, or heard of it being taught? And do you find, as I do, that this is at least as easy as any other method?

[baric]

My math teacher in 8th grade taught me to do it in a long division format, and I've remembered it ever since.

For example, rooting 62 would look like this:

  _________
\/62.0000    |   7
  49.        |   7
 -----------------
  13 00         148
  11 84           8
-------------------
   1 1600       1567
   1 0969          7
--------------------
      63100     15744
      62976         4
---------------------
        12400   15748

You basically have to do one multiplication for each digit of precision you need.

[tdvance]

I used to be able to do that, was taught by my grandfather in elementary school, then retaught in high school, but lack of practice meant I forgot it.

It might be easier (certainly easier to remember, and easier to code definitely) to do "divide and average", or "cut and try":


62: make a guess, say 7

62/7 is 8.857142 (you DO know how to compute decimals for ratios with 7 on the bottom?--strangely, I remembered THAT one).

The average of 7 and 8.57142 (actually, don't need THAT many digits, yet.) is about 7.7 or so.

divide and average again:
62/7.7 is almost exactly 8. avg. betw 7.7 and 8 is about 7.9

and so on.

If you had a calculator with no square root button, this method is pretty fast.

It's also fast to code--and converges really fast too, even if you need a lot of decimal places.

In this case, you need approximately one division for every digit of precision (if you use a calculator or do it accurately on paper instead of estimating in the head like I was doing).

Of course, having a log table makes it faster. Feynman's lectures volume one has a procedure for computing entries for log tables, in case you're stuck in the desert and need to make a log table.

[kleindoofy]

Does anybody here know how it's coded in calculators?

I'm guessing they use a very basic (no pun intended) language, probably the same one they used about 40 years ago, some simple subset of proto-assembler.

[baric]

If you had a calculator with no square root button, this method is pretty fast.

ha! Using a calculator is cheating, and doesn't qualify as 'by hand'. Besides, it's a lot easier nowadays to find a piece a paper than a calculator with no square root button!

Does anybody here know how it's coded in calculators?

I'm guessing they use a very basic (no pun intended) language, probably the same one they used about 40 years ago, some simple subset of proto-assembler.

The manual method I provided would be pretty easy to implement. It would only require iterative subtraction and digit shifting.

[pzkpfw]

I used to be able to do that, was taught by my grandfather in elementary school, then retaught in high school, but lack of practice meant I forgot it.

It might be easier (certainly easier to remember, and easier to code definitely) to do "divide and average", or "cut and try":

That looks like the Newton-Raphson method (if I remember College (High School) maths...)

Edit to add:

Oops, similar, but not the same, I think.

http://en.wikipedia.org/wiki/Newton's_method

[mike alexander]

OMG. I learned the paper/hand method in high school, and it has completely left my mind.

Totally depressing.

[HenrikOlsen]

Does anybody here know how it's coded in calculators?

I'm guessing they use a very basic (no pun intended) language, probably the same one they used about 40 years ago, some simple subset of proto-assembler.

In binary that long division-like algorithm turns out to be really simple to code.

[Glom]

Binomial expansion, which is in itself the Taylor expansion for a simple index function... and I've forgotten that too.

[Tobin Dax]

Binomial expansion, which is in itself the Taylor expansion for a simple index function... and I've forgotten that too.

I've always had to look up the Taylor expansion from the third term on.

[01101001]

Just feeling frisky, and not wanting to use my cell phone's calculator, I texted square root 62 to 466453 (GOOGLE).

Miraculously, a message came back to me:

Calculator: square root(62) = 7.87400787

[hhEb09'1]

Have any of you been taught this method, or heard of it being taught? And do you find, as I do, that this is at least as easy as any other method?

I'm familiar with the method baric described, as well as tdvance's, and I'd have to say yours would definitely come in third.

That looks like the Newton-Raphson method (if I remember College (High School) maths...)

Edit to add:

Oops, similar, but not the same, I think.

http://en.wikipedia.org/wiki/Newton's_method

No, it's essentially the same.

Newton's formula is x₁ = x₀ - f(x₀)/f'(x₀)
but the function f(x) in this case is f(x) = x² - N so
x₁ = x₀ - (x₀² - N)/(2x₀)
or
x₁ = (x₀ + N/x₀)/2

Which is tdvance's method.

[jokergirl]

I have been taught a method by my humanist maths teacher. But I can't say I remember a shred of it.

[mike alexander]

I have been taught a method by my humanist maths teacher. But I can't say I remember a shred of it.

I'm more fascinated by the idea of humanist mathematics.

Naw, we are so not going there...

[jokergirl]

I don't have a problem with seeing mathematics as a humanist science. I don't see why humanists disagree, though.

[mahesh]

....
Miraculously, a message came back to me:
Calculator: square root(62) = 7.87400787

That number is so beautiful.
Any body else see the beauty, in the way some numbers fall together? Presumably innumerable BAUTzens

I love division by seven. The results are so beautifully cyclical.

[baric]

That number is so beautiful.
Any body else the beauty, in the way some numbers fall together?

I love division by seven. The results are so beautifully cyclical.

You should see division by 13.

1/13 = .076923
3/13 = .230769
4/13 = .307692
9/13 = .692307
10/13=.769230
12/13=.923076


2/13 = .153846
5/13 = .384615
6/13 = .461538
7/13 = .538461
8/13 = .615384
11/13=.846153


There are two different 6-digit rotations, with the triplets swapped for numerators n and 13-n.

[trinitree88]

The Taylor expansion has to have a truncation indexed so the silly thing doesn't spend the day on sig figs unprintable or displayable. I make the kids do a series of better approximations when they forget their sci. calcs. and have to use a simple four function calculator on a quiz.....aggravating but do-able. Helps their memories a lot. pete

[hhEb09'1]

That number is so beautiful.
Any body else see the beauty, in the way some numbers fall together? Presumably innumerable BAUTzens

I love division by seven. The results are so beautifully cyclical.

Since it's irrational, it stops repeating: 7.874007874011811019685034448812

You should see division by 13.

My favorite is 1/89, it equals the sum
.0 +
.01 +
.001 +
.0002 +
.00003 +
.000005 +
.0000008 +
.00000013 +
.000000021 +
.0000000034 +
.00000000055 +
....
The nth Fibonacci number times 10^-(n+1)

[jfribrg]

The old fashioned pencil-and-paper method relies on the fact that (a+b)^2 = a^2 + 2ab + b^2, along with the knowledge that a is a multiple of a power of 10. In the case of sqrt(625) for instance a = 20 and b = 5. The "intuitive" first step is simply finding the value of a. The "non-intuitive" second step involves figuring out what value of b causes a + b to be as close to a perfect square as possible. For larger numbers and decimal answers, the above process is repeated on the remainder.

I always thought that computers calculated the square root by using logarithms. sqrt(x) = 2^(0.5lg(x)), where lg is the base 2 logarithm. Theoretically, these are rather slow calculations, but logarithms base 2 are reasonably efficient on a binary computer, especially in the range that people typically use.

[Celestial Mechanic]

[Snip!]

My favorite is 1/89, it equals the sum
.0 +
.01 +
.001 +
.0002 +
.00003 +
.000005 +
.0000008 +
.00000013 +
.000000021 +
.0000000034 +
.00000000055 +
....
The nth Fibonacci number times 10^-(n+1)

Wow, I didn't know that! I've got to see if I can prove it. (Don't tell me!)

Edited to add: Proved it.

[mahesh]

Ah, Fibonacci! Lovely Fibonacci!

[mahesh]

You should see division by 13....
There are two different 6-digit rotations, with the triplets swapped for numerators n and 13-n.

Oh, the moons of Jupiter! Beautiful rotation!

thanks.

[DonM435]

I'm more fascinated by the idea of humanist mathematics.

Naw, we are so not going there...

Interesting. My high school history teacher told us that George Washington's birthday -- 1732 -- was similar to the square root of three -- 1.732. Mixed metaphors, but I never forgot either fact. It helped me in History classes where I could relate dates to Presidential terms. It helped me on a Math final where we had to derive said root. I had to show the work, but it helped knowing exactly what to expect as the answer.

I will always be grateful to Father Fitzgerald for that. (I didn't like him much otherwise.)

[baric]

Oh, the moons of Jupiter! Beautiful rotation!

thanks.

I knew you would like it, since you liked n/7.

I was a baseball geek in my youth, so I learned a lot of the smaller fractions through osmosis from constantly calculating things like batting averages. 4-for-13 = .308 hitter.. not too shabby, but 3-for-13 = .231... he'll be riding the bench!

[absael]

My math teacher in 8th grade taught me to do it in a long division format, and I've remembered it ever since.

For example, rooting 62 would look like this:

  _________
\/62.0000    |   7
  49.        |   7
 -----------------
  13 00         148
  11 84           8
-------------------
   1 1600       1567
   1 0969          7
--------------------
      63100     15744
      62976         4
---------------------
        12400   15748

You basically have to do one multiplication for each digit of precision you need.

I've used this method before, but it takes me more than one multiplication for each digit. First I multiply the current root by 2, then divide into the difference (after adding the requisite number of zeros), then multiply again by the integer of the quotient after adding it to the divisor. Also, sometimes the quotient obtained in the second step is incorrect, requiring another multiplication.

[tdvance]

That looks like the Newton-Raphson method (if I remember College (High School) maths...)

Edit to add:

Oops, similar, but not the same, I think.

http://en.wikipedia.org/wiki/Newton's_method

They might be equivalent, actually. Newton's method has the advantage that you can easily extend it to cube roots, and on up.

[tdvance]

Theoretically, these are rather slow calculations, but logarithms base 2 are reasonably efficient on a binary computer, especially in the range that people typically use.

If all you want is the integer part of the result, some cpus do it in one instruction (a few nanoseconds on modern cpus--though I'm not sure Pentium provides the instruction--it probably has to have code that does it). Actually, for fixed point (binary), it's the same. Only when you insist on floating point would it take 10 or so nanoseconds (if the CPU supports it rather than requiring "software"), a very long time for electrons to wait! (equitvalent to a photon traveling about 10 feet).

[tdvance]

Interesting. My high school history teacher told us that George Washington's birthday -- 1732 -- was similar to the square root of three -- 1.732. Mixed metaphors, but I never forgot either fact. It helped me in History classes where I could relate dates to Presidential terms. It helped me on a Math final where we had to derive said root. I had to show the work, but it helped knowing exactly what to expect as the answer.

I will always be grateful to Father Fitzgerald for that. (I didn't like him much otherwise.)

that's a good one. My math teacher used Andrew Jackson's presidency to remember part of the expansion of e: 2.7 1828 1828

[baric]

I've used this method before, but it takes me more than one multiplication for each digit. First I multiply the current root by 2, then divide into the difference (after adding the requisite number of zeros), then multiply again by the integer of the quotient after adding it to the divisor. Also, sometimes the quotient obtained in the second step is incorrect, requiring another multiplication.

I don't see it that way...

Not counting the trivial additions and subtractions, I had to do this mentally:

Highest square less than 62: 7, automatically

How many times does 14+ go into 130? 8x14 = 112...

How many times does 15+ go into 116? 7x15 = 105.. another straightforward estimate.

How many times does 15+ go into 63? 4

The next one is 157 into 12, so the next digit is clearly 0

Then it is 157 into 120, so 0 again

Then it will be 15+ into 120, so it will be 7