On the random module python page (Link Here) there is this warning:
Warning: The pseudo-random generators of this module should not be used for security purposes. Use os.urandom() or SystemRandom if you
require a cryptographically secure pseudo-random number generator.
So whats the difference between os.urandom() and random?
Is one closer to a true random than the other?
Would the secure random be overkill in non-cryptographic instances?
Are there any other random modules in python?
You can read up on the distinction of cryptographically secure RNG in this fantastic answer over at Crypto.SE.
The main distinction between random and the system RNG like urandom is one of use cases. random implements deterministic PRNGs. There are scenarios where you want exactly those. For instance when you have an algorithm with a random element which you want to test, and you need those tests to be repeatable. In that case you want a deterministic PRNG which you can seed.
urandom on the other hand cannot be seeded and draws its source of entropy from many unpredictable sources, making it more random.
True random is something else yet and you'd need a physical source of randomness like something that measures atomic decay; that is truly random in the physical sense, but usually overkill for most applications.
So whats the difference between os.urandom() and random?
Random itself is predicable. That means that given the same seed the sequence of numbers generated by random is the same. Take a look at this question for a better explanation. This question also illustrates than random isn't really random.
This is generally the case for most programming languages - the generation of random numbers is not truly random. You can use these numbers when
cryptographic security is not a concern or if you want the same pattern of numbers to be generated.
Is one closer to a true random than the other?
Not sure how to answer this question because truly random numbers cannot be generated. Take a look at this article or this question for more information.
Since random generates a repeatable pattern I would say that os.urandom() is certainly more "random"
Would the secure random be overkill in non-cryptographic instances?
I wrote the following functions and there doesn't appear to be a huge time difference. However, if you don't need cryptographically secure numbers
it doesn't really make sense to use os.urandom(). Again it comes down to the use case, do you want a repeatable pattern, how "random" do you want your numbers, etc?
import time
import os
import random
def generate_random_numbers(x):
start = time.time()
random_numbers = []
for _ in range(x):
random_numbers.append(random.randrange(1,10,1))
end = time.time()
print(end - start)
def generate_secure_randoms(x):
start = time.time()
random_numbers = []
for _ in range(x):
random_numbers.append(os.urandom(1))
end = time.time()
print(end - start)
generate_random_numbers(10000)
generate_secure_randoms(10000)
Results:
0.016040563583374023
0.013456106185913086
Are there any other random modules in python?
Python 3.6 introduces the new secrets module
random implements a pseudo random number generator. Knowing the algorithm and the parameters we can predict the generated sequence. At the end of the text is a possible implementation of a linear pseudo random generator in Python, that shows the generator can be a simple linear function.
os.urandom uses system entropy sources to have better random generation. Entropy sources are something that we cannot predict, like asynchronous events. For instance the frequency that we hit the keyboard keys cannot be predicted.
Interrupts from other devices can also be unpredictable.
In the random module there is a class: SystemRandom which uses os.urandom() to generate random numbers.
Actually, it cannot be proven if a given sequence is Random or NOT. Andrey Kolmogorov work this out extensively around 1960s.
One can think that a sequence is random when the rules to obtain the sequence, in any given language, are larger than the sequence itself. Take for instance the following sequence, which seems random:
264338327950288419716939937510
However we can represent it also as:
pi digits 21 to 50
Since we found a way to represent the sequence smaller than the sequence itself, the sequence is not random. We could even think of a more compact language to represent it, say:
pi[21,50]
or yet another.
But the smaller rules, in the most compact language (or the smaller algorithm, if you will), to generate the sequence may never be found, even if it exists.
This finding depends only on human intelligence which is not absolute.
There might be a definitive way to prove if a sequence is random, but we will only know it when someone finds it. Or maybe there is no way to prove if randomness even exists.
An implementation of a LCG (Linear congruent generator) in Python can be:
from datetime import datetime
class LCG:
defaultSeed = 0
defaultMultiplier = 1664525
defaultIncrement = 1013904223
defaultModulus = 0x100000000
def __init__(self, seed, a, c, m):
self._x0 = seed #seed
self._a = a #multiplier
self._c = c #increment
self._m = m #modulus
#classmethod
def lcg(cls, seed = None):
if seed is None: seed = cls.defaultSeed
return LCG(int(seed), cls.defaultMultiplier,
cls.defaultIncrement, cls.defaultModulus)
#pre: bound > 0
#returns: pseudo random integer in [0, bound[
def randint(self, bound):
self._x0 = (self._a * self._x0 + self._c) % self._m
return int(abs(self._x0 % bound))
#generate a sequence of 20 digits
rnd = LCG.lcg(datetime.now().timestamp()) #diff seed every time
for i in range(20):
print(rnd.randint(10), end='')
print()
Related
I am using two different methods of trying to generate a bootstrap sample
np.random.seed(335)
y=np.random.normal(0,1,5)
b=np.empty(len(y)) #initializes an empty vector
for j in range(len(y)):
a = np.random.randint(1,len(y)) #Draws a random integer from 1 to n, where n is our sample size
b[j] = y[a-1] #indicies in python start at zero, the worst part of Python in my opinion
c = np.random.choice(y, size=5)
print(b)
print(c)
and for my output I get different results
[1.04749432 1.71963433 1.71963433 1.71963433 1.71963433]
[-0.25224454 -0.25224454 0.46604474 1.71963433 0.46604474]
I think the answer has something to do with the random number generator, but I'm confused as to the exact reason.
This comes down to the use of different algorithms for randomized selection. There are numerous equivalent ways to select items at random with replacement using a pseudorandom generator (or to generate random variates from any other distribution). In particular, the algorithm for numpy.random.choice need not make use of numpy.random.randint in theory. What matters is that these equivalent ways should produce the same distribution of random variates. In the case of NumPy, look at NumPy's source code.
Another, less important, reason for different results is that the two different selection procedures (randint and choice) produce pseudorandom numbers themselves, which can differ from each other because the selection procedures didn't begin with the same seed (more precisely, the same sequence of pseudorandom numbers). If we set the seed to the same value before beginning each procedure:
np.random.seed(335)
y=np.random.normal(0,1,5)
b=np.empty(len(y))
np.random.seed(999999) # Seed selection procedure 1
for j in range(len(y)):
a = np.random.randint(1,len(y))
b[j] = y[a-1]
np.random.seed(999999) # Seed selection procedure 2
c = np.random.choice(y, size=5)
print(b)
print(c)
then each procedure will begin with the same pseudorandom numbers. But even so, the two procedures may use different algorithms for random selection, and these differences may still lead to different results.
(However, numpy.random.* functions, such as randint and choice, have become legacy functions as of NumPy 1.17, and their algorithms are expected to remain as they are for backward compatibility reasons. That version didn't deprecate any numpy.random.* functions, however, so they are still available for the time being. See also this question. In newer applications you should make use of the new system introduced in version 1.17, including numpy.random.Generator, if you have that version or later. One advantage of the new system is that the application relies less on global state.)
What is the difference in
a = numpy.random.RandomState(1)
b = a.rand()
compared to
b = numpy.random.rand()
I'm not really sure if this has to do with seeding, and I'm new to the concept of seeding. If this is a case of seeding could somebody explain how the RandomState method does that, and maybe any tips on when it's useful to seed. Thank you.
The first sentence (a = numpy.random.RandomState(1)) start the pseudo random seed, in your case 1. That means that, no mater how many times you run the script, always get the same "random" number.
In the second case (b = numpy.random.rand()), the seed is predefined, you don't know what seed was used. So, every time you run a script, you obtain the next pseudo random of the unknown seed.
I'm still pretty new to programming and just learning how to unittest. I need to test a function that returns a random value. I've so far found answers suggesting the use of a specific seed value so that the 'random' sequence is constant and can be compared. This is what I've got so far:
This is the function I want to test:
import random
def roll():
'''Returns a random number in the range 1 to 6, inclusive.'''
return random.randint(1, 6)
And this is my unittest:
class Tests(unittest.TestCase):
def test_random_roll(self):
random.seed(900)
seq = random.randint(1, 6)
self.assertEqual(roll(), seq)
How do I set the corresponding seed value for the PRNG in the function so that it can be tested without writing it into the function itself? Or is this completely the wrong way to go about testing a random number generator?
Thanks
The other answers are correct as far as they go. Here I'm answering the deeper question of how to test a random number generator:
Your provided function is not really a random number generator, as its entire implementation depends on a provided random number generator. In other words, you are trusting that Python provides you with a sensible random generator. For most purposes, this is a good thing to do. If you are writing cryptographic primitives, you might want to do something else, and at that point you would want some really robust test strategies (but they will never be enough).
Testing a function returns a specific sequence of numbers tells you virtually nothing about the correctness of your function in terms of "producing random numbers". A predefined sequence of numbers is the opposite of a random sequence.
So, what do you actually want to test? For 'roll' function, I think you'd like to test:
That given 'enough' rolls it produces all the numbers between 1 and 6, preferably in 'approximately' equal proportions.
That it doesn't produce anything else.
The problem with 1. is that your function is defined to be a random sequence, so there is always a non-zero chance that any hard limits you put in to define 'enough' or 'approximately equal' will occasionally fail. You could do some calculations to pick some limits that would make sure your test is unlikely to fail more than e.g. 1 in a billion times, or you could slap a random.seed() call that will mean it will never fail if it passes once (unless the underlying implementation from Python changes).
Item 2. could be 'tested' more easily - generate some large 'N' number of items, check that all are within expected outcome.
For all of this, however, I'd ask what value the unit tests actually are. You literally cannot write a test to check whether something is 'random' or not. To see whether the function has a reasonable source of randomness and uses it correctly, tests are useless - you have to inspect the code. Once you have done that, it's clear that your function is correct (providing Python provides a decent random number generator).
In short, this is one of those cases where unit tests provide extremely little value. I would probably just write one test (item 2 above), and leave it at that.
By seeding the prng with a known seed, you know which sequence it will produce, so you can test for this sequence:
class Tests(unittest.TestCase):
def test_random_roll(self):
random.seed(900)
self.assertEqual(roll(), 6)
self.assertEqual(roll(), 2)
self.assertEqual(roll(), 5)
Is there any way to find out what seed Python used to seed its random number generator?
I know I can specify my own seed, but I'm quite happy with Python managing it. But, I do want to know what seed it used, so that if I like the results I'm getting in a particular run, I could reproduce that run later. If I had the seed that was used then I could.
If the answer is I can't, then what's the best way to generate a seed myself? I want them to always be different from run to run---I just want to know what was used.
UPDATE: yes, I mean random.random()! mistake... [title updated]
It is not possible to get the automatic seed back out from the generator. I normally generate seeds like this:
seed = random.randrange(sys.maxsize)
rng = random.Random(seed)
print("Seed was:", seed)
This way it is time-based, so each time you run the script (manually) it will be different, but if you are using multiple generators they won't have the same seed simply because they were created almost simultaneously.
The state of the random number generator isn't always simply a seed. For example, a secure PRNG typically has an entropy buffer, which is a larger block of data.
You can, however, save and restore the entire state of the randon number generator, so you can reproduce its results later on:
import random
old_state = random.getstate()
print random.random()
random.setstate(old_state)
print random.random()
# You can also restore the state into your own instance of the PRNG, to avoid
# thread-safety issues from using the default, global instance.
prng = random.Random()
prng.setstate(old_state)
print prng.random()
The results of getstate can, of course, be pickled if you want to save it persistently.
http://docs.python.org/library/random.html#random.getstate
You can subclass the random.Random, rewrite the seed() method the same way python does (v3.5 in this example) but storing seed value in a variable before calling super():
import random
class Random(random.Random):
def seed(self, a=None, version=2):
from os import urandom as _urandom
from hashlib import sha512 as _sha512
if a is None:
try:
# Seed with enough bytes to span the 19937 bit
# state space for the Mersenne Twister
a = int.from_bytes(_urandom(2500), 'big')
except NotImplementedError:
import time
a = int(time.time() * 256) # use fractional seconds
if version == 2:
if isinstance(a, (str, bytes, bytearray)):
if isinstance(a, str):
a = a.encode()
a += _sha512(a).digest()
a = int.from_bytes(a, 'big')
self._current_seed = a
super().seed(a)
def get_seed(self):
return self._current_seed
If you test it, a first random value generated with a new seed and a second value generated using the same seed (with the get_seed() method we created) will be equal:
>>> rnd1 = Random()
>>> seed = rnd1.get_seed()
>>> v1 = rnd1.randint(1, 0x260)
>>> rnd2 = Random(seed)
>>> v2 = rnd2.randint(1, 0x260)
>>> v1 == v2
True
If you store/copy the huge seed value and try using it in another session the value generated will be exactly the same.
Since no one mentioned that usually the best random sample you could get in any programming language is generated through the operating system I have to provide the following code:
random_data = os.urandom(8)
seed = int.from_bytes(random_data, byteorder="big")
this is cryptographically secure.
Source: https://www.quora.com/What-is-the-best-way-to-generate-random-seeds-in-python
with a value 8 it seems to produce around the same number of digits as sys.maxsize for me.
>>> int.from_bytes(os.urandom(8), byteorder="big")
17520563261454622261
>>> sys.maxsize
9223372036854775807
>>>
If you "set" the seed using random.seed(None), the randomizer is automatically seeded as a function the system time. However, you can't access this value, as you observed. What I do when I want to randomize but still know the seed is this:
tim = datetime.datetime.now()
randseed = tim.hour*10000+tim.minute*100+tim.second
random.seed(randseed)
note: the reason I prefer this to using time.time() as proposed by #Abdallah is because this way the randseed is human-readable and immediately understandable, which often has big benefits. Date components and even microsegments could also be added as needed.
I wanted to do the same thing but I could not get the seed. So, I thought since the seed is generated from time. I created my seed using the system time and used it as a seed so now I know which seed was used.
SEED = int(time.time())
random.seed(SEED)
The seed is an internal variable in the random package which is used to create the next random number. When a new number is requested, the seed is updated, too.
I would simple use 0 as a seed if you want to be sure to have the same random numbers every time, or make i configurable.
CorelDraw once had a random pattern generator, which was initialized with a seed. Patterns varied drastically for different seeds, so the seed was important configuration information of the pattern. It should be part of the config options for your runs.
EDIT: As noted by ephemient, the internal state of a random number generator may be more complex than the seed, depending on its implementation.
This is not a coding question, but am hoping that someone has come across this in the forums here. I am using Python to run some simulations. I need to run many replications using different random number seeds. I have two questions:
Are negative numbers okay as seeds?
Should I keep some distance in the seeds?
Currently I am using random.org to create 50 numbers between -100000 and +100000, which I use as seeds. Is this okay?
Thanks.
Quoting random.seed([x]):
Optional argument x can be any hashable object.
Both positive and negative numbers are hashable, and many other objects besides.
>>> hash(42)
42
>>> hash(-42)
-42
>>> hash("hello")
-1267296259
>>> hash(("hello", "world"))
759311865
Is it important that your simulations are repeatable? The canonical way to seed a RNG is by using the current system time, and indeed this is random's default behaviour:
random.seed([x])
Initialize the basic random number generator. Optional argument x can be
any hashable object. If x is omitted
or None, current system time is used;
current system time is also used to
initialize the generator when the
module is first imported.
I would only deviate from this behaviour if repeatability is important. If it is important, then your random.org seeds are a reasonable solution.
Should I keep some distance in the seeds?
No. For a good quality RNG, the choice of seed will not affect the quality of the output. A set of seeds [1,2,3,4,5,6,7,8,9,10] should result in the same quality of randomness as any random selection of 10 ints. But even if a selection of random uniformly-distributed seeds were desirable, maintaining some distance would break that distribution.