I've recently read that in programming you can't use the "==" operator for comparing real numbers (dunno why). Well, you can technically, but this may result in bugs. So, the question: does this apply to triggers?
A computer cannot handle and never will be able to handle real numbers. Instead it uses machine numbers, in case of sc2 these are 20.12 fixed point numbers. This means 20 bit are used for describing the integer part (2^20 = approx 1 million = largest and smallest integer) and 12 bits are used to describe the fractional part (2^12 = 4096, i.e. the best precision you can archieve in the fractional part is 1/4096 = approx 0.0002). The latter is the reason why "==" comparision is avoided for machine numbers. The machine cannot handle the ultimate precision in mathematics but needs to round in between! This means if you do multiple operations (which are always binary intern, like a * b * c is actually calculated as ( a * b ) * c )) you intruduce an error which is due to the limited machine precision. For example sqrt(3.)^2 == 3. will likely return false as sqrt(3.) does not return a exact value (it cannot) but a rounded one. (However, sqrt(4.)^2 == 4. would return true, as 2. and 4. can be described exact in machine numbers). So this rule is more a rule of thumb.
Ye, I guessed something like that, thx. Just thought that triggers are kind of simplified compared to normal programming and therefore might use something... nevermind.
But how will this work if I compare two real numbers that are actually int? Like 0.0 == 0.0? Data editor sometimes does strange things in such situations...
Comparing any two fixed point values that are identical (they do not need to be "pseudo int, like 2.,3.,...) will always return true. This is, because even if you do something like sqrt(3.) == sqrt(3.) the machine will translate it into (e.g.) 1.732 == 1.732 which is not the same but still true!
I've recently read that in programming you can't use the "==" operator for comparing real numbers (dunno why). Well, you can technically, but this may result in bugs. So, the question: does this apply to triggers?
A computer cannot handle and never will be able to handle real numbers. Instead it uses machine numbers, in case of sc2 these are 20.12 fixed point numbers. This means 20 bit are used for describing the integer part (2^20 = approx 1 million = largest and smallest integer) and 12 bits are used to describe the fractional part (2^12 = 4096, i.e. the best precision you can archieve in the fractional part is 1/4096 = approx 0.0002). The latter is the reason why "==" comparision is avoided for machine numbers. The machine cannot handle the ultimate precision in mathematics but needs to round in between! This means if you do multiple operations (which are always binary intern, like a * b * c is actually calculated as ( a * b ) * c )) you intruduce an error which is due to the limited machine precision. For example sqrt(3.)^2 == 3. will likely return false as sqrt(3.) does not return a exact value (it cannot) but a rounded one. (However, sqrt(4.)^2 == 4. would return true, as 2. and 4. can be described exact in machine numbers). So this rule is more a rule of thumb.
@Elmaex:
Ye, I guessed something like that, thx. Just thought that triggers are kind of simplified compared to normal programming and therefore might use something... nevermind.
But how will this work if I compare two real numbers that are actually int? Like 0.0 == 0.0? Data editor sometimes does strange things in such situations...
Comparing any two fixed point values that are identical (they do not need to be "pseudo int, like 2.,3.,...) will always return true. This is, because even if you do something like sqrt(3.) == sqrt(3.) the machine will translate it into (e.g.) 1.732 == 1.732 which is not the same but still true!
Ok, guess that's all I needed to know for now, thank you!