Re: [Boost-users] [random]: several issues

Subject: Re: [Boost-users] [random]: several issues
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-09-25 11:53:47

AMDG

Thomas Mang wrote:
> I am not up-to-date with the proposals of C++0x. Will the random 
> library become (conceptually)  like a part of C++0x ?

Yes.

> I am in general not familiar with the details of all the numerical 
> algorithms of drawing random numbers, but I fully agree that the draws 
> should be certainly efficient and used whenever applicable. Just keep 
> in mind there is a major difference of going through the numerical 
> calculation of the inverse cdf once you got a [0,1) input, or if you 
> get a [0,1) input and then use any algorithm you like to convert that 
> into the random draw. You seem to address the former, while I am more 
> addressing the later, that is a common interface for the input to get 
> a random draw.
>
> One way I could think of an integration - from a pure design point of 
> view - is to specify a nested classes within the distribution class 
> (like fisher_f_distribution<>::random) that kind of substitutes the 
> distributions in the random library. There could be two nested classes 
> actually, one that does sort of work as variate_generator, and one 
> that accepts a [0,1) number as raw input. If there is an efficient 
> algorithm for the distribution, use it. If not, go through the inverse 
> cdf. And yeah of course invokation shall be able with both the 
> generators of the random library (in which case all the information 
> about the range of the random draws can be used, at compile-time 
> occasionally even), or a general generator which provides the 
> information of the bounds (either at run-time or compile-time) and 
> finally a [0,1) draw gotten from whereever else, but with an assert of 
> course that this precondition was held.
> This approach should not only also ease the integration of random 
> draws for which the random library is not set up yet (inverse cdf, for 
> example. I prefer a slightly less efficient implementation over none 
> at all), but also to have a shared interface for additional 
> distributions not yet in math.distributions (like mulitvariate normal, 
> von-mises etc).

I think it would be better to keep random distributions somewhat 
decoupled, using
something like random_distribution<fisher_f_distribution<> >.

> Is there any interest in helping out regarding that, or develop these 
> ideas further (if you know there is none, no changes will be accepted, 
> I  can safe time thinking of that further...) ?

Some work has already been done on this in the sandbox:
https://svn.boost.org/trac/boost/browser/sandbox/statistics/dist_random

In Christ,
Steven Watanabe