Hacker News new | past | comments | ask | show | jobs | submit login

the knocks against the openbsd arc4random, namely

> No facility for a user-provided seed, preventing programs from getting reproducible results

> Periodically “stirs” the generator using kernel-provided entropy; this code must be removed if reproducible results desired (in testing its speed, I deleted this code)

seem like exactly the kinds of foot guns you really want removed from an RNG you're using for real live code.




Sometimes you want well-mixed numbers, but in a sequence that you can rerun. If you are simulating a process or testing games, having a fully deterministic setup if you know a seed is a great help to reproduce unusual behavior sighted.


Some people need reproducible "randomness". They're testing a model, for example. I'm not sure if this RNG is good for them or not.


Some people seem forever confused about the difference between random and deterministic.


Reproducibility and seed-ability isn't a footgun unless it's easy to do wrong accidentally, or hard to do right accidentally.

The former really isn't a problem except for really poor APIs, and the later isn't made worse by it... although the PCG random author does like to make a point of just how bad it is in C++ (see [1]).

[1] https://www.reddit.com/r/cpp/comments/31857s/random_number_g...


What about unit tests?


Produce a set of random numbers once and store them as part of the test set. That way your test is independent of the black box which is your RNG. Or make your own simple RNG - in these cases you are looking for "arbitrary, definitely not just sequential" rather than cryptographically random (or, indeed, truly random at all).

If you rely on the order of the output, for reliably consistent test cases in this instance, avoid using black-box RNGs which could change implementation under your nose without much or any warning.


Cryptographically random isn't the aim here - pseudorandom is.

A seedable black-box RNG that guarantees what seed corresponds to what stream is way simpler to use than a list of random numbers, IMHO. It's the difference between copying one number and copying a million.


> Cryptographically random isn't the aim here

We are agreeing here.

> A seedable black-box RNG that guarantees what seed corresponds

If you can control when the blackbox gets updated, or the blackbox carries a guarantee of stable output for any given seed over the while time of its existence, yes. But if you are using OS provided RNGs, as a for instance, their behaviour is not defined (well they are, but those definitions are not set in stone) and may change as kernel updates happen.

That is why I suggest "making your own simple PRNG". This could be as simple as picking a known documented algorithm as implemented by a particular library and using that in your test cases - it doesn't need to be as much as writing your own function even.


Right... but nobody's suggesting replacing the OS's RNG.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: