Calculation returns -0

See this:

> a=0
> print (5 * -a)

Zero is a neutral value.

However, Roblox Lua is returning -0.
This is a bug.

This also can cause some problems:
For example, if the variable a has -0 and I use a as an index of a table myTable[a] I could have two different indexes: [0] and [-0] depending on the part of the program which will be referencing the index 0.

It doesn’t cause issues with tables with a “positive” 0 index or a “negative” 0 index.
-0 is still equal to 0

1 Like

Negative zero represents the same table index as 0.

local tbl = {[0]=1}
tbl[-0] = 2
print(tbl[0]) --> 2

One problem that could arise with negative zero is when dividing by negative 0, although this doesn’t seem like a big problem.

print(1/0) --> inf
print(1/-0) --> -inf
1 Like

@incapaz @Halalaluyafail3

Forget about tables.
What I’m saying is:

A calculation is returning -0 and this is a BUG.

It is not a big deal though, just a visual bug, but sure it should be fixed. Point is it’s not urgent

From the IEEE 754 standard:

Moreover, there are two zero values, called signed zeros: the sign bit specifies whether a zero is +0 (positive zero) or −0 (negative zero).

−0 and +0 compare as equal

Compute sign as Csign = Asign XOR Bsign

If you multiply two floats with differing Sign bit, the standard requires the result to have the Sign bit set to 1, making it negative.


The only meaningful difference between 0 and -0 when doing float/double arithmetic (that I’m aware of) is the result when you divide by zero:

print(1 / 0) -- Equal to math.huge
print(1 / -0) -- Equal to -math.huge

Old versions of Lua incorrectly reuse the same constant for both 0 and -0 (whichever is defined first I think) so that snippet might not work in some cases. Negative zero is not a bug, but I still wouldn’t recommend relying too much on its behavior. From a floating point perspective it makes total sense, but I have mixed feelings about tostring exposing it.

1 Like

Random JavaScript VM:

> 5 * -0

Python 3:

>>> 5.0 * -0.0

This is how floating point computations work and is not a bug.


You could just do math.abs(-0) which should fix the problem. (I haven’t tested this out, so I don’t know if it will work)

Sorry, I’m not expert in JavaScript or Python, but I’ve been working with dozens of programming languages for almost 40 years and believe me, this is the first time I’ve seen -0 as a result of a mathematical operation…
But if Roblox staff understands that -0 is normal, you can close this topic.

They tend not to close topics here. Instead you mark a solution so that others can see without opening the topic that a solution has been found. In this instance, marking zeuxcg’s or NachtHemd’s answer as the solution makes the most sense as both of those provide the information as to why this is not a bug.

floating point has some oddities.
0.1 + 0.1 + 0.1 != 0.3
(0.1 + 0.2) + 0.3 != 0.1 + (0.2 + 0.3)


I have too, but I have seen it–This will yield it too:

#include <stdio.h>

int main( int argc, char *argv[] )
    printf( "-5.0 * 0: %f", -5.0f * 0 );

-5.0 * 0: -0.000000

I’m glad you mentioned this, as 0.1 is so notorious because “10 percent” is such an everyday thing.

In your defense though, you’re likely used to having an integer type available (especially for indexes!):

#include <stdio.h>

int main( int argc, char *argv[] )
    printf( "-5 * 0: %d", -5 * 0 );

-5 * 0: 0

Well, if you don’t like Python or JS, here’s C:

1 Like

This is such a fun piece of trivia because you can dive really deep into computer architecture and design with it.

I think at this point, this behavior is probably encoded at the hardware level. Even more fun is Apple encoded some JavaScript behavior into their chips.