Feature Request: Have Rnd() use a different PRNG
Community Forums/Monkey2 Talk/Feature Request: Have Rnd() use a different PRNG
| ||
| exactly as it says in the topic, I'd like to see monkey2 use Mersenne Twisters instead of its existing randomizer for the default Rnd() on all targets. Reasons: 1. Now that the focus is on c-based targets, it shouldn't be that difficult to ensure that the seed will remain constant across platforms. Pick the latest native implementation and stick with it. Use a "monkey" way to generate floats from the result if absolutely necessary to ensure that the seed doesn't "drift" between implementations if float handling deviates from the IEEE standard, but some implementations can already create doubles from 53-bit ints. 2. Mersenne Twister ensures a more even frequency distribution of resulting random numbers for a given seed over many iterations. Monkey's native randomizer isn't terrible, but certain numbers do tend to show up more than others more often and this can mess up games and apps that depend a lot on more reliable randomness. The uniformity of the resulting number distribution ensures more enjoyment from game players where randomness determines large amounts of the game's events -- certain kinds of events are less likely to happen in clusters compared to others due to the RNG. 3. mt19937's period before repeating numbers is extremely long, ensuring a lot of different numbers before repeats. In fact it's one of the primary advantages to using it -- it's 2^19937 − 1. I don't know what Monkey's PRNG has for a period, but, this again can affect games and apps where the user feels like they are seeing a "suspiciously similar" course of events happen more often. In particular, games and apps which set the seed based on a certain time of day, where the user (or scheduled routine) is expected to activate the seed at similar times of the day, can cause lots more of these things to happen given a short repeating period. 4. The code for mt19937 is well-examined and well-established. Problems with its randomness or target implementations can be researched a lot easier than rolling your own. MT's limitations are also well-known, and subsequent revisions to the core algorithm have produced more efficient and better-initialized routines. Limitations: It's not as fast as some other generators which have come out since. It's not cryptographically secure. Some other generators have more uniform distributions (I can't confirm this personally) Please consider this, or at least adding a better prng to the brl/std if Rng() must maintain backwards compatibility. Here are a couple other generators which may be of interest: https://en.wikipedia.org/wiki/Xorshift https://en.wikipedia.org/wiki/Multiply-with-carry https://en.wikipedia.org/wiki/Well_equidistributed_long-period_linear Edit: I guess also for the purposes of maintaining concurrent generators, it might be useful to also have generator objects, but I suppose that's not a core language thing as much as a standard library thing. Sometimes in a game, you want one generator to only be rotated at very specific times, but still want to generate randomness for separate processes without affecting the other generator (say for example to preserve a seed's ability to generate the same levels regardless of how user input affected subsequent calls to the generator)... etc |
| ||
| @Nobuyuki: Sometimes in a game, you want one generator to only be rotated at very specific times, but still want to generate randomness for separate processes without affecting the other generator (say for example to preserve a seed's ability to generate the same levels regardless of how user input affected subsequent calls to the generator) This is why I created the RandomSource class in Diddy. https://github.com/swoolcock/diddy/blob/master/src/diddy/math.monkey |
   |