Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add strategy for numpy.random.Generator #3510

Closed
wants to merge 12 commits into from
Closed

Add strategy for numpy.random.Generator #3510

wants to merge 12 commits into from

Conversation

rsokl
Copy link
Contributor

@rsokl rsokl commented Nov 19, 2022

Partially addressing #3131 (only a year later...), this adds hypothesis.extra.rand_generators for generating numpy.random.Generator instances with Hypothesis-controlled seeds. These have specialized reprs that enable reproducibility. This bumps our minimum supported version of NumPy to 1.19.01. 1.19.0 has already dropped out of the NEP 29 support window, so I do not think that this is an unreasonable dependency bump.

>>> from hypothesis.extra.numpy import rand_generators
>>> [rand_generators().example() for _ in range(3)]
[Generator(PCG64(17731618377865219412)),
Generator(PCG64(16938332804403789103)),
Generator(PCG64(9641801721570554589))]

>>> from numpy.random import MT19937, PCG64
>>> # specifying multiple backing bit-generator types
>>> [rand_generators(MT19937, PCG64).example() for _ in range(3)]
[Generator(PCG64(1138900339423482065)),
Generator(MT19937(13796052070681794055)),
Generator(MT19937(16637614687104877655))]

Once #3509 is merged, I can add numpy.random.Generator support for register_random (I figured out how to make the compatibility shim work)

Footnotes

  1. When BitGenerator was added to the NumPy's public API

@rsokl rsokl added the enhancement it's not broken, but we want it to be better label Nov 19, 2022
@rsokl rsokl changed the title Add strategy for numpy.random.Generators Add strategy for numpy.random.Generator Nov 19, 2022
@Zac-HD
Copy link
Member

Zac-HD commented Nov 20, 2022

Just dumping thoughts here:

  • if we're bumping the Numpy version, let's make sure that using something too old is an explicit error - and link to NEP-29. We could in principle support older versions of Numpy in everything but RNG; I don't think it's worth it
  • I think we should probably replicate the st.randoms(*, note_method_calls=False, use_true_random=False) interface. This is going to be pretty annoying, but IMO it's a pretty useful feature for shrinking and therefore debuggability. Unfortunately since the default is to draw from Hypothesis instead we can't backfill that in a future PR without changing behavior...
  • Relatedly, we could easily drop in a HypothesisBitGenerator() shim; this might be a good first pass at the above. Long-term I think we want a HypothesisGenerator class so that generated sizes, floats, etc. shrink as we'd want them to.

I realize that this amounts to asking for substantial extra work, sorry! Happy to try to find a workable subset if it's too much.

Finally, when you say "partially addressing", what will be left after this PR? It'd be nice to have a checklist, or perhaps close the issue and open a newer and more-specific one 😁

@Zac-HD
Copy link
Member

Zac-HD commented Apr 24, 2023

Closing this as stale 😥

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement it's not broken, but we want it to be better
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants