[SOLVED] Bizarre nil issue

[zorg]

And yet it returns usable numbers.

So does this function, but you shouldn't use it:

Code: Select all

function math.betterrandom() return 4 end

We are making games, not medical surgery software.

Indeed, neither of the two PRNG-s are cryptographically secure either, but there are properities one does want from their generators, even for games... idk about you but i'd be pissed off if i expected uniformity and did not receive that... or if it straight out didn't return specific numbers... or always returning a sequence like 5,24,163,5,24,163,...

This solution would work fine for bots in games, so in practice i would use it if needed.

Must be why old games had shitty bot ai, huh?

But really, its not that i thought long about it, just meant to counter the "doesn't even have an equivalence" part.

Well, you didn't counter jack though; luajit can not support multiple PRNG-s using the two functions it offers, math.random and math.randomseed

Can you explain what is so horrid about it?

Yes. besides the upvalue thing, which kinda would be a decent solution in and of itself, and the speed which i don't care about that much, the implementation itself is flawed... pretty sure i did say this before as well. You can't just save the output of the math.random call and think "oh, this is going to be the next seed!", it won't work as expected, and since there's no way to get the current seed/internal state of the luaJIT PRNG, you can't save and restore that state in any way whatsoever.

Obviously its slower, but the whole point was not to show that loves version is superior but that it is possible to get away without using it with only little effort in pure lua/jit.

But it's still going to work wrong and not do what you want; you can not save the PRNG's state.

Now for the sake of closing this thread: show me a _not horrid_ solution in stock lua/jit.

There is none, it's not possible... unless you re-implement the prng yourself in a way that can create separate generator objects, but that was not what the discussion was about.

In THIS very case hitting replace straight forward raises the error, thus it would lead to the fastest solving of THIS problem. Other claims are interpreted into it.

The original post's problem wasn't really about which prng they used, that was you opening your post with that opinion about it being better debug-able like that...

Seeing that the file has only 3 downloads, i gather you are giving an opinion without even having looked at the file. For what?
Such fuss about a badly phrased tip.... on the bright side nothing is as instructive as a few pages of "someone is wrong on the internet!".

Yeah, i didn't check the file because the issue was already solved; and yes, i am indeed correcting the eponymous someone who is actually dead wrong on the internet; hope no hard feelings though, i'm enjoying the banter myself.

[pgimeno]

I only showed how multiple seeds can be added to luajit, nothing more.

Have you tried it? The numbers generated are a bit boring.

Code: Select all

local f = newrandomgenerator(1)

for i = 1, 10 do print(f()) end
--[[ Output:
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
0.84018771715471
--]]

I don't recommend that method of generation anyway, because it reduces the period drastically; from the guaranteed 2^223 in LuaJIT to a maximum of 2^53, but most likely much less because the probability of a shorter cycle not to exist is small; in fact you have no guarantees as to the period. Furthermore, you lose the generator's guarantees with respect to the quality of the sequence.

[BrotSagtMist]

You can't just save the output of the math.random call and think "oh, this is going to be the next seed!", it won't work as expected, and since there's no way to get the current seed/internal state of the luaJIT PRNG, you can't save and restore that state in any way whatsoever.

My problem with that is that this problem once popped up on #lua and the channel concluded that this IS the solution.
I also did a 5 minutes test run to check for dupes and got none.
I can imagine that there is a chance to hit an endless circle tho. But in practice i have not found it and neither another flaw.

i'm enjoying the banter myself.

Ikr, and since ppl always misinterpret me in whatever forum i post (i do have a natural skill for that maybe?) i get it all the time. Yay.

Have you tried it? The numbers generated are a bit boring.

How dare you use my creation wrong! It does return randoms just fine, you on the other hand suddenly went from jit to PUC. The flaw there is obvious.

it reduces the period drastically; from the guaranteed 2^223 in LuaJIT to a maximum of 2^52, but most likely much less because the probability of a shorter cycle for not to exist is abysmal.

But is this a flaw? In my head this feels like complaining a map repeats after 1000 years instead of a million.
The good old ps2 had an 8bit seed in its standard random function, i think, dont dare quote me again if wrong, and the only game i can think of where this was exploitable to predict future gameplay was ff12.

[pgimeno]

How dare you use my creation wrong! It does return randoms just fine, you on the other hand suddenly went from jit to PUC. The flaw there is obvious.

Right, I made that mistake, sorry.

it reduces the period drastically; from the guaranteed 2^223 in LuaJIT to a maximum of 2^52, but most likely much less because the probability of a shorter cycle for not to exist is abysmal.

But is this a flaw? In my head this feels like complaining a map repeats after 1000 years instead of a million.

I can imagine the bug reports. "Hey this game is great, but from time to time the map looks completely flat and repetitive, any idea why?", or "I was playing normally but suddenly the game crashed saying that 0 is not a valid index".

The expected number of cycles in a random permutation is about ln(N)+0.5772, in this case about 37. The shortest of these has a probability of about 0.566146/k of being of length k, so you can expect short cycles to exist.

And zero is a valid result of math.random(), so ceil() is not the best strategy to get an integer from a uniform float.

Also, the quality of that generator depends on the quality of the seeding algorithm, which tends to be bad in my experience.

[Gunroar:Cannon()]

... from jit to PUC. .

PUC?

[GVovkiv]

... from jit to PUC. .

PUC?

aka vanila lua

[Gunroar:Cannon()]

Okay, makes sense now...

[milon]

LOL, I just realized I forgot to mark this as solved. Sorry!

And that was an interesting side conversation about RNGs. I'll keep using the one provided by Love personally, unless I have a specific reason not to.