I use distance squared checks for basically all my distance (vector3 length) checking, due to the performance increase from not incurring a square root (like in plain length checks).

From the looks of it, squared distance checks work fine in every situation:

`if x^2 < y^2, then x < y, even when 0 < (x or y) < 1`

I am not considering situations where x or y is less than 0, as distance and distance-squared is always going to be positive.

Since this works, it looks like distance checks are never ever needed, but I have a nagging feeling that i'm missing something. Will this still hold up in accuracy-critical situations?

There's no disadvantage I'm aware of when using squared length to compare distances. Think about it like that: You're just skipping the `sqrt`

which doesn't give you any additional accuracy. If you don't need the actual Euclidean distance, then you can safely leave the `sqrt`

out.

Of course the squared length scales quite differently than the Euclidean distance and is therefore a bad candidate for things like pathfinding heuristics.

February 11, 2012 10:51 AM

The only disadvantage I can think of is when dealing with large numbers which will overflow when squared.

For example, in Java:

```
int x = Integer.MAX_VALUE / 1000000; //2147
int y = Integer.MAX_VALUE / 5000; //429496
System.out.println("x < y: " + (x < y)); //true
System.out.println("x*x: " + (x * x)); //4609609
System.out.println("y*y: " + (y * y)); //-216779712 - overflows!
System.out.println("x*x < y*y: " + (x * x < y * y)); //false - incorrect result due to overflow!
```

Also worth noting that is what happens when you use Math.pow() with the exact same numbers and cast back to int from the double returned from `Math.pow()`

:

```
System.out.println("x^2: " + (int) (Math.pow(x, 2))); //4609609
System.out.println("y^2: " + (int) (Math.pow(y, 2))); //2147483647 - double to int conversion clamps to Integer.MAX_VALUE
System.out.println("x^2 < y^2: " + ((int) (Math.pow(x, 2)) < (int) (Math.pow(y, 2)))); //true - but for the wrong reason!
```

Is it working? *No*, it only gave the correct answer because `y*y`

is clamped to `Integer.MAX_VALUE`

, and `x*x`

is less than `Integer.MAX_VALUE`

. If `x*x`

was also clamped to `Integer.MAX_VALUE`

then you would get an incorrect answer.

Similar principles also apply with floats & doubles (except they obviously have a greater range before they overflow) and any other language which silently allows overflows.

February 17, 2012 03:08 AM

As bummzack hinted with the Path-finding analogy, you NEED to use the "normal" length every time you add distances together and want to compare their sum. (Just because summs of squares of lengths are different from squared summs of lengths).

x^2 + y^2 != (x+y)^2

February 17, 2012 18:31 PM

One time I was working in square distances, and made the mistake of *accumulating* squared distances, for an odometer count.

Of course, you can't do this, because mathematically,

```
(a^2+b^2+c^2+d^2)!=(a+b+c+d)^2
```

So, I ended up with an incorrect result there. Oops!

March 11, 2013 20:36 PM

You may run into trouble if you're writing an algorithm which requires that you compute an optimized position. For example, let's say you had a set of objects, and you were trying to compute the position with the smallest total distance from all of the objects. Just for a concrete example, say we're trying to power three buildings, and we want to figure out where the power plant should go so that we can connect it to all the buildings using the smallest total length of wire. Using the distance squared metric, you would end up with the x-coordinate of the power plant being the average of the x-coordinates of all the buildings (and analogously for the y-coordinate). Using the ordinary distance metric, the solution would be different, and often very far off from the distance squared solution.

August 03, 2014 19:38 PM

Using distance squared is almost always just fine and good for performance. The following considerations are important:

If you want to think about the sum of a number of distances, distance squared will be inaccurate. For instance, I have two distances and I want to make sure their sum is less than 10. The following code is incorrect:

```
a = get_distance_squared(c,d);
b = get_distance_squared(e,f);
assert(a+b < 10^2);
```

It fails to assert in the following invalid case: `a=36`

and `b=49`

. In this case, the first length is 6 and the second 7; their sum is greater than 10, but the sum of the squares is not 100 or greater.

Another consideration: for real-valued distances, distance squared will always be positive. If you're measuring displacement for instance, you may need to deal with negative values, and squaring them will not do.

October 11, 2018 13:52 PM

- Serverfault Help
- Superuser Help
- Ubuntu Help
- Webapps Help
- Webmasters Help
- Programmers Help
- Dba Help
- Drupal Help
- Wordpress Help
- Magento Help
- Joomla Help
- Android Help
- Apple Help
- Game Help
- Gaming Help
- Blender Help
- Ux Help
- Cooking Help
- Photo Help
- Stats Help
- Math Help
- Diy Help
- Gis Help
- Tex Help
- Meta Help
- Electronics Help
- Stackoverflow Help
- Bitcoin Help
- Ethereum Help