# Better random algo than the built-in Random() function?

**URL:** <https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536>\
**Category:** Ideas\
**Tags:** builtins\
**Created:** [February 6, 2022, 1:45pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536 "2022-02-06T13:45:49Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![SnakeBite](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/snakebite/32/6119_2.png) [@SnakeBite](https://discuss.python.org/u/SnakeBite)\
**Post date:** [February 6, 2022, 1:45pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/1 "2022-02-06T13:45:49Z")

</div>

The built-in random function uses the twister algorithm and I’d like to find something better.

One option I’ve found so far is Quantum Random which is “A Python interface to the ANU Quantum Random Numbers Server.”

Although the above solution is a good one, I have a feeling it’s going to be extremely slow.

The second potential option would be to use NumPy.SFC64, but I have no idea how I could use this to generate numbers within a certain range.

Are there any other better solutions out there? Is NumPy.SFC64 a good/viable option?

---

<div class="post-metadata">

**Author:** ![BowlOfRed](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/bowlofred/32/3379_2.png) [@BowlOfRed](https://discuss.python.org/u/BowlOfRed)\
**Post date:** [February 6, 2022, 9:35pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/2 "2022-02-06T21:35:19Z")

</div>

I think that depends on what aspects you need to be “better”. There is the generator in the [secrets](https://docs.python.org/3/library/secrets.html) module, but outside of cryptography it might not be what you need.

---

<div class="post-metadata">

**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\
**Post date:** [February 6, 2022, 9:43pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/3 "2022-02-06T21:43:25Z")

</div>

Better in what way?

Faster? Longer period? Shorter runs? Different spectral characteristics? What property does the Twister algorithm lack for you?

Saying “I want a better PRNG” is a bit like saying “I want a better car”. Okay, but what do you mean by better? What are you looking for? What’s better for me might not be better for you.

You suggested numpy.SFC64:

“I have no idea how I could use this to generate numbers within a certain range.”

[https://numpy.org/devdocs/reference/random/generated/numpy.random.Generator.integers.html#numpy.random.Generator.integers](https://numpy.org/devdocs/reference/random/generated/numpy.random.Generator.integers.html#numpy.random.Generator.integers)

[https://numpy.org/devdocs/reference/random/generator.html#numpy.random.Generator](https://numpy.org/devdocs/reference/random/generator.html#numpy.random.Generator)

---

<div class="post-metadata">

**Author:** ![mikecm](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mikecm/32/5448_2.png) [@mikecm](https://discuss.python.org/u/mikecm)\
**Post date:** [February 13, 2022, 11:55am UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/4 "2022-02-13T11:55:36Z")

</div>

Looks like there are lots of negative things associated with [Twister](https://en.wikipedia.org/wiki/Mersenne_Twister#Disadvantages). And this source mentions [CryptMT](https://www.ecrypt.eu.org/ecrypt2/). But I cant find info about licencing. So I guess there are choices here: add new function, and deprecate random. As one may expect if you need something added to Python then you need do some work unless its well supported and something the core devs are willing to take on.

---

<div class="post-metadata">

**Author:** ![SnakeBite](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/snakebite/32/6119_2.png) [@SnakeBite](https://discuss.python.org/u/SnakeBite)\
**Post date:** [February 13, 2022, 2:41pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/5 "2022-02-13T14:41:33Z")

</div>

Better in actually being random and not being able to be detected by AI.  
Sorry for not specifying. I am absolutely not very well versed in what makes random algorithms good or bad. I’ve just been told Twister is not a good choice for my project.

---

<div class="post-metadata">

**Author:** ![mattip](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/mattip/32/330_2.png) [@mattip](https://discuss.python.org/u/mattip)\
**Post date:** [February 13, 2022, 3:13pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/6 "2022-02-13T15:13:13Z")

</div>

The refactored NumPy random module was carefully designed with these concerns in mind. You might want take a look at the [bit generator documentation](https://numpy.org/devdocs/reference/random/index.html). NumPy (and many others) call these Pseudo Random Number Generators (or PRNGs), and there are a number of them inside NumPy. Even more can be found in the [randomgen](https://github.com/bashtage/randomgen#included-pseudo-random-number-generators) repo, where the NumPy routines were originally laid out. You can also peruse issues and discussions around the PRNGs in Numpy, like [here](https://numpy.org/devdocs/reference/random/upgrading-pcg64.html), [here](https://github.com/numpy/numpy/issues/16313), [here](https://github.com/numpy/numpy/issues/13635). The message I take from these discussions is that (1) a lot of thought has gone into the pseudorandomness of the set of PRNGs used in NumPy, (2) like any complicated subject there will never be a 100% consensus around which algorithm is better, (3) for most of us the difference between these PRNGs is very slight. So if you are not an expert, you should stick with the NumPy recommended best practices (disclaimer: I helped merge the referenced expert’s work into the module, so I am biased).

---

<div class="post-metadata">

**Author:** ![SnakeBite](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/snakebite/32/6119_2.png) [@SnakeBite](https://discuss.python.org/u/SnakeBite)\
**Post date:** [February 13, 2022, 5:39pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/7 "2022-02-13T17:39:01Z")

</div>

Sounds good thank you for clearing that up Matti.

I’m going to go ahead and assume that the fellow who told me not to use the standard NumPy random module was being paranoid.

---

<div class="post-metadata">

**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\
**Post date:** [February 13, 2022, 11:21pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/8 "2022-02-13T23:21:08Z")

</div>

There are lots of negative things associated with every PRNG, and there  
are lots of negative things associated with physical sources of  
randomness too.

---

<div class="post-metadata">

**Author:** ![steven.daprano](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/steven.daprano/32/1083_2.png) [@steven.daprano](https://discuss.python.org/u/steven.daprano)\
**Post date:** [February 13, 2022, 11:57pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/9 "2022-02-13T23:57:23Z")

</div>

Told by who? What reasons did they give?

Maybe if we knew more about your project, we could advise you better.

There is a lot of superstition among coders about PRNGs. Some of that is understandable: some simple PRNGs are really poor quality. But as soon as you hear somebody talk about needing “real randomness”, 99% sure they are following superstition.

“Real randomness” is impossible to define, and difficult to recognise. The old Dilbert cartoon is true:

> **[Dilbert Comic Strip on October 25, 2001](https://dilbert.com/strip/2001-10-25)**
>
> Headline: Tour of Accounting. Dilbert is wiping spit off of himself with a towel. A troll tour guide says, "Over here we have our random number generator." The troll places its hands on a slab of rock and relays the message of "nine nine ...

I am the author of PEP 506 so I am very aware of the limitations of the Mersenne Twister against attack:

> **[PEP 506 -- Adding A Secrets Module To The Standard Library](https://www.python.org/dev/peps/pep-0506/)**
>
> The official home of the Python Programming Language

Countering that, cryptographically secure random number generators have their own disadvantages, especially if you are doing any form of scientific research, where being able to replicate your results is paramount. Being able to replicate the same results with a reproducible stream of randomness generated from a seed is important.

What do you think the AI is going to detect? What are you using the AI for and why is that relevant? Unless you know what problem you are trying to avoid, how do you know that that the PRNG you pick isn’t _worse_ than Twister?

If you don’t know what problem you are trying to avoid, then any choice you make is just as likely to make it worse as to make it better. If you are already using Numpy, you should probably use whatever PRNG the Numpy people have chosen.

If you aren’t using Numpy, then you should just stick to MT until such time you know _why_ MT is (allegedly) not suitable. Unless you know what specific characteristic of MT is undesirable, how can you make a sensible choice of an better alternative?

---

<div class="post-metadata">

**Author:** ![westurner](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/westurner/32/867_2.png) [@westurner](https://discuss.python.org/u/westurner)\
**Post date:** [August 3, 2025, 5:35pm UTC](https://discuss.python.org/t/better-random-algo-than-the-built-in-random-function/13536/10 "2025-08-03T17:35:41Z")

</div>

paranoid\_crypto includes many randomness tests implemented in python for functions that say that they generate random bits or bytes:

- [google/paranoid\_crypto/docs/randomness\_tests.md#randomness-tests](https://github.com/google/paranoid_crypto/blob/main/docs/randomness_tests.md#randomness-tests)
  - lists Python’s mt19937 PRNG specifically
  - randomness tests
    - [NIST 800-22 ‘ in randomness\_tests.md#nist-sp-800-22](https://github.com/google/paranoid_crypto/blob/main/docs/randomness_tests.md#nist-sp-800-22)
    - source: [paranoid\_crypto/paranoid\_crypto/lib/randomness\_tests at main · google/paranoid\_crypto · GitHub](https://github.com/google/paranoid_crypto/tree/main/paranoid_crypto/lib/randomness_tests)
    - docs: [paranoid\_crypto/docs/randomness\_tests.md at main · google/paranoid\_crypto · GitHub](https://github.com/google/paranoid_crypto/blob/main/docs/randomness_tests.md#tests)

Links to the docs, specs, and sources for random in the python stdlib and for 3rd party packages like numpy, scipy, and sympy;

- [random — Generate pseudo-random numbers — Python 3.13.5 documentation](https://docs.python.org/3/library/random.html#module-random)
- [secrets — Generate secure random numbers for managing secrets — Python 3.13.5 documentation](https://docs.python.org/3/library/secrets.html)
  - [PEP 506 – Adding A Secrets Module To The Standard Library | peps.python.org](https://peps.python.org/pep-0506/)
    - PRNG
      - MT
        - MT19937
          - `random` module
            - [cpython/Lib/random.py at main · python/cpython · GitHub](https://github.com/python/cpython/blob/main/Lib/random.py)
            - [https://github.com/python/cpython/blob/main/Modules/\\\_randommodule.c](https://github.com/python/cpython/blob/main/Modules/%5C%5C%5C_randommodule.c)
            - 

> Warning: (python2) The pseudo-random generators of this module should not be used for security purposes. Use [`os.urandom()`](https://docs.python.org/2/library/os.html#os.urandom "os.urandom") or [`SystemRandom`](https://docs.python.org/2/library/random.html#random.SystemRandom "random.SystemRandom") if you require a cryptographically secure pseudo-random number generator.

            - 

> Warning: (python3) The pseudo-random generators of this module should not be used for security purposes. For security or cryptographic uses, see the [`secrets`](https://docs.python.org/3/library/secrets.html#module-secrets "secrets: Generate secure random numbers for managing secrets.") module.

    - CSPRNG
      - `secrets`module
        - [cpython/Lib/secrets.py at main · python/cpython · GitHub](https://github.com/python/cpython/blob/main/Lib/secrets.py)
          - → [`random.SystemRandom` in random.py#L889](https://github.com/python/cpython/blob/676748d4da3671205f537ecd61a492861e37b77b/Lib/random.py#L889)

- …
- NumPy
  - [Random sampling — NumPy v2.3 Manual](https://numpy.org/doc/stable/reference/random/index.html#)
  - [Legacy random generation — NumPy v2.3 Manual](https://numpy.org/doc/stable/reference/random/legacy.html#distributions) #distributions

- SciPy
  - [Statistical functions (scipy.stats) — SciPy v1.16.1 Manual](https://docs.scipy.org/doc/scipy/reference/stats.html)
    - Continuous distributions
    - Multivariate distributions
    - Discrete distributions

  - [Random Number Generators (scipy.stats.sampling) — SciPy v1.16.1 Manual](https://docs.scipy.org/doc/scipy/reference/stats.sampling.html)

- SymPy
  - [Stats - SymPy 1.14.0 documentation](https://docs.sympy.org/latest/modules/stats.html)
    - P(), E(), H(), variance(), density(), sample()
    - DiscreteUniform(), Die(), Coin(), DiscreteRV(), ContinuousRV()
