
Boost : 
From: John Maddock (john_at_[hidden])
Date: 20070110 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk