Currently the iterator statistics trait is treated as a special case since to act over the iterator the methods need to take a mutable reference, so all the traits from statrs::statistics are (going to be) combined in the IterStatistics trait that is implemented for all Iterators. I haven't come up with a better solution but for some reason this implementation doesn't sit too well with me and I'd love to have someone review it and provide feedback.

I would like to bring to your attention the fact that your licensing is incompatible with your dependencies.

Your crate is MIT licensed but depends upon nalgebra which is Apache-2.0 licensed only. While Apache-2.0 projects can use MIT licensed components, the reverse is not so.

Consider for instance that MIT is GPL v3 compatible, while Apache-2.0 is not; Your crate being MIT licensed is thus misleading to any potential GPL-v3 projects that consider using your crate - they'd end up constructing a non-compliant product.

statrs's latest version is 0.14.0. (Even though the website says it is 0.13.0, in the README.md and the link to the docs in the "About" section at the top right.)

statrs 0.14.0 depends on nalgebra 0.26. nalgebra has a RUSTSEC-2021-0070 advisory against it. Among other things, this causes cargo deny to fail.

Version 0.27.1 of nalgebra fixes the advisory.

It would be very helpful if statrs could have its dependency on nalgebra updated to 0.27.1, and then a new version of statrs (0.14.1 or 0.15.0) be released. Thank you.

Hi and thanks for the library!

Problem

I think there's a bug in the implementation of the continuous uniform distribution. According to the documentation, it should return values in the range [min, max], i.e. min ≤ random value ≤ max.

Unfortunately, the current implementation generates values in the range [min, max + 1), i.e. min ≤ random value < max + 1.

I think it might be a copy-paste bug 'inherited' from the discrete uniform distribution, where you really need to add 1 to the upper bound.

Solution

This PR is a partial fix for this bug: It changes the range of the continuous uniform distribution to [min, max), i.e. min ≤ random value < max. I don't have a quick fix to include the upper bound, but I think it's important to at least fix the + 1.0 issue. As of 0.7.0, you cannot really sample values between 0 and 1 without resorting to wild workarounds.

References

• MathNET implementation
• discrete uniform distribution in statrs
• rand::Rng trait, which says that gen_range() does not include the upper bound

Hello! This is a (hopefully) polite request to check if statrs is in a state ready to have a release cut? It's been 10mo according to crates.io and I for one am eager to get off rand 0.7. Thanks again for all your hard work!

This branch is not fit for merging (see below), but I wanted to gauge interest in having this functionality in statrs.

Issues with the implementation in this branch:

