Remove u64 support for Poisson

[dhardy]

• [ ] Added a CHANGELOG.md entry

Summary

Counter-proposal to #1516. Reverts part of #1498. Closes #1323 (doc change only).

Motivation

Where only Distribution<F> for F: Float is supported, Rust is reasonably good at inferring the intended sampling type. When Distribution<u64> is supported too, much more type annotation is needed which is annoying.

Also as noted in #1516, saturating to u64::MAX may not be appropriate in all use-cases.

[benjamin-lieser]

For Possion we have the garantie that it will not exceed u64::MAX, we should document that and encourage people to cast it to an integer.

For Zipf we should have the same garantie, because it takes n : u64 and the samples should be <=n. It is probably worth checking and potentially documenting if this can be violated due to rounding errors.

[dhardy]

garantie

Is it a guarantee for Poisson or "just" P(event) <= 1e-1000? Though by some definitions I can see that being sufficient.

What would the equivalent limit be for u32::MAX?

[benjamin-lieser]

garantie

Is it a guarantee for Poisson or "just" P(event) <= 1e-1000? Though by some definitions I can see that being sufficient.

What would the equivalent limit be for u32::MAX?

It is more than 1e6 standard deviations away, so it is actually more like at least 1e-1000000. My guess is that you can prove it is actually impossible with f64 but I have not tried it. In any case there is no way that a saturation could effect any real application. It is dramatically more likely that any computer running it will be hit by a meteor during the calculation than actually saturating on u64

If you take 4.2e9 as limit, you get 4.2e9 + 1465 * sqrt(4.2e9) < 2**32 Even though there are just 1465 standard deviations it is still less likely than the meteor.

I found a way to calculate the probabilities: For the first it is 10 ^(-5e11) For the second it is 10 ^(-1e6)