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

From: John Maddock (john_at_[hidden])
Date: 2007-01-10 08:25:16

Markus Werle wrote:
>> 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"?

No game on anything intended.  And "skewness" gives the skewness of the 
distribution, "kurtosis" relates to how sharp the peek of the distribution 
is.  The problem is that there are two measures in common use: "kurtosis" 
and "kurtosis excess": the latter is the kurtosis less 3, and is defined so 
that the normal distribution has a kurtosis excess of 0.  The problem is 
compounded by the two terms often being used interchangeably :-(

In any event, I've found a mathematically precise definition, so I'll have a 
go at rewriting that.

>> 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 ;-))

Far too optimistic I fear, they have quite strict terms of use 
http://mathworld.wolfram.com/about/terms.html but also a bad publishing 
contract means that Wolfram and Eric Weisstein effectively no longer own 
their own work: http://mathworld.wolfram.com/about/erics_commentary.html

>>> 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.

Basically: any elliptic integral can be reduced to a linear combination of 
three (linearly independent) standard forms.  Various candidates for these 
forms have been proposed, but Legendre's E, F and Pi integrals are the first 
to be defined and most well known.  The Carlson forms are an alternative set 
of std forms, but there are others in the literature too.

I see your point about the definitions given not looking much like an 
elliptic integral: but they are entirely standard.

The process of converting an arbitrary elliptic intregral into std form is 
covered in some depth in A&S I believe.  You may also be able to find a 
symbolic maths package that will do it for you (though I admit I don't know 
of any).

>>> 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 :-(

I hear you, but I still think you're wrong :-)

I think at this stage we need more opinions and some real world usage before 
changing these names again - we're on about the third naming scheme 
already - after previous discussions here.

John.