3 ms·
The problem with this is that most programmers don't need statistics on a regular enough basis. That's how things get into standard libraries: people need these
by awalton 12y ago
The problem with this is that most programmers don't need statistics on a regular enough basis. That's how things get into standard libraries: people need these things so regularly that there's no point in reimplementing them forever.
You really think we need stats functions in libc more than we need, say, properly written accelerated vector and matrix functions? Which do you think comes up more regularly in practice?
You're better off reimplementing these handful of functions in a BSD-licensed copy-lib and forgetting about it. None of these are particularly tricky to implement.
- jwmerrill 12y ago> The problem with this is that most programmers don't need statistics on a regular enough basis. Empirically, many language environments (think, e.g. scripting languages) don't have really easy access to all of these functions, but do have easy access to most of the rest of libm. The author is saying that if these were part of libm, then language implementers would include them in their respective standard libraries, and then people that care about stats (and many of us should care about stats!) could write good stats software in general purpose languages that we might have chosen for some independent reason. > You really think we need stats functions in libc more than we need, say, properly written accelerated vector and matrix functions? Can't we have both?
- thisrod 12y agoThe (dense) vector and matrix functions have lived in Lapack and BLAS for 40 years, longer than there has been a libc. Every serious language has a standard interface for them, and the issues discussed in the article haven't caused problems for decades.
- mjw 12y ago> The problem with this is that most programmers don't need statistics on a regular enough basis. That's how things get into standard libraries: people need these things so regularly that there's no point in reimplementing them forever. True, although I suspect there's probably a certain amount of historical accident to the set of functions included in math.h. There's a strong argument that some of these common 'special' functions are at least as fundamental to a variety of mathematical fields as (say) arc hyperbolic cosine, although admittedly it'd probably be hard to get clear consensus on exact which. I expect if you asked a variety of stats/ML geeks they might have other priorities to those given here -- e.g. I might request the digamma and trigamma functions (first and second derivatives of log gamma, useful for computing gradients in various Bayesian models) before asking for Bessel functions, say. It might also be sensible to prefer log-domain versions of some of the functions he suggests, since much practical computation with probabilities needs to happen in the log domain.
- Someone 12y ago"None of these are particularly tricky to implement." Almost every mathematical function is hard to implement, if you want an implementation that is correct and (about) as fast as possible. For example, see http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/math_toolkit/bessel/mbessel.html http://www.boost.org/doc/libs/1_55_0/libs/math/doc/html/math..., which explains how boost implements the Bessel functions. (By the way, I think boost math special functions is that 'BSD'-licensed library you are asking for)