Open termoshtt opened 5 years ago
For complex support, how should we proceed (once they update to rand 0.7
)? Should we let the end-user pull in num-complex
to get complex distributions or are you suggesting we should pull in num-complex
in ndarray-rand
directly?
On default PRNG, I do agree that a CSPRNG is probably overkill as the default RNG for random
- if we were to use SFMT
I assume we would need a fallback for non x86/x86_64
architectures, am I correct?
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.
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
rand
feature which implDistribution<Complex> for Standard
Default PRNG
ndarray_rand::random((n, n))
which does not need to initialize PRNG manually.