0.9.0 Love.math

[Grubby]

Is the PRNG crypto strong or not? If not, then I'd suspect issues with value(s) spread. What math is actually being used to create the PRNG values?

Just curious...

[slime]

It is not, and it's not supposed to be. PRNGs in games almost never need that characteristic - performance, on the other hand, is very important. It is also very important for PRNGs in games to be seedable and reproducible, so you can use the same seed to get the same results every time (if you need.) The latter characteristic is used to great effect in games like Minecraft - or more subtly in certain types of save-files for some games.

love.math.random uses a 64-bit Xorshift algorithm.

http://www.javamex.com/tutorials/random ... hift.shtml
https://bitbucket.org/rude/love/src/tip ... at=default

[gim]

It is not crypto strong, but from what I understand from what you've written in other thread, you don't need crypto-strong RNG.
I guess, you only need RNG, with some good properties.
As slime has written, love.math.random uses Xorshift (which actually is LFSR with primitive polynomial).

Used xorshift will provide full period, but I think (although I haven't tested) it'll fail statistical tests (i.e. Crash + Smallcrush : http://en.wikipedia.org/wiki/TestU01).

But fear not!, math.random under luajit uses Tausworthe prng, which should be quite good.

Besides, I don't think there would be problem with adding (additionaly) Mersenne Twister to love (that would probably require permission of the author, but from what I've heard, that is not a problem)

[slime]

One of the web pages I linked above says this:

[Xorshift's] resulting values pass Marsaglia's "Diehard battery" of statistical tests for randomness. L'Ecuyer & Simard (2007) also found that values of 13, 7 and 17 [which LÖVE uses] fail on only 7 of the 160 tests of their BigCrush battery.

[gim]

One of the web pages I linked above says this:

[Xorshift's] resulting values pass Marsaglia's "Diehard battery" of statistical tests for randomness. L'Ecuyer & Simard (2007) also found that values of 13, 7 and 17 [which LÖVE uses] fail on only 7 of the 160 tests of their BigCrush battery.

haven't noticed that, good to know it fails only on 7 (I knew it passes "diehard" tests - those are really basic ones)

[hryx]

or more subtly in certain types of save-files for some games.

You got my attention with that. Can you explain a use case pertaining to save files?

[Hexenhammer]

or more subtly in certain types of save-files for some games.

You got my attention with that. Can you explain a use case pertaining to save files?

Instead of saving the current world state (which maybe big and complex) you just save the RNG seed which created that state. "Loading" a game then means recreating the world state by re-seeding your RNG to the saved seed and running world gen. Of course that only works if the world state in question is static after generation. But in theory you could also handle partially dynamic world state by saving the RNG seed + the difference between the world state and the result of running world gen with that seed.

You may also want to save the RNG state to stop players from just reloading when they get an unfortunate dice roll or something. E.g. turn-based game, player saves at the beginning of the turn, does something with a 70% chance of success, fails.. if you do not save the RNG state he could now simply reload and try again until he succeeds. But if the RNG state is saved he always gets the same result there and thus has to accept it.