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

Use Poisson distribution to generate integers (not floats) #1497

Closed
nielsle opened this issue Sep 23, 2024 · 3 comments
Closed

Use Poisson distribution to generate integers (not floats) #1497

nielsle opened this issue Sep 23, 2024 · 3 comments
Labels
E-easy Participation: easy job

Comments

@nielsle
Copy link

nielsle commented Sep 23, 2024

Background

What is your motivation?

I would like to use simulate a stochastic process where the number of events in each time window follows a Poisson distribution.

let poisson = Poisson::new(lambda).unwrap();
for _step in 0..n_steps {
    let n_attempts: u64 = poisson.sample(&mut rand::thread_rng()));
    for _sub_step in 0..n_attempts {
        //do_stuff
    }
}

This code fails because the poisson.sample() distribution can only return a float

I can fix this by rounding off the float, but my code would be prettier if poisson.sample() could return an integer :-)

What type of application is this? (E.g. cryptography, game, numerical simulation)

Numerical simulation of a spin-system similar to the Ising model.

Feature request

Introduce a version of the Poisson distribution that implements Distribution<u64> or Distribution<i64>

See also https://rust-random.github.io/rand/src/rand_distr/poisson.rs.html#118-180

@dhardy
Copy link
Member

dhardy commented Sep 23, 2024

See also: #1220, 1093, #1323.

Supporting an additional type potentially breaks type inference, but I don't think this is a big concern (but this does require a breaking release).

I suggest that we support u64 and maybe u32. We should probably do a saturating-cast on overflow, though this is mostly a theoretical concern (unless λ is large). Want to make a PR? (Maybe for Zipf too.)

@dhardy dhardy added the E-easy Participation: easy job label Sep 23, 2024
@clarfonthey
Copy link
Contributor

Not to be too picky, but I figured I would point out the typo in the issue title, since "poison distribution" sounds a bit dangerous. :p

@dhardy dhardy changed the title Use Poison distribution to generate integers (not floats) Use Poisson distribution to generate integers (not floats) Sep 23, 2024
@benjamin-lieser
Copy link
Member

I suggest that we support u64 and maybe u32. We should probably do a saturating-cast on overflow, though this is mostly a theoretical concern (unless λ is large). Want to make a PR? (Maybe for Zipf too.)

In this case a big λ would lead to this sampling only u64::MAX, this should then probably be rejected in the constructor which is not really possible because for Distribution<f64> it works good enough.
Denying big λ completely would also solve #1312

I think we should implement only u64 and make sure we do not accept λ which will saturate this (except very extremely rare events)

dhardy pushed a commit that referenced this issue Oct 1, 2024
This addresses #1497 by adding
`Distribution<u64>`
It also solves #1312 by not
allowing `lambda` bigger than `1.844e19` (this also makes them always
fit into `u64`)
@dhardy dhardy closed this as completed Oct 1, 2024
benjamin-lieser added a commit to benjamin-lieser/rand that referenced this issue Feb 5, 2025
This addresses rust-random#1497 by adding
`Distribution<u64>`
It also solves rust-random#1312 by not
allowing `lambda` bigger than `1.844e19` (this also makes them always
fit into `u64`)
dhardy pushed a commit to rust-random/rand_distr that referenced this issue Feb 5, 2025
This addresses rust-random/rand#1497 by adding
`Distribution<u64>`
It also solves rust-random/rand#1312 by not
allowing `lambda` bigger than `1.844e19` (this also makes them always
fit into `u64`)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-easy Participation: easy job
Projects
None yet
Development

No branches or pull requests

4 participants