Vector2.Distance is just wrong. Or inacurrate.

Hi.
I want to determine some further behaviour in my code by checking if two vectors are exactly .5 units apart.
All Vectors are positioned in a grid so that wont be a problem.
Now at the point where i check for the distance it just gets all wrong(mathematicaly)… or is there a reason for that that i dont know?

if(Vector2.Distance(vertexA,vertexB) == .5f)
                isinvisible = false;

So lets give it those two points:
Pa(-2,11,5); Pb(-1.5,12)

According to simple math:
SqrRoot((xa-xb)²+(ya-yb)²)
(-2–1.5)² + (11.5-12)²
SqrRoot(-0.5² + -0.5²)
SqrRoot(0.5) = 0.5 WRONG

And there is the problem. If I do the math myself i get .7[…]. Vector2.Distance returns .5f. Why?

I just made a simple script checking on Mathf.Sqrt() and Vector2.Distance() with the values you provided (Pa and Pb). The results are correct - something like 0.707. Literally everybody is using these calls every day hundreds of times - they work.
Step through your code and see the input values. I suppose something is going wrong with what you hand over to your function. Check if vertexA and vertexB really hold the values you are expecting and no float / int conversion whatsoever is getting in your way. It’s happening somewhere else than .Distance()

1 Like

“Literally everybody is using these calls every day hundreds of times - they work.”
Yep and thats why I was so confused. I found my mistake 200 Lines up in my code. I am using Vector2.Distance on a Vector3… and the y is always 0. Thank you anyways

I don’t know if you’ve run into this problem yet, but equality testing with floats is risky. Floating point numbers always have a small margin of error, so instead of testing equality, you should test if the difference between the numbers is less than float.Epsilon. Cool IDEs will warn you of this.

1 Like

I was just gonna say that.
also remember to absolute the result before comparing.
http://0.30000000000000004.com/

1 Like

“All Vectors are positioned in a grid so that wont be a problem.”
I set those vectors in a grid multiplied by integers. I dont think that this will cause any floating point problems right? I will never alter the position of those vectors by more then .5 and wont get far enough of the origin to lose enough decimals points.
So this wont ever be a problem right?

Setting them in a grid still doesn’t matter.

Floating point error is not about large values. It’s about significant values and binary->decimal conversion.

For example the decimal value 0.1 in binary is 0.00011001100110011… repeating into infinity (just like how 1/3 is 0.333… in decimal). But since a float only has a finite number of sig value you must drop the end of the values so you end up with a value equal to just shy of 0.1… about 0.09999997.

And 0.1 isn’t the only value that does this. There’s a lot of them. So float error for EXACT equality is a huge issue.

Furthermore you’re using a sqrt. The way computers perform a sqrt also introduces error. First and foremost the way sqrt is calculated is platform dependent (most modern cpu’s have a hardware implementation, but each hardware is different). Otherwise it falls back on a software implementation that is usually OS specific. All of these algorithms can be distinct from one another in one way or the other, but usually are some sort of recursing operation that finds closer and closer estimates of the root and returns that.

This means that unless your root is a perfect square, you’re probably not going to get back a perfectly accurate result. Especially not irrational values like sqrt(2) (note that sqrt(0.5) = sqrt(2)/2 = ~0.7071… and is therefore irrational)

1 Like

I see. Thank you for your very detailed explanation.
I dropped the root and used sqrmagnitude instead. Additionally I added a threshold of .1.