Repository navigation
ndarray-rand with Complex and default PRNG #681
Description
I am considering a plan to port ndarray_linalg::generate::random feature into ndarray-rand crate. It is not depends on non-Ruat code (=LAPACK), and I think it will be useful for non-linalg users.
I'd like to improve the current API in the following two points. These are partially done in ndarray-linalg implementation.
Complex support
- num-complex has
randfeature which implDistribution<Complex> for Standard - It will be rand 0.5 while num-complex 0.2, i.e. incompatible to ndarray-rand doesn't work with rand 0.7 #658, Upgrade to rand 0.7.0 #659 until 0.3 will be released
Default PRNG
- Most ndarray users will seek
ndarray_rand::random((n, n))which does not need to initialize PRNG manually. - They will not need CSPRNG, but rand::thread_rng returns CSPRNG. For Monte-Calro or randomized algorithm usage, Mersenne twister will be good choice. I've re-implement SFMT in pure-Rust with std::arch.
Activity
LukeMathWalker commentedon Aug 5, 2019
For complex support, how should we proceed (once they update to
rand 0.7)? Should we let the end-user pull innum-complexto get complex distributions or are you suggesting we should pull innum-complexinndarray-randdirectly?On default PRNG, I do agree that a CSPRNG is probably overkill as the default RNG for
random- if we were to useSFMTI assume we would need a fallback for nonx86/x86_64architectures, am I correct?bluss commentedon Sep 1, 2019
The thread_rng doesn't seem like a high quality CSPRNG but the point is taken - that one is probably overkill. Ndarray-rand has never defaulted to it - as is documented. ("The default RNG is a fast automatically seeded rng (currently rand::rngs::SmallRng seeded from rand::thread_rng).")
And picking a new default with a good motivation sounds like a great idea.