Discussion Accuracy of GetUnitFacing(unit u)

[SineCosine]

Well, a user by the name of AccName was having problems with GetUnitFacing.
His problem?

if GetUnitFacing(u) == 270.00 and GetUnitFacing(u) != 270.00 then
    //Stuff
endif

At a glance, you should be able to conclude that the following is impossible.
How can something be and not be at the same time?

So, I set out to see if it was a bug or if it was an inaccuracy.
At first, it seemed like a bug.

After all..
I used this:

library BlizzardHasPotentialBugs initializer Blizzard_Init
    globals
        boolean Set270 = false
    endglobals

    private function Test_Bug takes nothing returns nothing
        local unit u = gg_unit_Hpal_0000
        local real f
        
        if Set270 == true then
            call SetUnitFacingTimed(u, 270.00, 0)
        endif
        
        set f = GetUnitFacing(u)
        
        if (f == 270.00) and (f < 270.00) then
            if f <= 270.00 then
                call BJDebugMsg("Unit's facing is either smaller than or equal to 270.00")
            endif
            if f >= 270.00 then
                call BJDebugMsg("Unit's facing is either larger than or equal to 270.00")
            endif
            if f == 270.00 then
                call BJDebugMsg("Unit's facing is equal to 270.00")
            endif
            if f != 270.00 then
                call BJDebugMsg("Unit's facing not equal to 270.00")
            endif
            if f < 270.00 then
                call BJDebugMsg("Unit's facing is smaller than 270.00")
            endif
            if f > 270.00 then
                call BJDebugMsg("Unit's facing is larger than 270.00")
            endif
            call BJDebugMsg(R2S(GetUnitFacing(u)))
        else
            call BJDebugMsg("I ain't bugged!")
            call BJDebugMsg(R2S(GetUnitFacing(u)))
        endif
        
        set u = null
    endfunction

    private function Stuff takes nothing returns boolean
        if GetSpellAbilityId() == 'A000' then
            if Set270 == true then
                set Set270 = false
            else
                set Set270 = true
            endif
        endif
        
        return false
    endfunction
    
    private function Blizzard_Init takes nothing returns nothing
        local trigger t = CreateTrigger()
        call TriggerRegisterTimerEvent(t, 1.00, true)
        call TriggerAddAction(t, function Test_Bug)
        
        set t = CreateTrigger()
        call TriggerRegisterPlayerUnitEvent(t, Player(0), EVENT_PLAYER_UNIT_SPELL_EFFECT, null)
        call TriggerAddCondition(t, Condition(function Stuff))
    endfunction
endlibrary

And it showed me:

Unit's facing is either smaller than or equal to 270.00
Unit's facing is equal to 270.00
Unit's facing not equal to 270.00
Unit's facing is smaller than 270.00
270.00

That's queer?
IT'S A BUG!

Nay, I say.
The answer is, === and !== should be used.
But Blizzard doesn't have those as valid comparisons..
Do they?

So..
Just how many zeroes should we put to avoid this weird bug?
I tried it and..
The answer is: Many.

32 zeroes, to be exact.
0.0000000000000000000000

So..
What's your take on this? o.0

On a side note..
Why would someone wanna' know if something is and isn't at the same time?

 

[Bribe]

Some responses that return real values have miniscule differences sometimes. GetSpellTargetX/Y return slightly different values for the same spell, and GetUnitFacing is not a good check for the angle between the caster and the spell target because sometimes the caster is able to get off the effect before completing the full turn towards the target.

 

[SineCosine]

Yea, I know about the GetSpellTargetX/Y part, it pissed me off to no end at one point in time xD

The guy wasn't looking for the angle between the caster and target, I think.
He just wanted to know why this would give him a message when it isn't supposed to:

if GetUnitFacing(u) == 270.00 and GetUnitFacing(u) != 270.00 then
    call BJDebugMsg("SHIT! I BUGGED! Oh noes!")
endif

[EDIT]
My solution is to add 32 decimal places for every value he wants to check this way..
But that would be tedious for a GUI user..
Would it not? o.0

And, would it even work?
As in, is it the solution to the problem? xD

[EDIT=2]
Holy Shi--
I tried to make a function that would make everything accurate up till 32 decimal places (In case it were ever needed..)
But something bugged ._.

