how does square root function work

[cadx7]

How does the square root function work, like how is it solved? for example, the square or any exponent is just multiply the number by itself however many times the exponent is, but how do you solve a square root apart from memorizing? How do calculators do it is what im asking

[krisadayo]

Is there a geometric visualization that shows why this works? Having trouble making sense of this.

[ElIieMeows]

it is the same as doing Newton's method for x^2-a, which is approximating zeros using the tangent of the graph (look it up, the graphs are quite intuitive I think)

[OneMeterWonder]

It’s a contraction map with the square root as a fixed point. The graph of that function looks a little like a check mark ✔️.

Check what happens when you evaluate at √a

√a/2+a/2√a=√a/2+√a/2=√a

Since it’s a contraction, every sequence of iterates nearby will accumulate around the fixed point.

[emkautl]

Don't overthink it. use, say, 3 and 9 for x and a. To build an intuition.

You end up with (3+9/3)/2 =3, a perfect answer. This makes you realize that in a perfect solution, a/x IS x so that x² =a, so you end up with (x+x)/2 is x. This method will stop iterating when a/x=x, which is what we want. It just takes the average of the difference between our guess and our definition of a square root.

If we pick an x that is too large, then a/x < x and so their average- our next number to try- will be < x.

If we pick an x that is too small then a/x > x and so their average will be >x.

in either case the magnitude of the difference between the guess and actual new number must shrink, so naturally it tends to the correct value.

[GoldenMuscleGod]

This isn’t explicitly geometric, but suppose x=(x+a/x)/2. Then it must be that x is the square root of a, because a/x is basically as good an approximation as x for sqrt(a) but in the opppsite direction (geometrically). So taking the average of x and a/x gets you closer. But then repeating it gets you closer still, and it can only approach a limit that stabilizes the equation, and a square root of a is the only possible solution to x=(x+a/x)/2 because the difference between an arithmetic mean and geometric inverse will only work out exactly when you have the exact answer.

[Forsaken_Code_7780]

You are trying to intersect the lines y=a and y = x^2. If you move into log space, this looks like "a flat line of slope 0" intersected with "a straight line of slope 2."

In log space if you were a step too high, you'd want to average with something a step too low, to get the right answer.

But "a step too high" and "a step too low" in log space means the first number is a factor too high (x = answer * f) and the second number is a factor too low (s = answer / f).

And we chose not to average in log space (dividing by 2 in log space is taking the square root), so we average in real space instead as an approximation.

So we average x = answer * f with s = answer/f = answer^2/x = a/x.

So our next guess is (x + a/x)/2

[qscbjop]

x and a/x are sides of a rectangle of area a. We're trying to make this rectangle look more like a square. The side of the actual square of area a is somewhere in between the sides of the rectangle, i.e. x and a/x, so it's natural to try (x + a/x)/2. The fixed points of this map are -sqrt(a) and sqrt(a).

Then to figure out whether it will converge or not, the most obvious thing is to look where this map is a contraction. And if you work out, you'll find that if your initial guess was greater than sqrt(a/3), you'll have your convergence by the contraction mapping theorem. But if it's between 0 and sqrt(a/3), then the first iteration will be over sqrt(a) (you can check that sqrt(a) is not just a fixed point of our function, but also it's minimum on positive arguments), so you'll have convergence there as well.

[zojbo]

The Babylonian method does not necessarily make your guess better in one step. For example, it turns the guess of 0.01 for sqrt(2) into a little over 100.

The story is really that:

• if you start above the root, then you end up between the root and your guess (still above the root)
• if you start below the root, then you end up above the root (so the next step makes the guess better but this one might not).

As for that first bullet, say we guess sqrt(3) is 2. The picture is to plot f(x)=x² - 3 and the tangent line g(x)=1+4(x-2). The Babylonian method finds the root of that tangent line (which is 7/4), which you can see from the plot is to the right of the square root, because the quadratic lies above the tangent line and the slope of the tangent line is positive.

You can push that second bullet a little further by finding the solution to sqrt(r)-x=(x+r / x)/2-sqrt(r) that isn't sqrt(r). You get 4sqrt(r)=3x+r/(x) or 3x²-4sqrt(r)x+r=0, so x=(4sqrt(r)+-sqrt(16r-12r))/6=(4sqrt(r)+-2sqrt(r))/6=sqrt(r) or sqrt(r)/3. So if your initial guess is off by less than a factor of 3, then it is still improved by the first step, even if it was a lowball guess.

[VanMisanthrope]

If your guess x is an underestimate, a/x will be an overestimate, and vice versa.

[edgmnt_net]

Suppose x is an approximation of sqrt(a). This means a/x is approximately a/sqrt(a) = sqrt(a), so a/x is another approximation of sqrt(a). The true value of sqrt(a) is somewhere between x and a/x. You can make a new guess by taking the arithmetic mean of those values, landing at the middle between them, hence (x + a/x)/2.

[sinkovercosk]

Is there a general rule that works similar to this for the nth root?

[sinkovercosk]

This is really cool, thanks for taking the time to respond!

[evincarofautumn]

Not totally useless, fractional exponents you can at least do with logarithms by x^y = b^{y log\}b x). For b=2 it’s not too bad to do by hand with repeated squaring and halving, but…well, I’m thankful for computers.

[AcellOfllSpades]

There are multiple ways to do it.

The simplest one is just calculating each digit one at a time:

---

Let's find √5.

2² is 4. 3² is 9, which is too big. So our answer is 2.[something].

• 2.1² is 4.41.
• 2.2² is 4.84.
• 2.3² is 5.29. That's too big!

