# 64-Bit Integer Overflow Issue

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

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

1 Like

Why would It matter?

yes.

1 Like

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

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

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

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

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

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.

1 Like

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

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

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

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

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

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

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.