skanade
asked on
Math question -- point to point distance
Given the x,y of the starting and ending points, I want to calculate the distance travelled. I will appreciate a hint on how to do it with a simple code example.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
The Pythagorean theorem!
distance=sqrt(pwr((x2-x1),
sqrt is the square root and pwr is the power.
Actually, it is probably best not to use qwr() for this, since expoential algorithms tend to take 100s of times longer than multiplies.
jep. and they tend to be less accurate than a multiplication by two. this normally doesn't make a difference, but in extreme cases it can be the drop of water that causes a divide by zero..
Nils
Nils
Prove the Pythagorean algorithm.
Interested in mine?
Interested in mine?
ASKER
Thanks!
Okay, got this from a website, but can't remember the addy. anyways:
This small operation calcuates the distance between two points. The routine can work in any number of dimensions, so you cold apply it to 2D or 3D.
In 2D
Define your two points. Point 1 at (x1, y1) and Point 2 at (x2, y2).
xd = x2-x1
yd = y2-y1
Distance = SquareRoot(xd*xd + yd*yd)
In 3D
Define your two points. Point 1 at (x1, y1, z1) and Point 2 at (x2, y2, z2).
xd = x2-x1
yd = y2-y1
zd = z2-z1
Distance = SquareRoot(xd*xd + yd*yd + zd*zd)
As you can see, this requires that you perform a square root. Square roots should be avoided like the plague if you want to write fast code. Only perform a Square Root if you really need to.
Ways to avoid Square Roots:
If you don't need a very accurate distance, you can use a lookup table to calculate it.
If, for example, you are performing collision detection between spheres, and all you want to know is whether or not two have collided, then you do not need to use a square root. Simply change the piece of code from:
if SquareRoot(xd*xd + yd*yd) < Diameter
to:
if (xd*xd + yd*yd) < (Diameter*Diameter)
This small operation calcuates the distance between two points. The routine can work in any number of dimensions, so you cold apply it to 2D or 3D.
In 2D
Define your two points. Point 1 at (x1, y1) and Point 2 at (x2, y2).
xd = x2-x1
yd = y2-y1
Distance = SquareRoot(xd*xd + yd*yd)
In 3D
Define your two points. Point 1 at (x1, y1, z1) and Point 2 at (x2, y2, z2).
xd = x2-x1
yd = y2-y1
zd = z2-z1
Distance = SquareRoot(xd*xd + yd*yd + zd*zd)
As you can see, this requires that you perform a square root. Square roots should be avoided like the plague if you want to write fast code. Only perform a Square Root if you really need to.
Ways to avoid Square Roots:
If you don't need a very accurate distance, you can use a lookup table to calculate it.
If, for example, you are performing collision detection between spheres, and all you want to know is whether or not two have collided, then you do not need to use a square root. Simply change the piece of code from:
if SquareRoot(xd*xd + yd*yd) < Diameter
to:
if (xd*xd + yd*yd) < (Diameter*Diameter)
>> square roots should be avoided like the
>> plague if you want to write fast code
Obviously you want to avoid any code when there is a faster alternative that is as easy and as relaible, but I don't think that is the case here. Square roots are bad, but not that bad. On a pentium 1, they take 70 clock cycles, to so you con do still do millions of them a second (assuming you aren't using the CPU for anything else :-) ). So I would not go to great lengths to avoid them. The code for the circle is a good example, the lengths you go to is not that far and it saves most of the 70 clock cycles. but using a look-up table is too much work, probably won't save much (if any) time and won't be accurate. Now if you are dealign with heavily optimized integer code that must do enormous numbers of squareoots, like you might find in a graphics algorithm, it might make sense to do a look-up, but that is not going to be a typcial case and you are probalby goign to loose any advantage you might gain if you don't write the code in assembly.
>> plague if you want to write fast code
Obviously you want to avoid any code when there is a faster alternative that is as easy and as relaible, but I don't think that is the case here. Square roots are bad, but not that bad. On a pentium 1, they take 70 clock cycles, to so you con do still do millions of them a second (assuming you aren't using the CPU for anything else :-) ). So I would not go to great lengths to avoid them. The code for the circle is a good example, the lengths you go to is not that far and it saves most of the 70 clock cycles. but using a look-up table is too much work, probably won't save much (if any) time and won't be accurate. Now if you are dealign with heavily optimized integer code that must do enormous numbers of squareoots, like you might find in a graphics algorithm, it might make sense to do a look-up, but that is not going to be a typcial case and you are probalby goign to loose any advantage you might gain if you don't write the code in assembly.
Talking about slow/fast.
Why using C++ then??? Just write it in assembly. Nowadays you should not be worried about slow code. Only optimize it when really necesarry.
Why using C++ then??? Just write it in assembly. Nowadays you should not be worried about slow code. Only optimize it when really necesarry.
>> Why using C++ then???
Its a very good language with too many benefits to mention. Why are you suggesting we shouldn't?
>> Nowadays you should not be
>> worried about slow code
Yes, then there is good chance that is what you'll get.
>> Only optimize it when really necesarry.
That was my point. A single squareroot is not worth optimizing. Even a hundred isn't worth it. But when you have thousands, as might in some situations, it might be worth it. Graphics algorithms often do so. They also tend to optimize trig funnctions which are even worse than squareroots.
Its a very good language with too many benefits to mention. Why are you suggesting we shouldn't?
>> Nowadays you should not be
>> worried about slow code
Yes, then there is good chance that is what you'll get.
>> Only optimize it when really necesarry.
That was my point. A single squareroot is not worth optimizing. Even a hundred isn't worth it. But when you have thousands, as might in some situations, it might be worth it. Graphics algorithms often do so. They also tend to optimize trig funnctions which are even worse than squareroots.
It was just a joke about C++. Using C++ makes your code dramatically slower, instead of using C or assembly. So why then bother about a few clock-cycles in comparison to the clock-cycles C++ uses for all its internal checking.
You are right about Graphics, but to optimize often depends on your context. And is proven lots of times that it is not always best to optimize the code you expect in the first place. And in the end you discover you should focus on code totally at unexpected places.
You are right about Graphics, but to optimize often depends on your context. And is proven lots of times that it is not always best to optimize the code you expect in the first place. And in the end you discover you should focus on code totally at unexpected places.