do CDF inversion methods have to be public?

@chrisb83, @mdhaber, @tirthasheshpatel I had completely missed the API changes to add NumericalInverseHermite and other public classes listed in http://scipy.github.io/devdocs/reference/stats.html#random-variate-generation-cdf-inversion. Was that discussed on the mailing list, and do these things have to be public?

My impression is that it’s a complex API that is quite unlike other APIs in scipy.stats. They take distribution objects that are not the regular stats distributions:

An instance of a class with pdf and dpdf methods.

It looks to me at first glance that this should be private infrastructure which supports improved RVS generation in the regular distribution classes?

[tirthasheshpatel]

For complicated pdf/cdf functions where you can’t just calculate these parameters analytically, it seems that would require drawing a lot of samples, estimating center and mode, and then feeding those back in. And then if you tweak domain, you have to remember to update these other params. Is that actually usable?

Most distributions are unimodal. One could use the optimize submodule to find the mode of the PDF (even for bounded/truncated distributions) in that case. In other cases, one could either analytically calculate the mode or give a value close to the actual mode (i.e. approximate the mode).

[chrisb83]

rvs_ratio_uniforms seems to be a problem as well, it does a very similar thing to NaiveRatioUniforms as far as I can tell from the docs - it should probably also be deprecated

Yes, NaiveRatioUniforms offers the same functionality as a special case using the common interface that Tirth implemented .We initially wanted to deprecate rvs_ratio_uniforms after adding NaiveRatioUniforms. We then decided to wait since the former is still faster (about 6x if I remember correctly). We can still deprecate it right away in my view. For a lot of distributions, NumericalInverseHermite or NumericalInversePolynomial offer faster alternatives.