Conveniently generating random numbers with TR1 random - c++

Andrei Alexandrescu (See Website For Email) ha scritto:
>
> minstd_rand gen;
> uniform_int<char> dist1('0', '9');
> uniform_int<unsigned> dist2(1, 1023);
> char digit = dist1(gen);
> unsigned length = dist2(gen);
>
> The problem with this is that it's way verbose and requires one object
> per range.

You can write the same code like this:

minstd_rand gen;
char digit = uniform_int<char>('0', '9')(gen);
unsigned length = uniform_int<unsigned>(1, 1023)(gen);

The presence of the generator is a Good Thing(tm), otherwise you would
need some static generator instance and you would completely lose the
gift of re-entrancy. So if the generator stays, I can't think of any
construct significantly less verbose than that. The creation of the
temporary object should not bother you so much. I have seen at least one
optimizing compiler doing a wonderful job on this code snippet.

> So I'm asking whether there's an easy and simple way to generate
> integral numbers within the TR1 framework. Did I overlook something? If
> not, it would be great if a convenience type or function was present in
> C++0X.

You might think about something like

template <class Type, class Rng>
Type generate_uniform_int(Type a, Type b, Rng& gen)
{
return uniform_int<Type>(a, b)(gen);
}

but I see little value over the example I have shown above: all you gain
is the possible automatic deduction of Type. I frankly prefer specifying
Type explicitly as I usually do, for example, even with std::min/max.

HTH,

Ganesh

---
[ 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 ]

Alberto Ganesh Barbati wrote:
> Andrei Alexandrescu (See Website For Email) ha scritto:
>> minstd_rand gen;
>> uniform_int<char> dist1('0', '9');
>> uniform_int<unsigned> dist2(1, 1023);
>> char digit = dist1(gen);
>> unsigned length = dist2(gen);
>>
>> The problem with this is that it's way verbose and requires one object
>> per range.
>
> You can write the same code like this:
>
> minstd_rand gen;
> char digit = uniform_int<char>('0', '9')(gen);
> unsigned length = uniform_int<unsigned>(1, 1023)(gen);
>
> The presence of the generator is a Good Thing(tm), otherwise you would
> need some static generator instance and you would completely lose the
> gift of re-entrancy. So if the generator stays, I can't think of any
> construct significantly less verbose than that. The creation of the
> temporary object should not bother you so much. I have seen at least one
> optimizing compiler doing a wonderful job on this code snippet.

Clearly the generator has to be in the picture.

But let's say the creation of the temporary object is not bothersome. In
that case, definitely the existence of the odd function
operator()(Generator&, SomeInt) _is_ bothersome! I mean, how come your
nice argument does not apply to using uniform_int for random_shuffle?
Either way you look at it, there is some redundancy.

>> So I'm asking whether there's an easy and simple way to generate
>> integral numbers within the TR1 framework. Did I overlook something? If
>> not, it would be great if a convenience type or function was present in
>> C++0X.
>
> You might think about something like
>
> template <class Type, class Rng>
> Type generate_uniform_int(Type a, Type b, Rng& gen)
> {
> return uniform_int<Type>(a, b)(gen);
> }
>
> but I see little value over the example I have shown above: all you gain
> is the possible automatic deduction of Type. I frankly prefer specifying
> Type explicitly as I usually do, for example, even with std::min/max.

Well I'd like it too, if there was a compelling argument in its favor. I
don't see one. So far, using the standard library does not necessitate
explicit type specification, and I don't see a need for the random
number generator to start a new trend.

Truth be told, with "auto" things will get a tad more palatable:

auto digit = uniform_int<char>('0', '9')(gen);

At least I can enjoy some weird Puritan satisfaction that I only
specified that I traffic in "char" three times instead of four.


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 ]