• [ ] Ignores location and scale parameters (they're assumed to be 0 and 1 respectively)
• [x] Pulls in "special" and "approx" as deps
• [x] No CheckedInverseCDF impl
• [ ] 400 lines of unit tests is a bit much
• [ ] Docs don't describe the formula

Currently the responsibility for guarding against exceptional cases (e.g. input not in valid domain, mathematically invalid operations etc) is passed to the user. We panic when an operation does not make mathematical sense (e.g. calculating the cumulative distribution function for discrete distributions at a negative input) which forces users to double check to make sure their inputs are valid. While this results in technically correct and predictable behavior from the API, I'm not sure if it's ergonomic or idiomatic and have been mulling over possibly introducing a Result based API either replacing or in addition to the stricter panic based API. This however warrants some discussion and I would love feedback from the community

Currently, statrs relies on rand 0.7 and nalgebra 0.23 (which itself relies on rand 0.7). The newer releases of nalgebra update their dependency to the latest rand, which is currently 0.8.3. One of the minor, but frustrating, differences between 0.7 and 0.8 is a change in the syntax of the rand_range function, from taking 2 arguments to taking a single range argument.

It would be great if statrs could be updated to rely on a newer nalgebra and a newer statrs. Currently, if one is depending on rand >= 0.8 (or is depending on any package that depends on this), then multiple different versions of rand are pulled down. Not only does this bloat the build, but it can run the risk of confusing the compiler about definitions that appear in both versions of the package.

The actual changes to conform with the new API interface of rnd_range are small, but I think there are some other changes that would need to be made, since the version of nalgebra should be bumped (but perhaps not to the very latest (0.26.1), unless other changes are made because they have deprecated some interfaces that are currently used in statrs).

I just saw this in the code:

    #[ignore]
    #[test]
    fn test_mean_variance_stability() {
        // TODO: Implement tests. Depends on Mersenne Twister RNG implementation.
        // Currently hesistant to bring extra dependency just for test
    }

You can add dependencies to the Cargo.toml that are only used when running the tests, but not when using the library as a dependency: http://doc.crates.io/specifying-dependencies.html#development-dependencies

The code below understandably runs into a type mismatch as the argument mean of statsrs::distribution::Normal requires a f64.

Similar to np.random.normal in Python's numpy package, it would be good to add support for Vector arguments of mean in statsrs.

Rust code (doesn't work due to type mismatch in let n...)

let x0: Vec<f64> = thread_rng().sample_iter(Standard).take(200).collect();

let endpoint_mean: Vec<_> = x0
  .iter()
  .map(|&x| x * (-0.5).exp())
  .collect();

let endpoint_variance: f64 =
  (SIGMA.pow(2) as f64 /  (1.0 - (-1.0).exp())).sqrt();

// this should output a vector n of some arbitrary length (here, 200). the argument endpoint_mean could be a Vec<f64> (as per numpy), but currently must be f64.
let n = Normal::new(endpoint_mean, endpoint_variance).unwrap();

Python code (works with an array of floats)

x0 = np.random.normal(loc = 0, scale = 1, size = 10000) // initial points, outputs a 10_000 vector
mean = X0*np.exp(-0.5) // 10_000 vector 
variance = np.sqrt(4/(1-np.exp(-1)) // = 1.5901201952413002
xt = np.random.normal(m,v) // = 10_000 vector

Removed also the tests which instantiated gamma with infinity as a parameter. Tests are still failing, but don't know what the motivation is behind those numbers. If it doesn't matter too much I'll just update the testvalues.

Hello, I'm studying the possibility of using this crate for Markov Chain Monte Carlo (MCMC) based inference. In this use case, the log-density of a distribution is evaluated repeatedly at different parameter values. To do that currently, the crate requires re-creating the distributions at each iteration. This isn't much of a problem for scalar distributions, but for the multivariate normal, I have to re-allocate the mean vector and covariance matrix at each iteration (since distributions are immutable), which impacts performance.

Allowing the user to re-set the parameters separately would work:

pub fn set_mean(&mut self, mu : &[f64]);
pub fn set_variance(&mut self, var : &[f64]);

But a solution that moves the parameters out of the struct would also work (therefore preserving the intended immutable API):

pub fn take_parameters(self) -> (DVector<f64>, DMatrix<f64>);

Are there any plans to offer something like that?

Multivariate Normal CDF

Implements the multivariate normal CDF

Algorithm

Uses the algorithm as explained in Section 4.2.2 in Computation of Multivariate Normal and t Probabilities by Alan Genz and Frank Bretz, together with the cholesky decomposition with dynamic changing of rows explained in Section 4.1.3. Specifically we use a Quasi Monte Carlo method.

Additions

• Trait ContinuousMultivariateCDF in mod.rs
• Module MultivariateUniform in multivariate_uniform.rs (mainly for me wanting an in-house way to get uniform distribution in $[0,1]^n$). Implements mean, mode, pdf, cdf, min, max, ln_pdf.
• Function chol_chrows for computing the Cholesky decomposition dynamically whilst changing rows for better integration limits
• Function integrate_pdf to integrate a multivariate pdf between limits a and b
• Implement ContinuousMultivariateCDF for MultivariateNormal (and MultivariateUniform), where cdf uses integrate_pdf with left limit a=[f64::NEG_INFINITY; dim] and right limit x=b
• Tests cdf against scipy.stats.multivariate_normal.cdf in python, as well as MvNormalCDF in Julia
• Import crate primes for generating first $n$ primes as Richtmyer generators in the Quasi MC algorithm

Implementation of Multivariate students t distribution in a very similar way to Multivariate normal. Includes sampling, mean, covariance, mode, pdf and log pdf functions.

Testing with exact values from python scipy.stats.multivariate_t functions. Large degrees of freedoms does not work yet

With this crate, is it possible to calculate the coefficient of variation / relative std dev (data.std_dev()/data.mean()) without calculating the mean twice?

First, of all, thanks for making and maintaining this project. I'm trying to make a wasm project and I would have probably given up without statrs.

Anyway, I'm always confused by the many synonyms used in statistics. This PR suggests to add one synonym to the inverse_cdf to the docstring of the normal distribution. This should make it at least visible when searching the docs?

Adding the note to all inverse_cdf implementations seems a bit redundant so that's why I kept it to the Normal for now.