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?
I think that depends on what aspects you need to be “better”. There is the generator in the secrets module, but outside of cryptography it might not be what you need.
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.”
Looks like there are lots of negative things associated with Twister. And this source mentions CryptMT. 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.
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.
The refactored NumPy random module was carefully designed with these concerns in mind. You might want take a look at the bit generator documentation. 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 repo, where the NumPy routines were originally laid out. You can also peruse issues and discussions around the PRNGs in Numpy, like here, here, here. 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).
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.
There are lots of negative things associated with every PRNG, and there
are lots of negative things associated with physical sources of
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:
I am the author of PEP 506 so I am very aware of the limitations of the Mersenne Twister against attack:
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?