[Numpy-discussion] [Python-ideas] Should our default random number generator be secure?

[Antoine Pitrou]

On Mon, 14 Sep 2015 09:26:58 +0100
Robert Kern <robert.kern at gmail.com> wrote:
> 
> Actually, I meant all of the crap *around* it, the platform-compatibility
> testing to see if you have such a hardware instruction or not, and C++
> template shenanigans in the surrounding code. It's possible that the
> complexity is only due to flexibility, but it was too complex for me to
> begin understanding *why* it's so complex before I succumbed to ennui and
> moved on to some other productive use of my free time. At least some of the
> complexity is due to needing software implementations of reduced-round
> crypto for decent performance in the absence of the hardware instruction.
> Performing well in the absence of the hardware instruction is very
> important to me as I do not seem to have the AES-NI instruction available
> on my mid-2012 Macbook Pro. Exposing counter-mode AES128 as a core PRNG is
> a nice idea, but it's just low on my wishlist. I want fast, multiple
> independent streams on my current hardware first, and PCG gives that to me.

Using AES also means emulating it on a GPU will be quite hard.

For the record, Numba is currently using a Mersenne Twister on the CPU,
to emulate Numpy's behaviour (although some of our distributions may be
different):

>>> def f(x):
...     np.random.seed(x)
...     l = []
...     for i in range(10): l.append(np.random.random())
...     return l
... 
>>> g = numba.jit(nopython=True)(f)
>>> f(10)
[0.771320643266746, 0.0207519493594015, 0.6336482349262754,
0.7488038825386119, 0.4985070123025904, 0.22479664553084766,
0.19806286475962398, 0.7605307121989587, 0.16911083656253545,
0.08833981417401027]
>>> g(10)
[0.771320643266746, 0.0207519493594015, 0.6336482349262754,
0.7488038825386119, 0.4985070123025904, 0.22479664553084766,
0.19806286475962398, 0.7605307121989587, 0.16911083656253545,
0.08833981417401027]


Currently we don't provide those APIs on the GPU, since MT is much too
costly there.

If Numpy wanted to switch to a different generator, and if Numba wanted
to remain compatible with Numpy, one of the PCG functions would be an
excellent choice (also for CPU performance, incidentally).

Regards

Antoine.