Is this issue with >= / == known?

01-26-2010, 04:01 PM

Hi there,
I just wasted a lot of time debugging one of my triggers to realize the following:

Had something like this in my periodic trigger with a frequency of 40.

time_variable_1 = 1
time_variable_2 = 1

JASS:

if time_variable_1 >= time_variable_2 then
//does not return true all the time

if time_variable_1 == time_variable_2 then
//does return true all the time

Doesn't make much sense to me, or can someone of you explain? (In case it is NO bug :>)

01-26-2010, 04:14 PM	#2
Troll-Brain	== only consider the three first numbers under the digit or so, when >= , or <= check for the whole number. (probably 9 numbers under the digit, make some tests if you really care about it)

01-26-2010, 04:38 PM	#3
Na_Dann_Ma_GoGo	Ah okay thanks. So in the first case it could be possible that it is 0.999953123>=1 for example?

01-26-2010, 04:52 PM

Troll-Brain

Quote:

Originally Posted by Na_Dann_Ma_GoGo

Ah okay thanks.
So in the first case it could be possible that it is 0.999953123>=1 for example?

For example.
But i you could wait someone with more knowledge to know how it exactly works.

01-26-2010, 04:56 PM	#5
Iron_Doors	I just tested this some, and == seems to check if the difference between the arguments is less than or equal to 2^-10 (except for really high values), whereas <= checks with maximum precision. Interestingly enough, this means that you can compare two reals more precisely by doing (a <= b) && (b <= a) than by using ==.

01-26-2010, 04:59 PM

Troll-Brain

Quote:

Interestingly enough, this means that you can compare two reals more precisely by doing (a <= b) && (b <= a) than by using ==.

Yes, but using an epsilon margin value seems a better idea though.

01-26-2010, 05:00 PM

Iron_Doors

Quote:

Originally Posted by Troll-Brain

Yes, but using an epsilon margin seems a better idea though.

Depends entirely of what you're using it for.

EDIT:
You can change that margin too:

Zinc:

function biasedEquals(real a, real b, integer bias) -> boolean {
    // higher bias means easier matching
    return a / Pow(2.0, bias) == b / Pow(2.0, bias);
}

01-26-2010, 05:04 PM

Troll-Brain

Quote:

Originally Posted by Iron_Doors

Depends entirely of what you're using it for.

Yes, but i fail to guess a such case where you would need to use the highest precision as possible, instead of some epsilon margin, an example ?

01-26-2010, 05:12 PM

Iron_Doors

Quote:

Originally Posted by Troll-Brain

Yes, but i fail to guess a such case where you would need to use the highest precision as possible, instead of some epsilon margin, an example ?

Suppose you want to check some real value against a constant of yours that's used to indicate some special case. The higher the precision of the check, the lower the chance that a random value accidentally passes it.

01-26-2010, 05:18 PM

#10

Troll-Brain

Quote:

Originally Posted by Iron_Doors

Theory, only theory, just find a concrete case and i will believe it that would be useful, currently i consider this round up more as a feature than something lame, and if for some reason you need more precision, then use >= and <= but with an epsilon margin value.

Btw, Pow would be much slower than simply use an epsilon margin value.
Also using Pow on high real values would make absurd results.

01-26-2010, 05:31 PM

#11

Iron_Doors

Quote:

Originally Posted by Troll-Brain

I wasn't arguing whether or not it would be better to round in general. I was just saying it's interesting and that one could come up with uses for the precise one too. I'm not trying to sell you anything so please don't try to bash me just because you don't find it useful.

Quote:

Originally Posted by Troll-Brain

...
Btw, Pow would be much slower than simply use an epsilon margin value.
Also using Pow on high real values would make absurd results.

I only used Pow as an example. In reality, you'd use an array with precomputed powers of 2, or then a constant one.

01-26-2010, 05:38 PM

#12

Troll-Brain

Quote:

No, no you don't get it, i don't try to bash you.
Simply how reals are handled in jass functions i don't see the usefulness of this. (highest precision possible i mean)
Maybe i'm wrong, but you didn't gave me a concrete example.

01-26-2010, 10:38 PM	#13
Captain Griffen	not(x!=y) != x==y The first is true if and only if the two have exactly the same bits, whereas the second is true if and only if x is within +/- a small amount of y.