Sturla Molden <stu...@molden.no> added the comment:

Further suggestions to improve the random module:

** Object-oriented PRNG: Let it be an object which stores the random state 
internally, so we can create independent PRNG objects. I.e. not just one global 
generator.

** Generator for quasi-random Sobol sequences.  These fail most statistical 
tests for randomness. But for many practical uses of random numbers, e.g. 
simulations and numerical integration, convergence can be orders of magnitude 
faster (often 1000x faster convergence) but still numerically correct. That is, 
they are not designed to "look random", but fill the sample space as uniformly 
as possible.

** For cryptographically strong random numbers, os.urandom is a good back-end. 
It will use /dev/urandom on Linux and CryptGenRandom on Windows.  We still e.g. 
need a method to convert random bits from os.urandom to floats with given 
distributions. os.urandom is already in the standard library, so there is no 
reason the random module should not use it.

** Ziggurat method for generating normal, exponential and gamma deviates. This 
avoids most call to trancendental functions (sin, cos, log) in transforming 
from uniform random deviates, and is thus much faster.

** Option to return a buffer (bytearray?) with random numbers. Some times we 
don't need Python ints or floats, but rather the raw bytes.

** Support for more statistical distributions. Provide a much broader coverage 
than today. 

** Markov Chain Monte Carlo (MCMC) generator. Provide simple plug-in factories 
for the Gibbs sampler and the Metropolis-Hastings alorithm.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12754>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to