Andrei Alexandrescu (See Website For Email) ha scritto:
> Alberto Ganesh Barbati wrote:
>> Andrei Alexandrescu (See Website For Email) ha scritto:
>>> minstd_rand gen;
>>> uniform_int<char> dist1('0', '9');
>>> uniform_int<unsigned> dist2(1, 1023);
>>> char digit = dist1(gen);
>>> unsigned length = dist2(gen);
>>>
>>> The problem with this is that it's way verbose and requires one object
>>> per range.
>>
>> You can write the same code like this:
>>
>> minstd_rand gen;
>> char digit = uniform_int<char>('0', '9')(gen);
>> unsigned length = uniform_int<unsigned>(1, 1023)(gen);
>>
>> The presence of the generator is a Good Thing(tm), otherwise you would
>> need some static generator instance and you would completely lose the
>> gift of re-entrancy. So if the generator stays, I can't think of any
>> construct significantly less verbose than that. The creation of the
>> temporary object should not bother you so much. I have seen at least one
>> optimizing compiler doing a wonderful job on this code snippet.
>
> Clearly the generator has to be in the picture.
>
> But let's say the creation of the temporary object is not bothersome. In
> that case, definitely the existence of the odd function
> operator()(Generator&, SomeInt) _is_ bothersome! I mean, how come your
> nice argument does not apply to using uniform_int for random_shuffle?
> Either way you look at it, there is some redundancy.

I don't get your point. What does operator()(Generator&, SomeInt) matter
with the "The problem with this is that it's way verbose and requires
one object per range" issue?

By the way, I just had a look at the latest draft N2461 and things have
changed quite a bit from your references. For example the
variate_generator template does not exist anymore so the description of
operator()(g,p) no longer has a reference to it. On a side note,
uniform_int is now named uniform_int_distribution.

>>> So I'm asking whether there's an easy and simple way to generate
>>> integral numbers within the TR1 framework. Did I overlook something? If
>>> not, it would be great if a convenience type or function was present in
>>> C++0X.
>>
>> You might think about something like
>>
>> template <class Type, class Rng>
>> Type generate_uniform_int(Type a, Type b, Rng& gen)
>> {
>> return uniform_int<Type>(a, b)(gen);
>> }
>>
>> but I see little value over the example I have shown above: all you gain
>> is the possible automatic deduction of Type. I frankly prefer specifying
>> Type explicitly as I usually do, for example, even with std::min/max.
>
> Well I'd like it too, if there was a compelling argument in its favor.
> don't see one. So far, using the standard library does not necessitate
> explicit type specification, and I don't see a need for the random
> number generator to start a new trend.

I apologize, English is not my mother language. I don't understand what
is "it" in the sentence "I'd like it too" (I did not say that I like
generate_uniform_int, in fact I don't). The rest of the sentence is also
quite obscure to me. Could you please rephrase?

> Truth be told, with "auto" things will get a tad more palatable:
>
> auto digit = uniform_int<char>('0', '9')(gen);
>
> At least I can enjoy some weird Puritan satisfaction that I only
> specified that I traffic in "char" three times instead of four.

If you say so... I usually prefer having the type of variable clearly
shown, especially when I know it and the name is short as in this case.

Cheers,

Ganesh

---
[ 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 ]

On 2007-10-29 1:00 PM, Andrei Alexandrescu (See Website For Email) wrote:
> Hello,
>
> I've studied Jens Maurer's TR1 random numbers
> (http://www.open-std.org/jtc1/sc22/wg...003/n1452.html).
> Very nicely done! I have a question-comment.

Thank you. My colleagues at Fermilab and I collaborated with Jens at
the time he was preparing this proposal. As another poster in this
thread has pointed out, this portion of the standard library has
undergone substantial evolution and refinement since the early TR1
version to which you refer above.

Because your "question-comment" concerns itself with certain details of
what we consider a superseded version, I have snipped it from this posting.

I would respectfully recommend that, at your convenience, you look at
section [rand] (26.4) of committee paper N2461, the latest Working Draft
for C++0X, published just this week. You might also want to review the
latest description of the random-shuffle algorithm in section
[alg.random.shuffle] (25.2.12).

For some rationale and background regarding the changes since the TR1
version, you may want to have a look at some subset of the following
papers, listed in (roughly) reverse chronological order; as best I can
tell, this is the complete set of papers (over the five-year time span
2002 to date) related to this part of C++0X:

N2424 "Recommendations for Resolving the 2007-09-21 Issues re [rand]"

N2423 "Recommendations for Resolving Issues re [rand], version 2"
N2391 "Recommendations for Resolving Issues re [rand]"

N2111 "Random Number Generation in C++0X: A Comprehensive Proposal,
version 4"
N2079 "Random Number Generation in C++0X: A Comprehensive Proposal,
version 3"
N2032 "Random Number Generation in C++0X: A Comprehensive Proposal,
version 2"
N1932 "Random Number Generation in C++0X: A Comprehensive Proposal"

N2033 "Proposal to Consolidate the Subtract-with-Carry Engines"
N1933 "Improvements to TR1's Facility for Random Number Generation"

N1914 "A Proposal to Add Random-Number Distributions to C++0X
N1588 "On Random-Number Distributions for C++0X"

N1452 "A Proposal to Add an Extensible Random Number Facility to the
Standard Library (Revision 2)"
N1398 "A Proposal to Add an Extensible Random Number Facility to the
Standard Library"

After you've had a chance to bring yourself up to date, we would be
pleased to have your further comments.

Best,

-- WEB

---
[ 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 ]

Alberto Ganesh Barbati wrote:
> I don't get your point. What does operator()(Generator&, SomeInt) matter
> with the "The problem with this is that it's way verbose and requires
> one object per range" issue?

It's very simple, really. The task is to generate an integral number in
the range [a, b]. I was saying there are two options:

a) Call uniform_int<int>(a, b)(gen)

b) Call a + uniform_int<int>(whatever, whatever)(gen, b + 1)

