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 width to hypothesis.strategies.complex_numbers() #3559

Merged
merged 19 commits into from Feb 2, 2023

Conversation

felixdivo
Copy link
Contributor

Towards #3468

Copy link
Member

@honno honno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work!

I think I'm not sure on width here. Maybe component_width would bring greater clarity to what a width argument would be (in that case, the width of the real/imag components individually)... but I'm not sure on that, so would wait to see what others think.

hypothesis-python/RELEASE.rst Outdated Show resolved Hide resolved
@felixdivo
Copy link
Contributor Author

Maybe component_width would bring greater clarity to what a width argument would be

Valid point, I thought about that too. However, I figuered that sticking to the notation of numpy (and therby probably most other libraries that came after) is a good idea, to not confuse things.

felixdivo and others added 3 commits January 26, 2023 13:06
Co-authored-by: Matthew Barber <quitesimplymatt@gmail.com>
Co-authored-by: Matthew Barber <quitesimplymatt@gmail.com>
@felixdivo felixdivo marked this pull request as ready for review January 26, 2023 12:20
@felixdivo
Copy link
Contributor Author

That the correct widths are computed is already checked by the floats() tests, I'd say the current tests are therefore enough. But if not (there could be a bug in computing complex128 -> 2x float64): Where would I add a test for that/where is that tested for floats()?

Copy link
Member

@honno honno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That the correct widths are computed is already checked by the floats() tests, I'd say the current tests are therefore enough. But if not (there could be a bug in computing complex128 -> 2x float64): Where would I add a test for that/where is that tested for floats()?

So st.floats() looks to have a ton of tests for things like allow_infinity that we don't also repeat for st.complex_numbers() (i.e. in tests/cover/test_float_nastiness.py). With that in mind, yeah I think the only tests we really need are covering possibilities that can happen in specifically st.complex_numbers(). Feel free to take a stab (good start already), but I'll mull this over myself too.

Copy link
Member

@Zac-HD Zac-HD left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great - thanks Felix!

I merged in #3557 so we'd get them in the same release, and tweaked the changelog (since we're adding a new argument, it's a minor release). Since I'm about to go to bed, we'll auto-merge and release if CI passes 🚀

@Zac-HD Zac-HD enabled auto-merge February 2, 2023 10:06
@Zac-HD Zac-HD disabled auto-merge February 2, 2023 10:07
@Zac-HD Zac-HD enabled auto-merge February 2, 2023 10:09
@Zac-HD Zac-HD merged commit 02fa5b3 into HypothesisWorks:master Feb 2, 2023
@felixdivo
Copy link
Contributor Author

That's awesome!

@felixdivo felixdivo deleted the patch-add-width branch February 2, 2023 11:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants