Thread: Mapping Math
View Single Post
Old 04-20-2006, 04:38 AM   #4
Vuen
User
 
Join Date: Mar 2003
Posts: 279

Submissions (5)

Vuen will become famous soon enough (64)Vuen will become famous soon enough (64)Vuen will become famous soon enough (64)

Spell making session 4 winner

Default

Quote:
Originally Posted by Blackroot
Wow! I didint realize using the traditional polar projection was so leaky. I didint even realize how off reals were in small quantities. +Rep

Polar projection is not actually leaky. At least, that's not the problem here. At worst it only leaks two location references (not the objects themselves) per call:

Collapse JASS:
function PolarProjectionBJ takes location source, real dist, real angle returns location
    local real x = GetLocationX(source) + dist * Cos(angle * bj_DEGTORAD)
    local real y = GetLocationY(source) + dist * Sin(angle * bj_DEGTORAD)
    return Location(x, y)
endfunction

By "leaky abstraction" he meant that the function is deceptively simple; you don't realize that it takes a ton of computing power to do. People use it in loops and periodic functions without realizing it and it slows their computer to a halt.



Also, reals are not at all off in small quantities. Warcraft can hold extremely small numbers, like 4.26547 x 10^-35 with extremely high precision (less than a millionth of a percent error, regardless of how small your number is).

The problem comes with when you're trying to look at the far decimal places on big numbers. Take a number like 0.236218. A float can hold that just fine. Now watch what happens when you add a million to it and subtract it again:

0.236218 + 1000000 = 1000000.236218

Warcraft can't hold 13 decimal places so it rounds it, which ends up being something like 1000000.2. Subtract a million again:

1000000.2 - 1000000 = 0.2

This simple calculation should in theory give us our number back, 0.236218, but because of rounding error the answer was 0.2, which is off by 15%. This is not because the number is small, but because a million is so large that it makes 0.036218 insignificant.

The moral here is to be very careful when subtracting numbers from eachother. If they are very close together, your result will get rounded. Often, if the numbers are close enough together, the rounding will simply leave zero, which can cause divide-by-zero or can simply make nothing happen at all. Very frustrating bugs to track down without this knowledge.
Vuen is offline   Reply With Quote