Skip to content

Conversation

TheIronBorn
Copy link
Contributor

@TheIronBorn TheIronBorn commented Dec 11, 2018

fixes #661

@vks
Copy link
Collaborator

vks commented Dec 11, 2018

Should we add the test case from #661?

@dhardy
Copy link
Member

dhardy commented Dec 11, 2018

@vks how? That test case re-implements the algorithm over a u8 RNG. Our code already has explicitly different behaviour for u16 and u32 types and testing all possible inputs for a u32 is way beyond the scope of CI testing.

@vks
Copy link
Collaborator

vks commented Dec 11, 2018

@dhardy We could make factor (range << range.leading_zeros()).wrapping_sub(1) into its own function (i.e. approximate_zone) and add the test case for the function. Not sure whether this is worth it, but it at least documents clearly why the wrapping_sub is necessary.

@TheIronBorn
Copy link
Contributor Author

Something like StepRng might work except for the u8 as u32 optimization and knowing when to stop.

@dhardy
Copy link
Member

dhardy commented Dec 12, 2018

knowing when to stop

Depends on $ty::MAX and the range, so I don't see any general option good enough to be a useful test.

I would just go with this PR, except maybe to say we subtract 1 because we are using inclusive bounds not exclusive upper bound.

@dhardy dhardy merged commit 033c253 into rust-random:master Dec 14, 2018
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.

UniformInt::sample_single leading zeros approximation is biased
3 participants