You say that (a) is a good option, efficiency-wise and all. Then I don't
understand why option (b) is in the picture. Why would people consume
interface real estate with a function that's not needed? The function
propagates up to variate_generator, so it's not an accident or an
oversight; there must be a reason.

> By the way, I just had a look at the latest draft N2461 and things have
> changed quite a bit from your references. For example the
> variate_generator template does not exist anymore so the description of
> operator()(g,p) no longer has a reference to it. On a side note,
> uniform_int is now named uniform_int_distribution.

I'm perusing:

http://www.open-std.org/jtc1/sc22/wg...2005/n1836.pdf

which does feature variate_generator and uniform_int. Then I searched
specifically for uniform_int_distribution and found:

http://www.open-std.org/jtc1/sc22/wg...2006/n2032.pdf

which indeed lacks the variate_generator and renames uniform_int to
uniform_int_distribution. I see with chagrin that the
operator()(UniformRandomNumberGenerator& urng, const param_type& parm)
is still there. I don't understand why. The nice thing is that the
function is constrained to a specific integral type param_type.

>>>> So I'm asking whether there's an easy and simple way to generate
>>>> integral numbers within the TR1 framework. Did I overlook something? If
>>>> not, it would be great if a convenience type or function was present in
>>>> C++0X.
>>> You might think about something like
>>>
>>> template <class Type, class Rng>
>>> Type generate_uniform_int(Type a, Type b, Rng& gen)
>>> {
>>> return uniform_int<Type>(a, b)(gen);
>>> }
>>>
>>> but I see little value over the example I have shown above: all you gain
>>> is the possible automatic deduction of Type. I frankly prefer specifying
>>> Type explicitly as I usually do, for example, even with std::min/max.
>> Well I'd like it too, if there was a compelling argument in its favor.
>> don't see one. So far, using the standard library does not necessitate
>> explicit type specification, and I don't see a need for the random
>> number generator to start a new trend.
>
> I apologize, English is not my mother language. I don't understand what
> is "it" in the sentence "I'd like it too" (I did not say that I like
> generate_uniform_int, in fact I don't). The rest of the sentence is also
> quite obscure to me. Could you please rephrase?

I meant: "I'd like to specify the type too, if there was a compelling
argument in favor of doing so".

>> Truth be told, with "auto" things will get a tad more palatable:
>>
>> auto digit = uniform_int<char>('0', '9')(gen);
>>
>> At least I can enjoy some weird Puritan satisfaction that I only
>> specified that I traffic in "char" three times instead of four.
>
> If you say so... I usually prefer having the type of variable clearly
> shown, especially when I know it and the name is short as in this case.

Experience with "auto" tends to suggest that omitting redundant type
names generally makes for more robust code. Lacking hard evidence, I
guess there's not much of a point I can make though ).


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 ]

Walter E Brown wrote:
> On 2007-10-29 1:00 PM, Andrei Alexandrescu (See Website For Email)
> wrote:
>> Hello,
>>
>> I've studied Jens Maurer's TR1 random numbers
>> (http://www.open-std.org/jtc1/sc22/wg...003/n1452.html).
>> Very nicely done! I have a question-comment.
>
> Thank you. My colleagues at Fermilab and I collaborated with Jens at
> the time he was preparing this proposal. As another poster in this
> thread has pointed out, this portion of the standard library has
> undergone substantial evolution and refinement since the early TR1
> version to which you refer above.
>
> Because your "question-comment" concerns itself with certain details
> of what we consider a superseded version, I have snipped it from this
> posting.
>
> I would respectfully recommend that, at your convenience, you look at
> section [rand] (26.4) of committee paper N2461, the latest Working
> Draft for C++0X, published just this week. You might also want to
> review the latest description of the random-shuffle algorithm in
> section [alg.random.shuffle] (25.2.12).

Thanks for the flowery language ). An URL would have been equally
appreciated. Are you, for example, referring to the N2461 available from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007 ?

[snip]
> After you've had a chance to bring yourself up to date, we would be
> pleased to have your further comments.

While I'm thoroughly impressed by you walking me through the mentioned
bibliography, if what I wanted was to absorb all of the minutiae of the
random numbers, probably I wouldn't even have written here. What I was
hoping was a simple answer to a simple question from someone who already
knows that information. Sure if someone asked me a simple question about
machine learning I wouldn't send her to read everything from Vapnik's
1974 paper onward.


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 ]

On 2007-10-31 12:30 PM, Andrei Alexandrescu (See Website For Email) wrote:
> Walter E Brown wrote:
>> On 2007-10-29 1:00 PM, Andrei Alexandrescu (See Website For Email)
>> wrote:
>>> Hello,
>>>
>>> I've studied Jens Maurer's TR1 random numbers
>>> (http://www.open-std.org/jtc1/sc22/wg...003/n1452.html).
>>> Very nicely done! I have a question-comment.
>>
>> Thank you. My colleagues at Fermilab and I collaborated with Jens at
>> the time he was preparing this proposal. As another poster in this
>> thread has pointed out, this portion of the standard library has
>> undergone substantial evolution and refinement since the early TR1
>> version to which you refer above.
>>
>> Because your "question-comment" concerns itself with certain details
>> of what we consider a superseded version, I have snipped it from this
>> posting.
>>
>> I would respectfully recommend that, at your convenience, you look at
>> section [rand] (26.4) of committee paper N2461, the latest Working
>> Draft for C++0X, published just this week. You might also want to
>> review the latest description of the random-shuffle algorithm in
>> section [alg.random.shuffle] (25.2.12).
>
> Thanks for the flowery language ). An URL would have been equally
> appreciated. Are you, for example, referring to the N2461 available from
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007 ?

Sorry if the language seemed "flowery"; as a non-native speaker of
English, that's simply the way I normally speak and write, and
especially so when it's in a public forum.

Sorry again re the lack of URLs. I didn't bother with them because:
a) I didn't have enough of them handy;
b) the references were pasted from a document that I did have handy;
c) a previous poster in the same thread had already referenced N2461;
d) since you are a recognized C++ expert, I assumed that you knew
where Committee documents were made publicly available.

For the record, yes, you seem to have found the correct N2461.

>
> [snip]
>> After you've had a chance to bring yourself up to date, we would be
>> pleased to have your further comments.
>
> While I'm thoroughly impressed by you walking me through the mentioned
> bibliography, if what I wanted was to absorb all of the minutiae of the
> random numbers, probably I wouldn't even have written here. What I was
> hoping was a simple answer to a simple question from someone who already
> knows that information. Sure if someone asked me a simple question about
> machine learning I wouldn't send her to read everything from Vapnik's
> 1974 paper onward.

No one here is or was trying to impress you; we were merely conveying
information. What I tried to convey in particular is that TR1's version
is no longer current, that many aspects of the random number facility
have been improved, and that your questions might be better answered if
phrased in terms of the interface now found in the Working Draft.

I see that you've separately now posted a question phrased in terms of
the intermediate document N2032, but I don't know why of all the
references I provided you would choose that one, clearly labeled
"version 2" and equally clearly succeeded by a "version 3" and a
"version 4".

More importantly, your question seems to misconstrue the nature of
"param_type" in the distributions. In particular, you wrote: "I see
with chagrin that the operator()(UniformRandomNumberGenerator& urng,
const param_type& parm) is still there. I don't understand why. The nice
thing is that the function is constrained to a specific integral type
param_type."

(1) I don't know why you believe that param_type is an integral type.
There's no such requirement.

(2) As stated in N1933, param_type and related functions "provide a
uniform interface so that distribution parameters can be manipulated
generically: it now becomes possible to write code that is independent
of any specific distribution."

And finally, let me see if I understand your basic concern about the
interface to a distribution. Is it that you believe that the member
templates of the following form are superfluous?
template<class URNG>
result_type
..._distribution:perator()(URNG&, param_type const &)
If so, please let me know and I will be very happy to address that
specific issue.

Best,

-- WEB

---
[ 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 ]

Walter E Brown wrote:
[snip]

Thanks for the excellent information.

> I see that you've separately now posted a question phrased in terms of
> the intermediate document N2032, but I don't know why of all the
> references I provided you would choose that one, clearly labeled
> "version 2" and equally clearly succeeded by a "version 3" and a
> "version 4".
>
> More importantly, your question seems to misconstrue the nature of
> "param_type" in the distributions. In particular, you wrote: "I see
> with chagrin that the operator()(UniformRandomNumberGenerator& urng,
> const param_type& parm) is still there. I don't understand why. The nice
> thing is that the function is constrained to a specific integral type
> param_type."
>
> (1) I don't know why you believe that param_type is an integral type.
> There's no such requirement.
>
> (2) As stated in N1933, param_type and related functions "provide a
> uniform interface so that distribution parameters can be manipulated
> generically: it now becomes possible to write code that is independent
> of any specific distribution."

Ok, I understand.

> And finally, let me see if I understand your basic concern about the
> interface to a distribution. Is it that you believe that the member
> templates of the following form are superfluous?
> template<class URNG>
> result_type
> ..._distribution:perator()(URNG&, param_type const &)
> If so, please let me know and I will be very happy to address that
> specific issue.

Yes, that's the root of my question. More specifically, I'm not sure
what method to use when generating integers in a range [a, b]. My
understanding is that I could go two routes:

a) Call uniform_int<int>(a, b)(gen)

b) Call a + uniform_int<int>(whatever, whatever)(gen, b + 1)

Why are there two ways, and what are the tradeoffs guiding the choice of
using one of them?


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 ]

Andrei Alexandrescu (See Website For Email) wrote:

> Walter E Brown wrote:
> [snip]
>
> Thanks for the excellent information.
>
>> I see that you've separately now posted a question phrased in terms of
>> the intermediate document N2032, but I don't know why of all the
>> references I provided you would choose that one, clearly labeled
>> "version 2" and equally clearly succeeded by a "version 3" and a
>> "version 4".
>>
>> More importantly, your question seems to misconstrue the nature of
>> "param_type" in the distributions. In particular, you wrote: "I see
>> with chagrin that the operator()(UniformRandomNumberGenerator& urng,
>> const param_type& parm) is still there. I don't understand why. The nice
>> thing is that the function is constrained to a specific integral type
>> param_type."
>>
>> (1) I don't know why you believe that param_type is an integral type.
>> There's no such requirement.
>>
>> (2) As stated in N1933, param_type and related functions "provide a
>> uniform interface so that distribution parameters can be manipulated
>> generically: it now becomes possible to write code that is independent
>> of any specific distribution."
>
> Ok, I understand.
>
>> And finally, let me see if I understand your basic concern about the
>> interface to a distribution. Is it that you believe that the member
>> templates of the following form are superfluous?
>> template<class URNG>
>> result_type
>> ..._distribution:perator()(URNG&, param_type const &)
>> If so, please let me know and I will be very happy to address that
>> specific issue.
>
> Yes, that's the root of my question.

One observation is that a distribution object can maintain its own buffer of
entropy. For instance, if you have a distribution that generates 8bit chars
and you call it with an engine that provides 32 random bits (via an
unsigned long), the your distribution object may have a little buffer for
later use, i.e., some calls

dist( urng )

may actually not call the RNG. One effect of (a) allowing the distribution
parameters to change and (b) having the meber

..._distribution:perator()(URNG&, param_type const &)

is that this pool of entropy can be reused. E.g., when you need to generate
random ints on smaller and smaller ranges, it could be wastefull to
construct a new distribution object ever time since you throw away random
bits.

> More specifically, I'm not sure
> what method to use when generating integers in a range [a, b]. My
> understanding is that I could go two routes:
>
> a) Call uniform_int<int>(a, b)(gen)
>
> b) Call a + uniform_int<int>(whatever, whatever)(gen, b + 1)
>
> Why are there two ways, and what are the tradeoffs guiding the choice of
> using one of them?

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>:aram_type(a,b) )

However, It think the intended way of using it is more like this:

typedef uniform_int_distribution<int>:aram_type range;

uniform_int_distribution<int> u_int_d;

c) u_int_d( gen, range(a,b) ); // reuse the same object!


Best

Kai-Uwe Bux

---
[ 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 ]