[SOLVED] Bizarre nil issue

[grump]

I challenge you to find me a platform where the results differ then.

That would be easy enough for vanilla Lua, but I forgot about LuaJITs custom PRNG. That one is indeed platform independent IIRC. You can only have one global generator with one seed and global state though, which is another drawback in many situations. And you can't store/restore the state.

[pgimeno]

Indeed I believe LuaJIT took care of having a cross-platform PRNG.

I don't think there's a strong reason to prefer math.random over love.math.random or vice versa. The default initialization is crap anyway; I've often needed sub-second precision (not so often with Löve, admittedly, but it has happened). If you need repeatable results, you can use love.math.setRandomSeed() at the beginning.

Things are of course very different with respect to love.math.newRandomGenerator, for which LuaJIT doesn't even have an equivalence.

Edit: On a quick test, math.random is indeed marginally faster than love.math.random (by about 25%).

[BrotSagtMist]

Code: Select all

function newrandomgenerator(y)
 local trans=y or 1
 return function(x)
  math.randomseed(trans)
  trans=math.random()
  return x and math.ceil(x*trans) or trans
 end
end

[grump]

Code: Select all

function newrandomgenerator(y)
 local trans=y or 1
 return function(x)
  math.randomseed(trans)
  trans=math.random()
  return x and math.ceil(x*trans) or trans
 end
end

Your strongest point was that math.random is faster, but then you propose an alternative that is 20 times slower than LÖVE's RNG. It also drastically shortens the RNG's period.

[BrotSagtMist]

My point was what? Are you drunk?
I only showed how multiple seeds can be added to luajit, nothing more.

Whats your point? Asking stuff you clearly need no information about? Bragging about pseudoknowledge that no cares about because it practically never matters to anyone?

[Gunroar:Cannon()]

The graph of toxicity kept rising, I could feel it.
Anyway, I'm learning a few things, though I still think I'll stick to math.random...unless, of course...I don't.

[zorg]

A few things i wanted to post, but only after something like this happened.

Firstoff, for debug reasons you should use math.random instead love.math.random.
That makes debugging predictable.

Why? Elaborate please?

I'm guessing the main reasoning was that (and this is more related to what Löve does at init rather than luaJIT itself) löve doesn't seed lua(JIT)'s default random function (as was said before)...

That said, one very simple solution to this while *still* using löve's is a very neat love.math.setRandomSeed(0,0) call, for instance; right at the top of your main.lua (and called only while you want to debug stuff) - This was mentioned by pgimeno.

It is yet not clear if there are actually differences between platforms, i have not seen them in the wild so far. It is only that there is no guarantee that it is the same.

And on further downsides, loves version is a slight tick slower then luajits function.

In terms of map creation if we write math.randomseed(1) before a generation this will always create the same level and we can therefore say: There is a bug in level 1 instead of "sometimes it bugs".

Personally i use math.randomseed(love.math.random()) which gives the best of booth.

divided the above into 4 parts;
1. Actually, it might be guaranteed (on at least all officially supported platforms/architectures of LuaJIT); partial quote from the LuaJIT website's extensions page:

Enhanced PRNG for math.random()
LuaJIT uses a Tausworthe PRNG with period 2^223 to implement math.random() and math.randomseed(). The quality of the PRNG results is much superior compared to the standard Lua implementation which uses the platform-specific ANSI rand().

2. Marginally, as proven later in the thread (pgimeno again, a difference of 25%), but yes; that's one downside to löve's PRNG compared to luaJIT's.

3. This point wholly depends on the complexity; how many prng-s you use, etc. ...you don't need to go the minecraft route where you use one "main" seed to randomize/customize/generate stuff in a level...

4. That... really doesn't give you the best of both worlds, especially since luajit's randomseed can (if i'm not wrong) take in only one number value... that's 52 significant digits only, whereas Löve's seed setting methods can take in two 32-bit numbers as well, covering the whole range of seed values. You're basically sacrificing seed-space for a very minimal speedup... neither probably matter too much though.

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

Except that's a horrid implementation, and it's actually impossible to do correctly... unless mike pall hid a math.getrandomseed function up their sleeve... you'd need to save and restore that seed; setting the current random number as the new seed is not correct anyway.

Whats your point? Asking stuff you clearly need no information about? Bragging about pseudoknowledge that no cares about because it practically never matters to anyone?

• Whether you choose to use LuaJIT's tausworthe PRNG (using a 223-bit Linear feedback shift register) or Löve's xorshift* variant with state hashing (probably xoroshiro1024*, the only one on the linked page with one star at the end), is indeed not really a practical concern.
• Whether you choose one or the other based on their speed, given that they're so close to each other w.r.t. performance is, again, not really a practical concern.
• Reducing the state/seed space of a PRNG can become a concern in practice, since the returned values might no longer be suitable in so many ways, it's better to not tinker with stuff one doesn't understand... at least do it without publicising your tests.
• If you need multiple PRNG objects, it becomes a concern how those are implemented, or if they are even possible (with LuaJIT, they're not)
• Giving out a woefully wrong implementation of what's essentially not a PRNG object constructor is probably the biggest concern.

[BrotSagtMist]

And yet it returns usable numbers.
We are making games, not medical surgery software.
This solution would work fine for bots in games, so in practice i would use it if needed.
But really, its not that i thought long about it, just meant to counter the "doesn't even have an equivalence" part.
Can you explain what is so horrid about it?

[MrFariator]

Creates upvalues every time you use it, slower than just using plain math.random or love.math.random, and love.math.setRandomSeed achieves the same thing with less. In practice, it might work, but it's something I'd never even consider or suggest using.

However, I don't take an issue with your proposed generator, or possibly suggesting math.random over love.math.random. What I take an issue with is claiming that one makes debugging easier than the other. That's just patently false, considering both math.random and love.math.random have capabilities to set the seed, making them behave predictably where required. Might as well use a looping table of numbers (like what original Doom does) if you take such an approach to debugging.

[BrotSagtMist]

Creates upvalues every time you use it, slower than just using plain math.random or love.math.random, and love.math.setRandomSeed achieves the same thing with less.

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.
Now for the sake of closing this thread: show me a _not horrid_ solution in stock lua/jit.

What I take an issue with is claiming that one makes debugging easier than the other.

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.
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!".