If you port the example code from the Wikipedia Mersenne Twister page (and add a float interface), you end up with around 80 lines of code. See here:
http://pastebin.com/KiKUcBpH It works extremely well and is quite fast (I've not noticed any performance difference with Math.random, which on V8 is implemented as a simple congrual PRNG). Speaking of simple congrual PRNGs, those are particularly easy, just a couple of lines: function random() { seed = (seed*MULTIPLYER + PRIME_NUMBER) % MAXIMUM; return seed / MAXIMUM; } But, they suck (Wikipedia has a nice graphic illustrating this). Still, even they would be better than nothing. Cheers, Joe On Tue, Dec 1, 2015 at 1:45 PM, David Bruant <[email protected]> wrote: > Le 01/12/2015 20:20, Michał Wadas a écrit : >> >> >> As we all know, JavaScript as language lacks builtin randomness related >> utilities. >> All we have is Math.random() and environment provided RNG - window.crypto >> in browser and crypto module in NodeJS. >> Sadly, these APIs have serious disadvantages for many applications: >> >> Math.random >> - implementation dependant >> - not seedable >> - unknown entropy >> - unknown cycle >> (...) >> > I'm surprised by the level of control you describe (knowing the cycle, > seeding, etc.). If you have all of this, then, your PRNG is just a > deterministic function. Why generating numbers which "look" random if you > want to control how they're generated? > >> window.crypto >> - not widely known > > This is most certainly not a good reason to introduce a new API. > >> As we can see, all these either unreliable or designed mainly for >> cryptography. >> >> That's we need easy to use, seedable random generator >> > Can you provide use cases the current options you listed make impossible or > particularly hard? > > >> Why shouldn't it be provided by library? >> >> - average developer can't and don't want to find and verify quality of >> library - "cryptography is hard" and math is hard too >> > A library or a browser implementation would both need to be "validated" by a > test suite verifying some statistical properties. My point is that it's the > same amount of work to validate the "quality" of the implementation. > >> - library size limits it usability on Web >> > How big would the library be? > How much unreasonable would it be compared to other libraries for other use > cases? > I'm not an expert on the topic, but of the few things I know, it's hard to > imagine a PRNG function would be more than 10k > >> - no standard interface for PRNG - library can't be replaced as drop-in >> replacement >> > We've seen in the past that good libraries become de-facto standard (at the > library level, not the platform level) and candidate to being shimmed when > the library is useful and there is motivation for a drop-in replacement > (jQuery > Zepto, underscore > lodash). This can happen. > We've also seen ES Promises respect the Promise A+ spec or close enough if > they don't (I'm not very familiar with the details). > > David > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
