Skip to content

Conversation

jagerman
Copy link
Contributor

Use the same nextafter approach from boost::compute::random::normal_distribution to eliminate the possibility of getting a draw equal to b, so that we really do produce [a,b) values, as currently documented (and desired).

Copied this assertion from boost::random::uniform_real_distribution.
Currently b::c::r::uniform_real_distribution can produce a variate equal
to the upper bound, which is wrong: it is supposed to (and claims to)
produce values in [LO,HI), not [LO,HI], but when the random unsigned
int draw equals UINT_MAX (or values close to it, with the rounding
introduced by RealType = float), we get the upper limit, HI.

This commit applies nextafter to the result to shift the result towards
LO by the smallest amount possible, which therefore ensures that our
maximum is now the largest representable value that is strictly less
than HI.

If we generate a value of LO (from a random uint of 0), we end up
calling nextafter(LO, LO), which equals LO, so this will indeed conform
to the [LO,HI) interval.
@jagerman jagerman changed the title Develop uniform_real_distribution: fix boundary so values are really [a,b) instead of [a,b] Apr 24, 2016
@jszuppe
Copy link
Contributor

jszuppe commented Apr 24, 2016

Just 15 minutes ago I pushed the same PR. Well without the assertion BOOST_ASSERT(a < b); but with additional test.

@jagerman
Copy link
Contributor Author

Yeah, I just noticed that. Closing this one.

@jagerman jagerman closed this Apr 24, 2016
@jszuppe
Copy link
Contributor

jszuppe commented Apr 24, 2016

I'll add the assert. It's a good idea.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.0009%) to 88.792% when pulling 81b826d on jagerman:develop into 48217d2 on boostorg:develop.

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.

3 participants