Difference between a number value and int value

Hi,

Whats the difference between a number value and int value?

From,
File

Integers can be any whole number value between -(2^63 - 1) and (2^63 - 1). Because in luau integers are stored in doubles, you start to lose precision after -(2^53) and (2^53) respectively (because IEEE-754 doubles have 52 bits for its mantissa.

Numbers can be any real number value be any value between -(1.810^308) and (1.810^308). As you reach higher numbers, though, you start to lose precision. Assuming IEEE-754 precision.

The same limits apply to the IntValue and NumberValue data types.

3 Likes

Number value can hold any type of number: decimal, integer, fraction,… Example: 1.3, 5/2, 3, 0.9999999999,…
Int value can only hold integers. Example: 1, 2, 3, 4,…

3 Likes

What is a situation where an IntValue is needed instead of a NumberValue?

Maybe I misread (or it might be me being horrible at math) but don’t floats lose precision just by existing? If I have a NumberValue in the workspace then use string.format with a very precise format string (’%.50f’), I lose precision automatically.

print(string.format('%.50f', workspace.TestValue.Value))
--> 0.40000000000000002220446049250313080847263336181641

Same thing with math operations on floats (taking into account the operation uses several different “digits”)

local value = 0.5 + 1.45 
print(string.format('%.50f', value))
--> 1.94999999999999995559107901499373838305473327636719

@DesertusX, An example where a NumberValue would be more useful often would be storing money. Let’s say a developer wants a currency where cents or parts of a dollar don’t exist (which is common in games), they want everything to be rounded to the nearest dollar, that would be an example of an integer being better than a float. Another example would be storing a stage in an obby, if I use a NumberValue, that means I could be on stage 103.5, being on a half stage doesn’t really make sense.

1 Like

I’m not sure that I’d say that floating point numbers “lose precision just by existing.” For integers, I say this because, you can store a large quantity of whole numbers (integers) without any loss in precision. The reason this is the case is because of the way floating point numbers are stored. Roblox uses IEEE-754 floating point numbers, which are stored as such:

  • 1 sign bit
  • 52 bits of mantissa
  • 11 bits of exponent (biased)

The mantissa gives us a 52 bits of precision for the starting decimal number of 1.xxxxxxxx, where the x’s can be a 0 or 1. Keep in mind that this is base 2, so for example, 1.1 would be 1.5 in base 10, and 10.11 would be 2.75 in base 10.

Then if you multiply this number by 2^0, then you can get all the integers from 1->1,

if you multiply it by 2^1, then you can get all the integers from 2->3 (1*2 and 1.5*2 respectively),

if you multiply it by 2^2, you can get all the integers from 4->7 (1*4, 1.25*4, 1.5*4, 1.75*4) which in base 2 would be: (1.00*4, 1.01*4, 1.10*4, 1.11*4), respectively.

You can keep repeating this pattern (2^n gives all integers from 2^n to 2^(n+1) - 1) until you use all 52 bits of mantissa, at which point you’ll find you can get any integer from 0 to 2^53 - 1, with perfect precision.

2^53 -1 would be 1.1111 …(44 more 1’s)… 1111 * 2^52

If you meant that in response to my point that “as you reach higher numbers, though, you start to lose precision”, though, you still do technically lose precision as you reach higher numbers. And by precision here I mean the norm from the number you actually intended. And any decimal precision you have is intended by the IEEE-754, so there is no technical “loss in precision” just by existing.

For instance, let’s say we have a floating point number consisting of 4 bits of mantissa and 3 bits of decimal,

this lets us have

1.xxxx * 2^(-3 → 4)

You’ll find that if I want to have 1.0625 (base 10), it’s very easy: 1.0001 * 2^0, but if I want 2.0625, it gets rounded to 1.0001 * 2^1, or in base 10, 2.125. The next number lower than this that you can have is 1.0000 * 2^1, which is just 2. By going up in by 1 base 2 exponent, I lost 1 base 2 decimal of precision. This is what I meant by as you reach higher numbers you lose precision.

1 Like

Ahh okay my bad, I get what you mean now. That’s really interesting, I had no idea numbers worked like that. Thanks for teaching me something new haha.

Kinda going off-topic here but that reminds me of an issue Minecraft had years ago where each time you went some exponent of 8(?) blocks from the origin (0,0) you’d start seeing loss of precision and each time you moved your movement became increasingly choppier and stutter-y.

Really interesting actually, that was a great explanation, thanks for that!

1 Like