Approximating Euclidean Distance without Pythagoras?

[McC]

Is there an easy way to approximate a Euclidean distance between two points ([x,y,z] and [x',y',z']) without resorting to exponents and radicals?

The usual way is, obviously, a variation on the familiar two-dimensional Pythagorean theorem, which is √((x'-x)²+(y'-y)²+(z'-z)²). However, suppose you don't have access to a calculator to figure out the value of the radical? Is there a purely algebraic/arithmetic way of calculating an approximate Euclidean distance in this fashion that can be easily distilled to a generic formula?

It need not be exact -- a purely integer solution is perfectly acceptable, for the purposes of what I need this for. It simply needs to be something that someone can do on paper or (ideally) in one's head and arrive at an "almost right" number.

Thanks!

[metavac]

Here you go.

[Kuroneko]

However, suppose you don't have access to a calculator to figure out the value of the radical?

Why not just calculate the radical by hand? It's only slightly harder than long division. Anyone can do it on paper. [Edit: e.g., see here].

Is there a purely algebraic/arithmetic way of calculating an approximate Euclidean distance in this fashion that can be easily distilled to a generic formula? It need not be exact -- a purely integer solution is perfectly acceptable, for the purposes of what I need this for. It simply needs to be something that someone can do on paper or (ideally) in one's head and arrive at an "almost right" number.

If you're trying to caclulate sqrt[t] and t is large, you can simply do this by trial and error. For example, sqrt[280] is more than16.5 but less than 17 (16² = 256, 17² = 289). If you're familiar with the squares of integers, or if you have the time to fiddle with them on paper, it may be good enough for your purposes.

If t is close to 1, going this route just to avoid a square root seems to me more trouble than it is worth, but I suppose you can calculate T = (1-t)/4. If T is small (|T| ≥ 1/4 is non-convergent). Then sqrt[t] = 1/Sum[ C(2n,n) T^n ] = 1/[ 1 + 2T² + 6T³ + ... ], where C(2n,n) is a binomial coefficient (these are the middle terms of the even rows in Pascal's triangle, so they're very easy to calculate on paper). If T is small, you'd need very few terms in the series to give an accurate result.

Also remember than if you have a number too small or too large for you to deal with, you can write it in scientific notation and take out even powers of 10, e.g., the square root of 4875 = 4.875*10^4, so its square root is about 100sqrt(4.9) ~ 100*[2.2] = 220.

--
Edit:

Here you go.

Babylonians did Newton's method? That is awesome.

[metavac]

Edit:

Here you go.

Babylonians did Newton's method? That is awesome.

That's what it was called. Wicked.

[McC]

Here you go.

Yeah, one iteration of this is more or less what I've been using so far, assuming I understand it correctly. That is, if you want to figure out √((4-0)²+(2-0)²+(3-0)²), you do the initial squaring (so 16 + 4 + 9, or 29), then figure out the two closest squares to that. In this case, 5 and 6. Then just take the mean, in this case 5.5 (round to 6). The actual value turns out to be 5.39 or so, so it's within the margin of error (+/-0.75) I'm looking for.

Why not just calculate the radical by hand? It's only slightly harder than long division. Anyone can do it on paper.

Mainly because this isn't intended to be a method for someone with mathematical patience. Were it meant for just me, I'd happily calculate it out to five or six digits. However, the people this method is meant for tend to be mathematically disinclined. As it is, I'm worried about even asking them to evaluate the squares of the interior integers, or to figure out the two closest squares for the simplified Babylonian version I've implemented.

[Kuroneko]

Yeah, one iteration of this is more or less what I've been using so far, assuming I understand it correctly.

No, you've just the initial guess.

That is, if you want to figure out √((4-0)²+(2-0)²+(3-0)²), you do the initial squaring (so 16 + 4 + 9, or 29), then figure out the two closest squares to that. In this case, 5 and 6. Then just take the mean, in this case 5.5 (round to 6).

If you want to do one iteration with the guess 5.5, do [1/2][5.5 + 29/5.5] = 5.386, which is about 0.001 away from the actual root. Using 6 gives 5.417, which has an arror of about 0.03.

[Specialist]

Is there an easy way to approximate a Euclidean distance between two points ([x,y,z] and [x',y',z']) without resorting to exponents and radicals?

The usual way is, obviously, a variation on the familiar two-dimensional Pythagorean theorem, which is √((x'-x)²+(y'-y)²+(z'-z)²). However, suppose you don't have access to a calculator to figure out the value of the radical? Is there a purely algebraic/arithmetic way of calculating an approximate Euclidean distance in this fashion that can be easily distilled to a generic formula?

It need not be exact -- a purely integer solution is perfectly acceptable, for the purposes of what I need this for. It simply needs to be something that someone can do on paper or (ideally) in one's head and arrive at an "almost right" number.

Thanks!

If you're just comparing distances you don't need to do the squre root.

[Surlethe]

Mainly because this isn't intended to be a method for someone with mathematical patience. Were it meant for just me, I'd happily calculate it out to five or six digits. However, the people this method is meant for tend to be mathematically disinclined. As it is, I'm worried about even asking them to evaluate the squares of the interior integers, or to figure out the two closest squares for the simplified Babylonian version I've implemented.

Are these people children? Also, is it possible for you to write a program for this, since the method is algorithmic and iterative, or is that out of the question?

[McC]

Are these people children? Also, is it possible for you to write a program for this, since the method is algorithmic and iterative, or is that out of the question?

Role-players, and out-of-the-question. I need a fast method that can be done in the head of pretty much anyone, including people who "hate math." It's meant for live play, so just coming up with a program won't work.

[Surlethe]

Are these people children? Also, is it possible for you to write a program for this, since the method is algorithmic and iterative, or is that out of the question?

Role-players, and out-of-the-question. I need a fast method that can be done in the head of pretty much anyone, including people who "hate math." It's meant for live play, so just coming up with a program won't work.

Ahh, I see. Even "I hate math" people should be able to square two- and three-digit integers.

Here's a thought: would a table of squares help? That way, instead of working it out in your head or on a piece of paper, you could simply consult the sheet, add them together, and then consult the sheet again for an "in between these two integers" guess.

[McC]

Ahh, I see. Even "I hate math" people should be able to square two- and three-digit integers.

I wouldn't task such people with squaring anything bigger than, say, 13.

Here's a thought: would a table of squares help? That way, instead of working it out in your head or on a piece of paper, you could simply consult the sheet, add them together, and then consult the sheet again for an "in between these two integers" guess.

I may resort to this, yeah.

[Surlethe]

Ahh, I see. Even "I hate math" people should be able to square two- and three-digit integers.

I wouldn't task such people with squaring anything bigger than, say, 13.

I'm not quite sure what to say to this, other than note that elementary students can square numbers as big as c.

Here's a thought: would a table of squares help? That way, instead of working it out in your head or on a piece of paper, you could simply consult the sheet, add them together, and then consult the sheet again for an "in between these two integers" guess.

I may resort to this, yeah.

Even easier: if you're working in two dimensions, it's not difficult to make a table that gives you the distances directly, like this.

[Kuroneko]

And of course, you can reuse the same two-dimensional table for three dimensions by first calculating the distance d in the xy plane without the z component and then the distance between (0,z1) and (d,z2).

A role-playing friend of mine has a large sheet with a hexagonal tiling under a glass that he uses to keep track of positions and estimate distances.

[Feil]

What about a string and a ruler? Or am I misunderstanding the objective, here?

[Surlethe]

What about a string and a ruler? Or am I misunderstanding the objective, here?

Where's the fun in that?

Actually, I'd assumed that roleplaying doesn't use an actual board. Is that not the case? I've never done it, myself.

[Uraniun235]

Roleplaying games often involve combat, and some players like to use boards to plot out and keep track of where players and opponents and obstacles are during combat.

What about a string and a ruler?

Tape measure would be much quicker, I'd think.

[Ariphaos]

Where's the fun in that?

Actually, I'd assumed that roleplaying doesn't use an actual board. Is that not the case? I've never done it, myself.

Some people use miniatures and don't bother with abstracting combat. D&D is big on this now as WotC wants in on the Minis market (and coming full circle from Chainmail...).

Still, the best idea IMO is still the marked string - just mark inches on a string and go.