Commit: r1050: Improve performance of distance calculations.
Version 1050 was commited by markb on 2009-05-30 10:04:26 +0100 (Sat, 30 May 2009) Improve performance of distance calculations. Moved distance() from MultiPolygonRelation class into Coord class to form the basis of quickDistance(). Original distance() now renamed to slowDistance() and distance() now calls quickDistance(). Added distanceInDegreesSquared() - this can be used for those situations where absolute distance is not required, i.e. for determining a nearest point out of a set of points. Reworked Utils.toDegrees() and Utils.toRadians() to reduce number of divisions at runtime.
May I propose to rename the function slowDistance() to exactDistance()? I think the main reason for this function is not to be slow, but to be the exact calculation. Regards, Johann
Original distance() now renamed to slowDistance() and distance() now calls quickDistance().
Hi Johann,
May I propose to rename the function slowDistance() to exactDistance()? I think the main reason for this function is not to be slow, but to be the exact calculation.
It doesn't want to be slow but it just is because acos() is a complete dog. But how do you know it's exact anyway? Have you tested it in any way? Also, while you are at it, why not propose that quickDistance() is renamed notQuiteSoExactDistanceButProbablyGoodEnoughThatNoOneWillNotice()? And anyway, even if quickDistance() does not produce as accurate a result as slowDistance(), as long as the result is good enough for the calculation being performed we're better off with the speed increase. I am happy with the names as they are. Cheers, Mark
Hi Mark, i didn't want to upset you. Its your code, well code btw., and you can name the functions as you like. But from the sight of a progrommer not so deep in the internals of mkgmap, it seems to me clearer to choose from the functions quickDistance() and exactDistance().
May I propose to rename the function slowDistance() to exactDistance()? I think the main reason for this function is not to be slow, but to be the exact calculation.
It doesn't want to be slow but it just is because acos() is a complete dog.
But how do you know it's exact anyway? Have you tested it in any way?
No, but I know that the calculation formula is another one and is more expensive, but should deliver the correct distance.
Also, while you are at it, why not propose that quickDistance() is renamed notQuiteSoExactDistanceButProbablyGoodEnoughThatNoOneWillNotice()?
And anyway, even if quickDistance() does not produce as accurate a result as slowDistance(), as long as the result is good enough for the calculation being performed we're better off with the speed increase.
Yes, I know that and fully agree to that.
I am happy with the names as they are.
Then dont change it. It was only a suggestion. Regards, Johann
Hi Johann,
i didn't want to upset you.
Actually, you didn't - I was just cruelly making fun at your expense. Sorry, I can't help it sometimes. I really don't care much what the functions are called, especially as slowDistance() is no longer used anyway (apart from the check in quickDistance() which is inactive unless compiled in.) What is more important than the names is how they perform in terms of accuracy and speed. Given that both functions are approximations anyway (for example, neither take into account the height of the ground at the coordinates so the answers will be "wrong" unless the ground is level), we surely only need to use a function that is sufficiently accurate such that the map quality doesn't suffer such that anyone would notice. Cheers, Mark
participants (3)
-
Johann Gail -
Mark Burton -
svn commit