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

Quickcheck Arbitrary support? #241

Closed
Hoverbear opened this issue Nov 19, 2016 · 9 comments
Closed

Quickcheck Arbitrary support? #241

Hoverbear opened this issue Nov 19, 2016 · 9 comments

Comments

@Hoverbear
Copy link

Would there be interest in supporting (perhaps via a feature) the Quickcheck Arbitrary trait?

An example:

impl Arbitrary for BigUint {
  fn arbitrary<G: Gen>(g: &mut G) -> Self {
    BigUnit::new(g.gen::<Vec<u32>>())
}

Reasoning:

  • As a user I would like to be able to generate arbitrary values for use in quickcheck! {} based tests.
  • It is not possible to implement Arbitrary on BigUint, for example, since it it part of a different crate.

I would be interested in working on this PR but I want to make sure it would be welcome.

@cuviper
Copy link
Member

cuviper commented Nov 19, 2016 via email

@Hoverbear
Copy link
Author

That was the plan. :)

One question I had about some semantics, when say generating some arbitrary BigUint, what should the range be? Taking a Vec<u32> which is like 4000 elements might be a bit over the top.

@cuviper
Copy link
Member

cuviper commented Nov 20, 2016

I guess that depends how it will be used. A bigint that long is not inherently unreasonable, but could certainly be slow for some scenarios. I'll leave that to your discretion for now. :-)

@Hoverbear
Copy link
Author

What about atoms in the observable universe? 4*10^81?

@cuviper
Copy link
Member

cuviper commented Nov 20, 2016

Is it kosher to put arbitrary limits on Arbitrary? ;)

I would just leave it with whatever Vec<u32> does by default, unless you have a use case that shows this to be unmanageable. If you have such a case, then cut it down according to that.

We could invent scenarios where almost any bigint would hurt, like some exponential algorithm. So we have to be a bit pragmatic according to how it will actually be used.

@Hoverbear
Copy link
Author

Suppose you're right. :) It's hardly arbitrary if we limit it.

@remexre
Copy link

remexre commented May 17, 2017

@Hoverbear Are you still working on this? If not, I'd like to.

@Hoverbear
Copy link
Author

@remexre It fell of my plate! If you'd like to take it over please feel free.

remexre pushed a commit to remexre/num that referenced this issue Jun 1, 2017
I'd love to `impl<T: Into<String>> From<T> for Value` and probably also
`impl<T: Iterator<Item=I>, I: Into<Value> From<T> for Value`. Maybe with
specialization?

Fixes rust-num#241
@cuviper cuviper closed this as completed Dec 19, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants