PRNG - currently available solutions aren't addressing many use cases

joe joeedh at gmail.com
Wed Dec 2 00:10:03 UTC 2015


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 <bruant.d at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list