Does it have something to do with the fact that binary is in base 2?

call BJDebugMsg(R2S(270.00 * 1.00000000000000000000000000000000) + " Weird, huh?")
call BJDebugMsg(R2S(110.00 * 1.00000000000000000000000000000000) + " Weird, huh?")
call BJDebugMsg(R2S(220.00 * 1.00000000000000000000000000000000) + " Weird, huh?")

Results are..

540.000 Weird, huh?
220.000 Weird, huh?
440.000 Weird, huh?

 

[uberfoop]

Yes, reals in Warcraft 3 fail miserably quite frequently when you use any sort of equality comparison on them. You will notice, however, that the >= and the < did NOT conflict. wc3 reals ARE good enough for that to work.

That's hardly the worst thing about wc3's floating point real system though. The worst is that arithmatic operations frequently store end results which are just wrong. If you have some repeating function on a timer which counts with a real in incriments of .1 from 0 to 10, you will be VERY lucky if the r==10 when you want to cut your looping works (as opposed to an r>9.91 and r<=10.09 check or something, which generally would work).


Anyway, welcome to the world of wc3 mathematics.

 

[SineCosine]

Wow ._.
But what about the 32 decimal places fixing it? XD

Is that correct?
Or am I sadly mistaken, too =/

I tried the test again with this:

    private function FixReal takes real r returns real
        return (r * 1.00000000000000000000000000000000) / 2.00000000000000000000000000000000
    endfunction

And I compared GetUnitFacing(u) with FixReal(270.00)
The unit's facing never got to == 270 and != 270 at the same time ever again =)

 

[Bribe]

This is why I have R2I conversions in my Time Travel system instead of using reals the whole time.

 

[SineCosine]

That would simplify things a hell lot ._.
Oh, well.

I'll try to forget this ever happened xD

 

[Troll-Brain]

== rounds about 3 numbers or so under the digit (like R2S i think), while >= , <= don't, or at least with more numbers under the digit.
I haven't tested the other operators, but maybe it's the same shit.
Easy to test, hf.

 

[Bribe]

Please also keep in mind that, in terms of both reals and integers, you must be absolutely positive that that value will not increase/decrease unexpectedly and overshoot the "==" margin.

 

[SanKakU]

Yes, reals in Warcraft 3 fail miserably quite frequently when you use any sort of equality comparison on them. You will notice, however, that the >= and the < did NOT conflict. wc3 reals ARE good enough for that to work.

That's hardly the worst thing about wc3's floating point real system though. The worst is that arithmatic operations frequently store end results which are just wrong. If you have some repeating function on a timer which counts with a real in incriments of .1 from 0 to 10, you will be VERY lucky if the r==10 when you want to cut your looping works (as opposed to an r>9.91 and r<=10.09 check or something, which generally would work).


Anyway, welcome to the world of wc3 mathematics.

would this be because warcraft 3 often uses random values? like rolling dice for damage for units, unlike in starcraft.

 

[uberfoop]

would this be because warcraft 3 often uses random values? like rolling dice for damage for units, unlike in starcraft.

Not at all. If that were the case, it would only screw up on use of random values and not when, say, incrimenting along in small steps from one value to another.

I figure it's just a really bad case of floating point operation precision fail.

Here's a basic example. When watching the numbers go by, note the jumps being small power-of-two-esque numbers:

scope MathFail initializer Init

globals
    real r = 0.00
endglobals

private function Repeater takes nothing returns nothing
    set r = r + .1
    call BJDebugMsg(R2SW(r,30,10))
endfunction

private function Init takes nothing returns nothing
    call TimerStart(CreateTimer(),.5,true,function Repeater)
endfunction

endscope

 

[SineCosine]

So..
WC3 isn't the only thing suffering from this? o.0

 

[Jedi]

I can't see a great problem since nobody uses an absolute real value like this

//Bad
if GetUnitFacing(unit) == SomeReal then

//Good
if GetUnitFacing(unit) > SomeReal and GetUnitFacing(unit) < SomeOtherReal then

 

[SineCosine]

I know that nobody would do this..
Except for a few..

But it does pose a potential problem. (Whatever that problem may be =x)
Well, lesson learned, I guess.