-
-
Notifications
You must be signed in to change notification settings - Fork 437
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
Uniform<f32/f64> should honor high/low limits #476
Comments
…ues in the requested range. Resolves rust-random#476
Probably either rejection sampling or clamping will be needed... I'd rather see a complete solution for one particular problem (e.g. |
Just wanted to write the same. Good that you thought about this corner case! But I can see other users complaining about the performance drop in @dhardy It can be a simple function, but what do you think of some method to make rejection sampling extra simple (i.e. that allows users to not write the loop)? Not thought it through though... |
So something like |
I was thinking more in the direction of: pub trait Distribution<T> {
/* ... */
fn rejection_sample<R: Rng + ?Sized>(&self, rng: &mut R, min: T, max: T)
-> T where T: PartialOrd<T>;
}
let val = Uniform::new(low, high).rejection_sample(&mut rng, low, high); Hmmm, doesn't look great. Maybe some iterator adapter: let val = Uniform::new(low, high).sample_iter(&mut rng).accept_if(|x| x >= low && x < high); Also ugly. And does the same as: let val = Uniform::new(low, high).sample_iter(&mut rng).filter(|x| x >= low && x < high).next(); |
Yes, a new method on Not sure if it's worth it, but it could be an unobtrusive layer on top of the current |
…ues in the requested range. Resolves rust-random#476
…ues in the requested range. Resolves rust-random#476
…ues in the requested range. Resolves rust-random#476
Make Uniform<f32/f64> and gen_range<f32/f64> honor limits strictly. Resolves #476
…ues in the requested range. Resolves rust-random#476
We should require that all
Uniform
distributions stick to thehigh
/low
limits, even in the face of rounding issues. Users are likely to see unexpected and hard-to-reproduce bugs if the returned value on rare occasions will be outside of the specified limits.One example that I ran into was while implementing
choose_weighted
for dhardy#82. If the generated number can be slightly higher thanhigh
, that means that we risk iterating through the whole item-set without selecting any item to return.The simplest approach is to simply check the generated value against high/low and loop if it doesn't fit withing the desired boundaries. However that runs into problem when
scale
rounds to infinity, since then we'll just loop forever.Looking into some alternative approaches instead.
The text was updated successfully, but these errors were encountered: