-0 being processed wrong

ID:114000
 
Jun 2 2011, 11:47 am
Not a bug
BYOND Version:482
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 11.0.696.71
Applies to:DM Language
Status: Not a bug
This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:
When entered -0 (minus zero) as parameter, it fails to recognise it as a 'simple' 0 (zero).

Numbered Steps to Reproduce Problem:

Code Snippet (if applicable) to Reproduce Problem:
proc
     testZero(something)
          if(something != 0)
               world << "Not zero!"
          else
               world << "Zero!"

     testtestZero()
          testZero(10)
          testZero(-15)
          testZero(0)
          testZero(-0) //for example when it's -var, when var is unknown


Expected Results:
Not zero!
Not zero!
Zero!
Zero!

Actual Results:
Not zero!
Not zero!
Zero!
Not zero!

Does the problem occur:
Every time? Or how often?
Always
In other games?
Tested it both in game and standalone.
In other user accounts?
Yes.
On other computers?
Yes.
When does the problem NOT occur?
by replacing 'something != 0' with 'something < 0 || something > 0'

Workarounds:
See above.
</0>
Jun 2 2011, 4:24 pm
I can't reproduce this on 32-bit Windows XP. Is there a possibility is may be a 64-bit issue? That's bizarre, but weirder things have happened.
Jun 2 2011, 4:30 pm
This works fine on Windows 7, Home Premium 64-bit.
I get the expected results.
Jun 2 2011, 4:31 pm
Cannot reproduce. Works fine on Windows 7 Professional 64-bit

Not zero!
Not zero!
Zero!
Zero!
Jun 2 2011, 9:55 pm
well, the code I use is this:

reduceHP(dmg as num, obj/O)
            hp -= dmg
            showHPOverlay(-dmg)

            if(hp <= 0)
                deathCheck(O)

        showHPOverlay(dmg)
            if(dmg != 0)
                var/obj/HPOverlay/HP = new /obj/HPOverlay(dmg)


On which it shows the overlay, even if it's 0
Jun 2 2011, 10:44 pm
You shouldn't be doing that then.
Jun 3 2011, 6:28 am
It's not an OS problem: I'm also using Windows 7 Ultimate 64 bit. I get the expected results. However, I am running 483, not 482.
Jun 3 2011, 6:37 am
must be something with the code then, though I have no clue what could bug it. All I do is what's coded below ...

I guess you can put a lock on this thread.
Jun 3 2011, 9:49 pm (Edited on Jun 3 2011, 9:59 pm)
Don't worry, I figured this out, or at least found more ways to reproduce it.
I found two ways to generate this negative zero. One way is through input as number. The second way is this text2num("-0"). Both of these are not equal to your traditional zero. I have named this beast, Anti-Zero.
mob/verb
    testZero(something as num)
        if(something != 0)
            world << "Not zero!"
        else
            world << "Zero!"
    testAntiZero()
        var/AntiZero=text2num("-0")
        if(AntiZero != 0)
            if((AntiZero+1-1) != 0)
                world << "Not zero!"
            else
                world << "Anti-Zero!"
        else
            world << "Zero!"


The problem seems to be either
"-0 is being evaluated incorrectly at runtime"
or
"-0 is being converted incorrectly from a string to a number"
Jun 3 2011, 9:58 pm
aaah, possible, since I originally had "as num", but it got lost in testing.

Dunno if I use text2num() somewhere, but I don't think so.

Nice find! Makes me feel less stupid now :p
Jun 3 2011, 10:03 pm
Confirmed my theory. Check out this neat trick!
mob/verb
    AntiZero()
        var/AntiZero=text2num("-0")
        world<<num2text(AntiZero)

Run it, and notice how the negative sign isn't lost in the result.
Jun 4 2011, 4:09 pm
Chowder wrote:
I have named this beast, Anti-Zero.

It's actual name is negative zero, and it's not uncommon in computer settings.
Jun 4 2011, 5:17 pm
I know what it is. I was just being dramatic. D: Nice wiki link though, that I did not know.