Re: Conveniently generating random numbers with TR1 random
Walter E Brown wrote:
On 2007-11-03 11:10 PM, jkherciueh@gmx.net wrote:
> Andrei Alexandrescu (See Website For Email) wrote:
> Those do no longer exist. The corresponding forms would be:
>
> a) uniform_int_distribution<int>(a,b)(gen)
> b) uniform_int_distribution<int>(0,0)
> ( gen, uniform_int_distribution<int>::param_type(a,b) )
Yes, this is correct according to the latest Working Draft for C++0X.
>
> However, I think the intended way of using it is more like this:
>
> typedef uniform_int_distribution<int>::param_type range;
>
> uniform_int_distribution<int> u_int_d;
>
> c) u_int_d( gen, range(a,b) ); // reuse the same object!
Yes, this is the intended way to use this two-argument function call
operator. However, we believe that the single-argument function call
operator will be used far more often in most programs.
I have to admit that right now I'm thoroughly confused about param_type,
and actually poring through all of its occurrences in the draft C++0X
spec does not help. I applied the following procedure:
1. Search N2461 for "param_type"
2. Read the vicinity of every occurrence.
No avail whatsoever. (I am assuming that N2461 is self-contained;
otherwise, my point is moot.) Then I repeated the same procedure for
"param(", thinking that the homonym function is explained somewhere. I
did find an explanation in table 107 on page 855:
Expression: u(e)
Type: T
Pre-post condition:
With p = u.param(), the sequence amortized
of numbers returned by successive constant number
invocations with the same object e of invocations of
is randomly distributed according e
to the associated p(z | {p}) or
P(zi | {p}) function.
That's awfully little to go by in deducing what param_type and the
param() functions are about. I vaguely realise from having read past
documents that the parameter parameterizes the distribution, e.g. for a
Gaussian distribution the parameters would be \Sigma and \mu. Is that
correct? If so, then it's unclear to me where it says that an integral
distribution has one parameter that's its range. I looked all over
uniform_int_distribution, it just doesn't say a thing.
A second issue I discovered while thinking of the random numbers library
is that there's no generator called "random". There are various
generators whose names tell _how_ the job is done, yet none that says
_what_ job is being done and offers to readily take up the task.
This might seem silly, but I think it's not. Think of Joe Coder trying
to generate some random numbers. Joe happily pulls his just-installed
C++0X's documentation, looks up random numbers, and sure enough, there's
plenty of stuff to play with. The problem is that Joe does not know or
care much about how random numbers are generated, so names like
"linear_congruential_engine", "mersenne_twister_engine", or
"hole_in_the_ground" are all just the same to him; he just wants to get
work done. So Joe finds himself with an embarrassment of riches:
1. Should he use minstd_rand0?
2. minstd_rand perhaps? (That "0" didn't look that good anyway.)
3. The ungainly-named mt19937?
4. The Latin-sounding, luminous and optimistic ranlux* variety? (Fiat Lux!)
..
10. Templatize the whole thing with the generator type and toss the
choice point elsewhere?
That's lots of choice, which is good if Joe's focus was Monte Carlo
simulation, hashing, cryptography, and the such, but really, all Joe is
trying here is to generate some plain vanilla random numbers.
So I suggest the standard library provides a typedef called "random" (or
"random_generator" etc.) for whatever the library implementation
believes is the most appropriate generator for the given platform. On
most platforms, probably:
typedef mt19937 random;
would do, and on a tight embedded system:
typedef minstd_rand random;
would be more appropriate.
Don't get me wrong in criticizing the library; by and large, I think
it's the best random number library design of all, by a mile. If I were
a random number, I'd think I died and went to heaven. Yet, I find it a
bit of a letdown that the new random library has all this great breadth
and depth, but in my humble opinion it hasn't really dotted the last
"i"s. Any complex library should be taken back to the simplest tasks
it's supposed to fulfill and checked if it makes them easy enough.
Andrei
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]