[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: Numpy binary wheels and CI for win/arm64 platform
On Mon, Jun 6, 2022 at 5:08 PM Niyas Sait wrote: > > When you say "we could request access to new Volterra machines": how do > > you see that playing out? Who would provide them, and who would maintain > > them? Would they be available to the more general scientific python > > community? Who would pay the bill? > > Microsoft, Qualcomm, and Arm are very interested in native support for > Numpy and other scientific packages for Windows on Arm platform. > And we have contacts with them to start the relevant discussion if there > is interest to use those dev boxes (local or remote access) > or Azure VMs for CI/CD purposes. > Hi Niyas, I'd be interested in remote access to a development machine. This will help with NumPy and SciPy; and it would allow testing binaries resulting from a cross-compilation step. I don't have a preference for a Volterra box or an Azure VM - as long as it can be used for development purposes the details of getting access are not that important I'd say. > > Hope that answers your questions. > > Niyas > > > > On Mon, 6 Jun 2022 at 14:51, Matti Picus wrote: > >> When you say "we could request access to new Volterra machines": how do >> you see that playing out? Who would provide them, and who would maintain >> them? Would they be available to the more general scientific python >> community? Who would pay the bill? If the people supporting this niche >> platform stop doing so, can we drop the wheels? CPython has PEP 11 [0], >> maybe this effort should start by writing a similar NEP for the >> scientific python community. >> >> Matti >> >> >> [0] https://peps.python.org/pep-0011 >> >> >> On 6/6/22 13:35, Niyas Sait wrote: >> > Hello, >> > >> > It has been a while since we discussed adding CI/CD support for >> > Windows on Arm. Let me share a few updates and see if we can find a >> > way forward. >> > >> > First of all, Thanks for suggesting cibuildwheel. We have couple of >> > patches in progress to add native [1] and cross-compilation support >> > [2] to cibuildwheel. They could solve the binary wheel creation and >> > releases. However, we may still lack support for CI. >> > >> > I would like to check if there is any interest in using Windows/Arm64 >> > VMs in Azure [3] or Volterra machines ( new Windows/Arm64 Dev Boxes ) >> > [4] to add CI support for WoA platform. >> > >> > In order to use Azure VMs with GitHub Actions or Azure Pipeline, we >> > must set up self-hosted runners. I am not sure if that would be an >> > acceptable workflow for the numpy community. If that could work we >> > could potentially find ways to fund the required VMs for NumPy project. >> > I don't think integration in the main NumPy CI is an option right now, however I also don't think it is necessary. A standalone daily or weekly scheduled job that would notify interested devs should already be very helpful. Cheers, Ralf > > >> > Also, we could request access to new Volterra machines for Numpy >> > CI/CD. I know it is not easy to maintain them as part of CI/CD >> > workflow, but if any maintainers are interested in using them for >> > CI/CD purposes, we can progress on that discussion. >> > >> > Let me know what you think. >> > >> > Thanks >> > Niyas >> > >> > [1] https://github.com/pypa/cibuildwheel/pull/920 >> > [2] https://github.com/pypa/cibuildwheel/pull/1108 >> > [3] >> > >> https://azure.microsoft.com/en-us/blog/now-in-preview-azure-virtual-machines-with-ampere-altra-armbased-processors/ >> > [4] >> > >> https://blogs.windows.com/windowsdeveloper/2022/05/24/create-next-generation-experiences-at-scale-with-windows/ >> ___ >> 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: niyas.s...@linaro.org >> > ___ > 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: ralf.gomm...@googlemail.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
