Warn people away from this package

[johnmyleswhite]

We keep having people who believe this package is meant to be used by end-users and therefore are surprised it's not documented.

[ararslan]

I would probably change "and should never use this package under any circumstances" to simply "instead."

[simonster]

The "Basic Functions" are not accessible through Distributions but still potentially useful. OTOH, many of them are one liners.

[ararslan]

I believe @andreasnoack was saying that we should eventually just merge this into Distributions rather than having it as its own package.

While I think that's a good longer-term goal, currently some packages use StatsFuns as a medium for interfacing with the Rmath functions. Hopefully Rmath itself will eventually be phased out.

[simonster]

The "Basic Functions" (xlogy, logistic, softmax, etc.) are potentially useful, but don't really make sense in Distributions (and many of them are not used there at all). If this package is not meant to be used by end users, we should either delete them and tell users to implement them themselves, or split this package into one that is meant to be used by end users and one that isn't.

[ararslan]

We could put the useful things in StatsBase and the Distributions-specific stuff in Distributions.

[simonster]

StatsBase sounds like a decent place to me.

[andreasnoack]

@simonster We could move such functions to StatsBase. Mainly, I would like to avoid that people use the pdf,cdf functions here.

[ararslan]

What about all of the constants we define here, like invπ and the like? Do those make sense in StatsBase as well? To me those seem like things people could just implement themselves as needed; I've honestly never quite understood why we have them.

[tpapp]

I think there is a niche in the package ecosystem for implementing seemingly trivial one liners, some of which are nevertheless hard to get right, because of corner cases, numerical issues, or unfortunate combinations of the two. I learned this the hard way, isolating #22 took a good part of an afternoon. Also, while writing functions that do promotion and type stability right is not difficult in Julia, having a library which already took care of this safes effort.

Instead of warning users away from this package, I would suggest that it is renamed NumFuns or something similar, and becomes a repository of well-tested implementations for functions that fit the above description. Some of these are used in machine learning, some in statistics, some in science, so a more generic name would be better.

[andreasnoack]

I think we all agree that it is useful to have these functions somewhere in a package. It just shouldn't be StatsFuns. StatsBase seemed to be the consensus. Somebody just has to do it.

[tpapp]

So would a PR that just puts the contents of this library in StatsBase (in some organized manner) be useful? I could do it during the holidays.

[andreasnoack]

...and deprecating it here. Yes, that would be very useful.

[tpapp]

How would I deprecate it? Deprecate every exported function? Or are there facilities for deprecating an entire module?

[nalimilan]

Wait, don't we want people to use most of these functions from Distributions.jl instead?

[ararslan]

I thought we were going to divide the functions between StatsBase and Distributions as appropriate

[andreasnoack]

I think the view was that functions like logistic and xlogx (probably all of misc.jl) seem to fit better in StatsBase than Distributions. The Rmath related stuff should go into Distributions.

The exported functions herethat we move, say foo, should be changed to something like @deprecate foo(x) StatsBase.foo(x).

[nalimilan]

Maybe logistic, but I don't think we want to export all functions like nchisqinvlogccdf from StatsBase, right?

[andreasnoack]

Functions like nchisqinvlogccdf shouldn't be exported anywhere. If it is a useful function, it should be covered by the API in Distributions.

[andreasnoack]

Superseded by #85