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

Arbitrary f32 and f64's should include special values #27

Closed
danburkert opened this issue Sep 21, 2014 · 6 comments
Closed

Arbitrary f32 and f64's should include special values #27

danburkert opened this issue Sep 21, 2014 · 6 comments

Comments

@danburkert
Copy link
Contributor

Currently INFINITY, NEG_INFINITY, NAN and possibly -0.0 are never generated by quickcheck. These values are valid floats, and should be tested for.

@ghost
Copy link

ghost commented Oct 15, 2014

I agree, this would be nice to have.

For what it's worth, Haskell's QuickCheck generates none of those values for its Arbitrary Float and Arbitrary Double instances (as of version 2.7.6).

@BurntSushi
Copy link
Owner

Does anyone know why Haskell's QuickCheck doesn't generate those special values?

@huonw
Copy link
Contributor

huonw commented May 11, 2015

Including subnormals might be good too.

@bekh6ex
Copy link
Contributor

bekh6ex commented Sep 17, 2017

Related problem: f64 and f32 values are always in range between -100 and 100

quickcheck! {
    fn float_range(n: f64) -> bool {
        n < 100.0 && n > -100.0
    }
}

This test never fails.

quickcheck version = 0.4.2

@bekh6ex
Copy link
Contributor

bekh6ex commented Sep 26, 2017

Regarding Haskell's quickcheck and floats here is related discussion:
nick8325/quickcheck#98

@KamilaBorowska
Copy link

However for Float, the NaN values are problematic since they violate the typeclass laws.

Doesn't sound like an issue for Rust, just saying, due to PartialEq and Eq being separate.

BurntSushi pushed a commit that referenced this issue Dec 27, 2020
This commit tweaks the Arbitrary impls of number types (integers,
floats) to use the full range with a small bias toward "problem" values.
This is a change from prior behavior that would use the `size` parameter
to control the range of integers.

In retrospect, using the `size` parameter this way was probably
misguided. Instead, it should only be used to control the sizes of data
structures instead of also constraining numeric ranges. By constraining
numeric ranges, we leave out a huge space of values that are never
tested.

Fixes #27, Fixes #119, Fixes #190, Fixes #233, Closes #240
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

No branches or pull requests

5 participants