Future of distributions in rand

[vks]

When working with distributions it is very useful to have access to their density, their distribution function and their quantile function in addition to being able to sample from them. Furthermore, it is nice to be able to calculate their (theoretical, exact) moments. I think it makes sense to have all this functionality in a common interface.

This is implemented in the statrs crate. There is some overlap with rand, sampling is implemented there as well, but for a lot more distributions.

I see the following options:

1. Only implement sampling in rand. Port the missing distributions from statrs to rand.
2. Also implement the theoretical properties of the distributions mentioned above in rand, essentially duplicating statrs.
3. Remove the distributions from rand and suggest to use statrs instead.

What do you think?

[dhardy]

Very good question. I don't know; potentially I'm open to big changes (post 0.5).

Statrs focusses on f64 despite using a generic T in the Distribution trait; this probably means at least Range and Uniform should remain in rand.

The Distribution trait in statrs is identical to ours (aside from R: Rng+?Sized addition), so it doesn't make much sense to have both (after 0.5 introduces our Distribution trait). I don't think it makes sense to remove this or basic uniform sampling from rand so statrs could simply re-export our trait later (unfortunately meaning it can't reach 1.0 before rand does).

The other distributions we have (exponential, normal, gamma) do feel out-of-place in rand so potentially we could remove those. I'm embarrassed to say I wasn't aware of statrs until now.

One thing not clear about the statrs distributions is how precise the sampling is — e.g. is the Bernoulli distribution accurate for p < ε (but within the normal range of f64)?

I think we should also ask @boxtown what he thinks?

[dhardy]

I see the Bernoulli distribution in statrs simply wraps Binomial, and the latter has a simple O(n) implementation, in contrast to the rejection method used in @fizyk20's PR.

[boxtown]

I'm open to the idea of depending on rands Distribution trait. Although to be honest I don't see any issue with the duplication. I am of course open to PRs if there is a desire to move sampling code into Statrs. I'd be willing to tackle it myself if someone is willing to open issues, it might just take a little longer

[vks]

Statrs focusses on f64 despite using a generic T in the Distribution trait; this probably means at least Range and Uniform should remain in rand.

I think the main reason for this is simplicity. AFAIK, the sampling of f32 and integers is a desired feature. See statrs-dev/statrs#17.

The other distributions we have (exponential, normal, gamma) do feel out-of-place in rand so potentially we could remove those.

I agree, it makes sense to move them to statrs and advertise the create for generating floats. In the long term, the discrete distributions could be moved there as well.

I see the Bernoulli distribution in statrs simply wraps Binomial, and the latter has a simple O(n) implementation, in contrast to the rejection method used in @fizyk20's PR.

Yes, I think it makes sense to avoid duplicated work implementing the distributions, which is the main reason I brought up the issue.

[dhardy]

I labelled this low-priority mostly because it needs more planning and would probably be better to discuss after more distribution code has been implemented / optimised / reviewed, and also because it's beyond the scope of the next release, but this is an important topic to finalise before the 1.0 release.

[pitdicker]

Just my personal opinion. There are a few distributions I really want to keep/have in Rand:

• Some default distribution that all types can implement and that ties in with Rng::gen (Uniform).
• The Range distribution.
• Some way to get floats with high precision, including a range.
• A Bernoulli distribution, making use of the high precision float method to improve upon Rng::gen_bool.
• I have really started to like type Exp1 distribution. It is an easy way to improve the performance of code that would otherwise use rng.gen::<f64>().ln().
• The Alphanumeric distribution. It does not irreplaceable or perfect, but it is just a nice piece of functionality.

What I am not sure about is generating random numbers that fit some probability distribution. Because if have not used them myself, I can't care strongly whether they are part of Rand or not. Two not-so-strong reasons to have them in Rand (or a clear companion crate to point to):

• Generating values in those distributions is a big randomness-related topic. A lot of the literature is about this area, it seems much more to me than there is about RNGs.
• Sometimes using some distribution is just the right tool for the job. Simulations / statistical problems are not the only uses. It is nice to have them easily available.

On the other hand, stats-rs is certainly going beyond what rand should provide (in my opinion), and no doubt provides a more complete and useful library for some area's. And it is taking it's inspiration from a good source 😄.

I think it is best to keep generating values according to some distribution in Rand. For simple use cases people can just use Rand. Then it would be nice if stats-rs would use these implementations (work together on improving them), and we would link to stats-rs for the place to find more features.

[burdges]

It's sometimes useful if two projects do the same things from different perspectives, especially if those things involve tricky things like presenting mathematics well.