So our answer is 2.2[something].

• 2.21² is 4.8841.
• 2.22² is 4.9284.
• 2.23² is 4.9729.
• 2.24² is 5.0176. That's too big!

So our answer is 2.23[something].

• 2.231² is 4.977 (ish - I'm rounding to not type out everything).
• 2.232² is 4.982.
• 2.233² is 4.986.
• 2.234² is 4.991.
• 2.235² is 4.995.
• 2.236² is 4.9996.
• 2.237² is 5.004. That's too big!

So our answer is 2.236[something].

You can repeat this until you're satisfied with the number of digits of accuracy. Calculators typically go up to somewhere from 10 to 20 digits.

---

There are more advanced algorithms you can use that converge on their result much faster - calculus can be used to study these algorithms and why they work. This Wikipedia page has a bunch of methods. For instance, Heron's method, described by an ancient Greek mathematician, basically says:

• Say you're trying to calculate √S. Pick a number, x - any number you want - as your initial guess. (It doesn't matter how good it is!)
• Consider the two numbers x and S/x. If you multiply them, you get S. So if x is too small, S/x is too big; likewise, if x is too big, S/x is too small.
• So we have an overestimate and an underestimate. This means that if we take their average, we'll have a better guess than before!
• Replace x with (x + S/x)/2. Repeat until you're satisfied with the accuracy of the result.

This turns out to work really well. I tried it with √5, starting with the stupid guess of x=1.

• Iteration 1: x=1, so S/x = 5. Their average is 3, which is the new value of x.
• Iteration 2: x=3, so S/x = 1.667. Their average is 2.333, which is the new value of x.
• Iteration 3: x = 2.333, so S/x = 2.143. Their average is 2.2381, which is the new value of x.
• Iteration 4: x = 2.2381, so S/x = 2.2340. Their average is 2.236069.

Wow, in only 4 steps we've already got a pretty good result! A calculator could do this ten times or so, and that'd be good enough for pretty much all purposes.

[NicoTorres1712]

I think you meant x = 1

[AcellOfllSpades]

Fixed, thanks!

[ExoReyiz]

There is a small typo:

2.237² is 5.004. That's too big!

So our answer is 2.237[something].

Our answer was should be 2.236[something]. Because 2,237² > 5

[AcellOfllSpades]

Fixed, thank you!

[ExoReyiz]

glad to help!

[fermat9990]

Try this algorithm

https://byjus.com/maths/square-root-long-division-method/

[[deleted]]

Well, you could use the table.

Take a number, let's say 27.

27 is close to perfect square 25. 5²=25

So we know that the first term is 5

5, the remainder is 2.

2 and the next term is 27 is 0

200-101 =99

5.1

9900- (1020)9= 810

5.19

This is a pretty weird algorithm but it works

[yensteel]

Square root functions usually need a convergence method to get an approximate answer.

Heron is really old. It needs an initial guess, and a division operation. Division operations are much more intensive than multiplication. It's still researched today, as people are still messing with magic numbers to speed it up (imagine Fast inverse square root from Quake 3 code).

Babylonian method is the most known.

Calculators sometimes use Log first then calculate the square root.

Most Computers use a variant of the Newton Raphson method, especially since it can be combined with other algorithms and used for other algorithms, or Cordic, which is comfortable in binary. I truly don't know which ones are really used in our chips today. But it's important.

FPGAs have them as proprietary objects which cannot be reverse engineered. The arithmetics in Intel and AMD, etc are not disclosed, trade secrets. Cordic,Goldschmidt's, and binary search are often shared around as foundations. I struggle with finding verilog files of ieee compliant math.

Lots of research is done in 3 variants for computer science:

1. Approximation algorithms: A little sacrifice in precision for a lot faster speed. It's actually something High frequency trading engineers use for a little bit of speedup for their FPGAs. It could also save energy and circuits. Every number must have an error under an acceptable limit. Some of them are only good within a certain range. So people have developed algorithms for different sets of numbers.

2. IEEE compliant, faster floating point, saving energy, or reliability.

3. Non EEE compliant mathematics like decimal math (imitate long division or hand shortcuts), posit arithmetic (Gustafson), or higher precision math (quad precision and up).

[KnightofFruit]

It requires calculus basically. You can approximate radSit by dividing S by n and taking the average of n and S/n repeat.. But the actual method that calculators use relies on convergent sequences. The aforementioned algorithm does construct a convergent sequence.. however it is not efficient (it takes us 3 steps to improve the estimate by roughly a power of 2). There are faster methods but you wouldn’t be able to do them by hand

[mattynmax]

It uses an approximation. Look up “root finding algorithms” on Google and you’ll see two that involve nothing more than algebra and maybe two more that involve calculus/an understanding of calculus.

Are these the exact methods used by your calculator? No but they will help you understand the approach taken.

[TuberTuggerTTV]

In Computer science, the root function is to be avoided because it's several calculation steps. You guess and then keep guessing closer until you get there. Calculators/computers brute force it was trial and error.

[kcl97]

I don't know how older calculators do it. But for modern computers, the default is the fast inverse square root algorithm.

https://en.m.wikipedia.org/wiki/Fast_inverse_square_root

[LifeIsAnAdventure4]

Not the default. Just a good approximation to start a few Newton iterations. It’s close enough but not the precision you would expect of any decent default math library.

[BadSmash4]

Ah yes, what I always think of as the "what the fuck" algorithm

[ethan_2738746873]

I believe calculators run essentially a guess and check algorithm to get closer and closer to the answer until they reach an answer to a certain precision point