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 back a way to put a bound on numbers generated #267
Comments
Would this bring back Previously the |
The intent is to add back methods yes. But I'm not making rand a public dependency. However, this issue is about something different. This is a configuration knob on Gen itself. If you would like more methods on Gen, please file new issues with the desired method signatures. |
As far as I can tell, making existing private methods on But will do! |
It does expose rand. Their type signatures include things from the rand crate. |
Looking through upgrading to 1.0, and this would be great to have. Presumably it would be possible to accept |
quickcheck seems severely limited without |
You don't need gen_bool. Arbitrary::bool should work just fine. It would probably be good to add gen_range, but it doesn't seem particularly difficult to use modulus instead. |
And once again, this issue is unrelated to adding helper methods in Gen. This is about bounding values generated by Arbitrary impls for number types. |
We now have dependabot, but as there are several outdated packages, I thought I upgrade the simple ones once more manually. `quickcheck` (and `rand`) are likely not upgraded until there is a good way to generate ranges (see BurntSushi/quickcheck#267 for more information). Also `parity-scale-codec` needs more work.
We now have dependabot, but as there are several outdated packages, I thought I upgrade the simple ones once more manually. `quickcheck` (and `rand`) are likely not upgraded until there is a good way to generate ranges (see BurntSushi/quickcheck#267 for more information). Also `parity-scale-codec` needs more work.
I also need this to update some of my code to quickcheck 1.0, specifically to generate floating point numbers in a specific range. |
Floating point values don't have such a convenient hack, unfortunately. |
The following obsolete dendencies remain: * quickcheck 0.9 (current: 1.0): Byztime's tests depend on some removed functionality (see BurntSushi/quickcheck#267) and I can't be bothered to deal with this right now. * rand 0.7 (current: 0.8): required by quickcheck 0.9. * aead 0.3 (current: 0.4): required by aes_siv 0.5.
Modulus breaks shrinking. QuickCheck shrinks the generated number, but your number after As an example, the values generated in this manner look like this in failures:
The actual failing case, after shrinking, would be either Modulus is completely wrong for this purpose. |
@adam-becker I don't know what you're talking about. I was of course referring to the implementation of Lines 732 to 768 in defde6f
|
What is the status of this issue? The number of issues from other projects referencing this one is a clear sign people want this resolved. P.S. A quick check (no pun intended) shows at least one project implemented this functionality on top of QuickCheck, libp2p/rust-libp2p#2857, https://github.com/libp2p/rust-libp2p/blob/master/misc/quickcheck-ext/src/lib.rs. However, I am not sure their implementation is sound when shrinking, and it only works for unsigned numbers. |
It turns out that the tests inside byteorder were designed around the ability to control the bounds of integers generated and there is no easy way to adapt them to quickcheck 1.0 without this ability. I think we can just add a
bound
mutator onGen
that is by default not set.The text was updated successfully, but these errors were encountered: