[Numpy-discussion] Re: seed for new random number generator
On Tue, Jun 21, 2022 at 9:54 AM Pieter Eendebak wrote: > Hi Robert, > > Thanks for the information and the offer. My use case is development of > algorithms where I want to be able to test variations of the algorithm > while keeping the same (simulated or generated) data. Related to that are > example scripts part of the documentation that I want to always have the > same result. > > Creating a generator and passing that (someway or the other) is a good > approach, but it requires some refactoring of the code. Especially for > third-party code I would like to avoid this (to be honest, most external > code is still using the old numpy random number interface, so there we can > use the old style of setting the seed) > Ah, okay, so you're replacing the old global with a new global Generator instance in your own code as an easier transitional step. # global instance rng = np.random.default_rng() def seed_global_rng(seed=None): # Create the same type of BitGenerator with the given seed, and then copy its state over to the global. bg_cls = type(rng.bit_generator) bg = bg_cls(seed) rng.bit_generator.state = bg.state I do recommend moving to passing around a Generator when you can; even in the older system, we've always recommended passing around a RandomState instance. -- Robert Kern ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: seed for new random number generator
Hi Robert, Thanks for the information and the offer. My use case is development of algorithms where I want to be able to test variations of the algorithm while keeping the same (simulated or generated) data. Related to that are example scripts part of the documentation that I want to always have the same result. Creating a generator and passing that (someway or the other) is a good approach, but it requires some refactoring of the code. Especially for third-party code I would like to avoid this (to be honest, most external code is still using the old numpy random number interface, so there we can use the old style of setting the seed) With kind regards, Pieter Eendebak On Sun, Jun 19, 2022 at 5:36 PM Robert Kern wrote: > On Sun, Jun 19, 2022 at 9:37 AM Pieter Eendebak > wrote: > >> Hi everyone, >> >> The new numpy random interface (e.g. r=numpy.random.default_rng; >> r.random) is much faster than the old one (e.g. np.random.random). When >> converting code from the old style to the new style I miss having a way to >> set the seed of the RNG >> >> I tried: >> >> rng.bit_generator = np.random.PCG64(seed=42) # fails, with good error >> message >> rng.bit_generator.state['state']['state']=42 # has no effect, perhaps >> make this dict read-only? >> >> Is there a way to set the seed without creating a new RNG object? >> > > We generally recommend just creating a new Generator and passing that > around in almost all cases. Whenever that can possibly be made to work, > please do that. The use of np.random.seed() is usually a code smell > indicating that someone was working around the fact that there was just the > one global underneath np.random.random() et al. When you don't have the > constraint of a single global instance, it's almost always going to be > better to use multiple instances; you don't need that workaround anymore. > > There are ways to punch in a new BitGenerator into an existing Generator, > if you must, and also ways to punch in a state dict into the BitGenerator, > but these are largely for various meta-programming tasks like serialization > rather than day-to-day use of pseudorandom numbers. If you are converting > old code that happened to use np.random.seed(), it is almost certainly not > one of these tasks. > > If you want to describe your use case more specifically, I can give you > some more guidance on good patterns to replace it with the new system. > > -- > Robert Kern > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: pieter.eende...@gmail.com > ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: seed for new random number generator
On Sun, Jun 19, 2022 at 4:36 PM Robert Kern wrote: > On Sun, Jun 19, 2022 at 9:37 AM Pieter Eendebak > wrote: > >> Hi everyone, >> >> The new numpy random interface (e.g. r=numpy.random.default_rng; >> r.random) is much faster than the old one (e.g. np.random.random). When >> converting code from the old style to the new style I miss having a way to >> set the seed of the RNG >> >> I tried: >> >> rng.bit_generator = np.random.PCG64(seed=42) # fails, with good error >> message >> rng.bit_generator.state['state']['state']=42 # has no effect, perhaps >> make this dict read-only? >> >> Is there a way to set the seed without creating a new RNG object? >> > > We generally recommend just creating a new Generator and passing that > around in almost all cases. Whenever that can possibly be made to work, > please do that. The use of np.random.seed() is usually a code smell > indicating that someone was working around the fact that there was just the > one global underneath np.random.random() et al. When you don't have the > constraint of a single global instance, it's almost always going to be > better to use multiple instances; you don't need that workaround anymore. > > There are ways to punch in a new BitGenerator into an existing Generator, > if you must, and also ways to punch in a state dict into the BitGenerator, > but these are largely for various meta-programming tasks like serialization > rather than day-to-day use of pseudorandom numbers. If you are converting > old code that happened to use np.random.seed(), it is almost certainly not > one of these tasks. > > If you want to describe your use case more specifically, I can give you > some more guidance on good patterns to replace it with the new system. > > -- > Robert Kern > ___ > NumPy-Discussion mailing list -- numpy-discussion@python.org > To unsubscribe send an email to numpy-discussion-le...@python.org > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ > Member address: kevin.k.shepp...@gmail.com At some point we had a seed implementation on the BitGenerator. This was benchmarked against creating a fresh BitGenerator and there was no measurable performance gain to the seed() method over creating a fresh BitGenerator. If you want to reseed, the simplest method is to simply call default_rng again. import numpy as np SEED = 382193802183092174983 rg = np.random.default_rng(SEED) rg.standard_normal((1000,100)) # Do stuff rg = np.random.default_rng(SEED) rg.standard_normal((1000,100)) Kevin ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
[Numpy-discussion] Re: seed for new random number generator
On Sun, Jun 19, 2022 at 9:37 AM Pieter Eendebak wrote: > Hi everyone, > > The new numpy random interface (e.g. r=numpy.random.default_rng; r.random) > is much faster than the old one (e.g. np.random.random). When converting > code from the old style to the new style I miss having a way to set the > seed of the RNG > > I tried: > > rng.bit_generator = np.random.PCG64(seed=42) # fails, with good error > message > rng.bit_generator.state['state']['state']=42 # has no effect, perhaps make > this dict read-only? > > Is there a way to set the seed without creating a new RNG object? > We generally recommend just creating a new Generator and passing that around in almost all cases. Whenever that can possibly be made to work, please do that. The use of np.random.seed() is usually a code smell indicating that someone was working around the fact that there was just the one global underneath np.random.random() et al. When you don't have the constraint of a single global instance, it's almost always going to be better to use multiple instances; you don't need that workaround anymore. There are ways to punch in a new BitGenerator into an existing Generator, if you must, and also ways to punch in a state dict into the BitGenerator, but these are largely for various meta-programming tasks like serialization rather than day-to-day use of pseudorandom numbers. If you are converting old code that happened to use np.random.seed(), it is almost certainly not one of these tasks. If you want to describe your use case more specifically, I can give you some more guidance on good patterns to replace it with the new system. -- Robert Kern ___ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
