Re: [boost] Review Request: Statistical Distributions and Mathematical Special Functions

From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2007-01-10 04:37:30

John Maddock <john <at> johnmaddock.co.uk> writes:

> > In the docs sometimes you have formulations like e.g.
> > "Returns the cubed root of x.". For native speakers this may be no
> > problem,
> > but sqrt(x)^3 may be easier to catch for the rest of us.
> 
> That would be x^(1/3) 

Unintenden "Quod erat demonstrantum"

> I've just added that.

Fine.

> > Also I dislike: "The definition used here is that used by Wolfram
> > MathWorld" since by this the docs are neither self-contained nor
> > robust against
> 
> Hmmm, that section could be better phrased,
> 
> Looks like we need a concise definition of "kertosis", 

The “kertosis” is a measure of skewness for distributions - right?
So is this a game on words for "distribution"?

> but there are limits 
> to how much we can rewrite what's already very well explained elsewhere.

Could we ask Wolfram for permission to include the stuff?
At the same time they could switch to boost license for the docs ...
(yes, I can be optimistic, too ;-))
 
> > Citing papers is OK, but it takes a few thousand dollars to get them
> > all I guess. So adding an outline of the algorithm would be nice for
> > all functions (though saying what you use is GoodStuff(TM), too).
> 
> The special functions all have an "implementation" section that should 
> provide that (or at least a formula).  However, there are some papers that 
> are just too complex to summarise (the methods used to obtain the initial 
> approximations for the inverse incomplete gamma and beta functions are good 
> examples of this).

I see.

> > I see no connection between \Int R(t, s) dt and the definitions F, E
> > and \Pi so here again the docs are a little bit confusing and the
> > information about gamma function definitions and what Legendre found
> > out will not enter my brain without further information from other
> > sources which I find odd.
> 
> Now I'm confused: 

No, I am. This was an error due to removed text.
I wanted to talk about elliptic integrals here.
I had difficulties with chapter "Definition" below "Elliptic Integrals"
Looking at this part of the docs my sentence above makes more sense.

> > What I also dislike is the existence of default typedefs for double
> I'd be interested in other views on this: my gut feeling is that hardly any 
> users of the statistics code will be using anything except double precision. 

... until 128 bit platforms are widely available at the supermarket in 2009?

> The convenience of being able to write:
> 
> quantile(students_t(10), .95);  // 95% quantile for 10 degrees freedom
> 
> is well worth it IMO.  The alternative:
> 
> quantile(students_t_distribution<double>(10), .95);

I'd still vote for 

  quantile(students_t<double>(10), .95);

or 

  quantile(students_t_distr<double>(10), .95);

which is not much more pain
or a typedef in the user's code (which makes it easy to adopt
to future requirements, where I change the typedef, not all of my code):

  typedef students_t_distribution<double> students_t;
  ...
  quantile(students_t(10), .95);
 
> is unnecessarily verbose in comparison.  It's like writing:
> 
> std::string
> rather than:
> std::basic_string<char>

And yet std::string should have never made it into the standard.
That beast is a counter example of cute design.
We now have std::string and std::wstring and someday std::wwstring?
This convention has no symmetry and I dislike it, too.
It takes a lot of headache to get my code switched to unicode
since all of it is polluted with the default 95% solution :-(

Markus