64-Bit Integer Overflow Issue

Help and Feedback Scripting Support
, ,
#1

Hi, so I’m trying to create an obby generator with random gamemodes, but im having issues getting a random number I keep running into limitations of the system.

math.random() work only with 32 Bit equivilent numbers, so I would only have a total of 4 billion unique seeds to generate between when using math.random().
:NextInteger() works with 64 bit equivilent numbers, which allows for over 18 quintillion unique seeds, so :NextInteger() would be the best choice when it comes to generating more unique seeds.

However instead of randomly generating between 18 quintillion unique numbers, Its overflowing well beyond the 64 bit integer limit. And after printing out (2^63) - 1 in the output, it is returning 9223372036854776000, with the known integer limit being 9223372036854775807. So when subtracting between the two numbers (9223372036854776000 - 9223372036854775807), I am getting a number well beyond the 64 bit integer limit, with the number roblox giving me being bigger by 193 digits.

This is the code I have to get a random seed between that limit 
ob.IntRange = {-(2^63), (2^63) - 1}
function ob.newSeed()
    return Random.new():NextInteger(ob.IntRange[1], ob.IntRange[2]);
end

How could I fix this issue?

4 Likes
#2

Are you sure need 2^63 seeds? Do you realize how big that number is?

1 Like
#3

Why would It matter?

yes.

1 Like
#4

Because that’s a large number of seeds. It’s probably not necessary.

I’m not sure why you can’t just try this, see if it works:

ob.IntRange = {-(2^63), (2^63) - 1}

local range = ob.IntRange[2] - ob.IntRange[1]

function ob.newSeed()
    return ob.IntRange[1] + (math.random() * range)
end
1 Like
#5

You can say the same thing for Minecraft (another game that uses this number to generate seeds)
Is 18 quintillion different Minecraft seeds necessary for a game like this? No, but It keeps the game randomized with different combinations of biomes, structures, and mobs.

Roblox seems to have a big issue with calculating 2^63 - 1 with it instead giving a number outside the limit, causing the subtraction not to work.

In order to get the Answers I got, I had to shorten the number to where the numbers were different, which I subtracted 6000 - 5807.

1 Like
#6

minecraft has been up for idk, a long time, and it still hasn’t reached 18 quintillion so you DON’T need that many seeds!

2 Likes
#7

Minecraft is a game with million of players, but it still probably doesn’t need that many seeds. It’s a big number.

If you used a smaller number, your problem would be solved.

1 Like
#8

Minecraft randomly picks a number and then creates the blocks.

Its random ranges from (-2^63 - 2^63 - 1), which is 18 quintillion.
Prior, it used to be up to 2^31.

Minecraft doesn’t store the seeds somewhere, it picks a number, and then creates a world using that number like with any world generator.

Either way, It should not matter how many unique seeds there are, and I’m not sure why it’s important or a big issue, Its just a number used to make something random.

1 Like
#9

Your problem is because the number is too big, so it does matter. I suggest taking it down under the limit. You are comparing your obby game generator to MINECRAFT, a game with millions of chunks, that’s huge.

Syntax - Luau.

1 Like
#10

You’re getting unexpected results because Luau doesn’t use real integers, it has a generic number type that is a 64-bit float. A float value can use the same number of bits as an int value, but it can represent a much larger range of numbers, with the downside being that higher numbers become less precise. For example, a 32-bit float at the number 33,554,432 has enough precision loss such that the next highest number it can represent is 33,554,436 (if Im understanding the Wikipedia article correctly).

I hope this helps. I’m not exactly sure what the main issue is in your post, other than the maximum number representable being higher than the 64-bit int limit when you thought otherwise.

2 Likes
#11

I’m not talking about perlin noise, I’m talking about seeds, which is still relevant.

That was the issue , where 2^63 give an incorrect number

That would make sense.

2 Likes
#12

Glad to have helped!

1 Like
#13

What I like to do is to give myself a hard time:

local Seed = ""

for Index = 1, math.random(math.random(25)) do
   Seed = Seed..tostring(math.random(0,9))
end

Seed = tonumber(Seed)
2 Likes
#14

Doing a little bit of more research, this would be reason.
Though, it isnt nessecarly Single-precision (The 32 Bit equivilent), but Double-precision (Which is 64 bit).

1 Like
#15

Yes, I used single-precision as an example, I’m sorry if I mislead you.

#16

As an update to this, i figured out a way to properly use 2^63 with its precision loss:

ob.IntRange = {
    -(2^63) + 1000, -- despite losing precision, -1000 is still accurate enough
    (2^63) - 1000   -- it allows us to be within the 64 bit range without overflow
}

function ob.newSeed()
    local n = Random.new():NextInteger(ob.IntRange[1], ob.IntRange[2]);
    local a = math.floor(n / math.random(2^31 - 1));
    return 
end

While it is possible to get up to 18 quintilion seeds, its essentially picking the lower numbers for better precision, but in rare cases, it may pick a seed at around 2^63 if it can. (But thats a 1 in 2.4 Billion chance of occuring), I’ll probably modify it to be more agressive (as in pick numbers for long ranges) with its outcome.

Thats actually a pretty smart way to do it.

1 Like