random_shuffle seed

[Peter Ammon]

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

Thanks,
-peter

[Victor Bazarov]

"Peter Ammon" <pe*********@rocketmail.com> wrote...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

Read about 'srand' function.

V

[Chris Theis]

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

Thanks,
-peter

Look up the srand() function. Although it seems stupid at first glance, a
generator producing "pseudo-random" numbers using always the same seed at
startup (e.g. without specifying a different seed every time you run the
program), will give you a reproducable sequence of "random" numbers. This is
very helpful in case you want to debug the behavior of a simulation for
example.

BTW you should use srand only once in your program!!

HTH
Chris

[Peter Ammon]

Chris Theis wrote:

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

Thanks,
-peter

Look up the srand() function. Although it seems stupid at first glance, a
generator producing "pseudo-random" numbers using always the same seed at
startup (e.g. without specifying a different seed every time you run the
program), will give you a reproducable sequence of "random" numbers. This is
very helpful in case you want to debug the behavior of a simulation for
example.

BTW you should use srand only once in your program!!

HTH
Chris

random_shuffle evidently doesn't have to use rand() as its internal
PRNG; see my response to Mr. Bazarov.

-Peter

[Peter Ammon]

Victor Bazarov wrote:

"Peter Ammon" <pe*********@rocketmail.com> wrote...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

Read about 'srand' function.

V

Tried that and no dice. Looking in my headers, I see that
random_shuffle uses a template __random_number, which is defined as so:

template<typename _Distance>
inline _Distance
__random_number(_Distance __n)
{
#ifdef _GLIBCPP_HAVE_DRAND48
return lrand48() % __n;
#else
return rand() % __n;
#endif
}

and _GLIBCPP_HAVE_DRAND48 is unconditionally defined elsewhere, even
when I compile with -ansi -pedantic. I can seed it and get more random
results with seed48, but of course this is not portable.

So am I to conclude that there is no guarantee that random_shuffle's
internal PRNG is rand(), and that there need not be any user accessible
way to seed it? This would seriously call into question the utility of
random_shuffle without a user supplied RandomNumberGenerator in any
portable program

Ordinarily I'd call this a QoI issue, but I'm using g++ which is a
pretty high Q I.

-Peter

[Chris Theis]

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

Victor Bazarov wrote:
[SNIP]
template<typename _Distance>
inline _Distance
__random_number(_Distance __n)
{
#ifdef _GLIBCPP_HAVE_DRAND48
return lrand48() % __n;
#else
return rand() % __n;
#endif
}

and _GLIBCPP_HAVE_DRAND48 is unconditionally defined elsewhere, even
when I compile with -ansi -pedantic. I can seed it and get more random
results with seed48, but of course this is not portable.

So am I to conclude that there is no guarantee that random_shuffle's
internal PRNG is rand(), and that there need not be any user accessible
way to seed it? This would seriously call into question the utility of
random_shuffle without a user supplied RandomNumberGenerator in any
portable program

It is enforced by the standard that random shuffle uses a uniform
distribution random number generator. It is not guaranteed that this is
rand(). Due to the fact rand() is a standard function available on every
system it is the practical choice, which is also portable. If your compiler
implements the use of a non-standard function like lrand48 it's good for you
getting better random numbers, although you'll have to seed it accordingly.
IMHO such approaches are arguable because the user should at least be
notified that a non portable function is used for a standard algorithm.
Anyway I'm not sure whether _GLIBCPP_HAVE_DRAND48 is defined by default even
on systems supplying lrand48. This is actually the first case that I've
heard that this was troublesome. Generally one should supply an
implementation of a reasonable good RNG if good random numbers are required.

Regards
Chris

[DrPizza]

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

With difficulty.

The Standard provides no function to do this, and random_shuffle is forbidden
from using std::rand(). C++ "inherits" rand() from C (see [lib.c.math] -- rand
isn't defined in the C++ Standard at all, instead a reference is given to the
C Standard), and C states that "The implementation shall behave as if no
library function calls the rand function".

This constraint thus applies to C++, which thus prevents random_shuffle from
using rand().

A resolution is proposed.
http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#395

--
Now Playing: Marc Aurel - Running (dumonde remix) (D I G I T A L L Y - I M P
O R T E D - European Trance, Techno, Hi-NRG... we can't define it!)
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[Howard Hinnant]

In article <TT*******************@fe04.atl2.webusenet.com>,
"DrPizza" <dr*****@battleaxe.net> wrote:

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

With difficulty.

The Standard provides no function to do this, and random_shuffle is forbidden
from using std::rand(). C++ "inherits" rand() from C (see [lib.c.math] -- rand
isn't defined in the C++ Standard at all, instead a reference is given to the
C Standard), and C states that "The implementation shall behave as if no
library function calls the rand function".

This constraint thus applies to C++, which thus prevents random_shuffle from
using rand().

A resolution is proposed.
http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#395

And just fyi, the resolution was looked upon favoribly at last week's
standards meeting. If I remember correctly, its status was moved to
"ready". But don't take that to the bank until the next revision of the
issues list comes out.

-Howard

[Pete Becker]

DrPizza wrote:

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

With difficulty.

The Standard provides no function to do this, and random_shuffle is forbidden
from using std::rand(). C++ "inherits" rand() from C (see [lib.c.math] -- rand
isn't defined in the C++ Standard at all, instead a reference is given to the
C Standard), and C states that "The implementation shall behave as if no
library function calls the rand function".

This constraint thus applies to C++, which thus prevents random_shuffle from
using rand().

A resolution is proposed.
http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#395

Yup, we added redundant language to make it clear that statements in the
C standard about the C library are not constraints on the C++ library.
Shouldn't need to be said...

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[DrPizza]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

"Peter Ammon" <pe*********@rocketmail.com> wrote in message
news:bn**********@news.apple.com...

I'm calling random_shuffle without passing in a RandomNumberGenerator
and getting the same shuffle every time I restart my program. Apparently
I need to seed the internal random number generator. But how? I can't
find any way to do that, and if there is none, then how is the internal
random number generator useful?

With difficulty.

The Standard provides no function to do this, and random_shuffle is forbidden from using std::rand(). C++ "inherits" rand() from C (see [lib.c.math] -- rand isn't defined in the C++ Standard at all, instead a reference is given to the C Standard), and C states that "The implementation shall behave as if no
library function calls the rand function".

This constraint thus applies to C++, which thus prevents random_shuffle from using rand().

A resolution is proposed.
http://anubis.dkuug.dk/jtc1/sc22/wg2...ctive.html#395

Yup, we added redundant language to make it clear that statements in the
C standard about the C library are not constraints on the C++ library.
Shouldn't need to be said...

Why not? You wouldn't want to permit your C++ library to call strtok()
internally, would you? In general it seems quite desirable to carry that
constraint over from C; rand() is probably the only exception.

--
Now Playing: Accuface - Theme From Accuface
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[Pete Becker]

DrPizza wrote:

You wouldn't want to permit your C++ library to call strtok()
internally, would you?
Sure. Why not?
In general it seems quite desirable to carry that
constraint over from C; rand() is probably the only exception.

"Seems quite desirable" is not the same as "required by the standard."

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[DrPizza]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

You wouldn't want to permit your C++ library to call strtok()
internally, would you?

Sure. Why not?

Because it means you can't use strtok() yourself?

In general it seems quite desirable to carry that
constraint over from C; rand() is probably the only exception.

"Seems quite desirable" is not the same as "required by the standard."

But it (surely) is required by the standard because the standard just defers
to the C standard for the description of these functions, and one aspect of
the C standard pertinent to these functions is that the implementation shall
not call them.
--
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[tom_usenet]

On Thu, 6 Nov 2003 13:19:32 -0000, "DrPizza"
<dr*****@anti-flash.co.uk> wrote:

> In general it seems quite desirable to carry that
> constraint over from C; rand() is probably the only exception.

"Seems quite desirable" is not the same as "required by the standard."

But it (surely) is required by the standard because the standard just defers
to the C standard for the description of these functions, and one aspect of
the C standard pertinent to these functions is that the implementation shall
not call them.

The C standard only says that the implementation of the C library
won't call them.

Taking the original quote:
"The implementation shall behave as if no library function calls the
rand function"

The "library" referred to is the C library, not the C++ one. Just
because C++ includes the (slightly modified) C library doesn't mean
that it *is* the C library.

Tom

[Pete Becker]

DrPizza wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

You wouldn't want to permit your C++ library to call strtok()
internally, would you?
Sure. Why not?

Because it means you can't use strtok() yourself?

Non sequitur.

In general it seems quite desirable to carry that
constraint over from C; rand() is probably the only exception.

"Seems quite desirable" is not the same as "required by the standard."

But it (surely) is required by the standard because the standard just defers
to the C standard for the description of these functions, and one aspect of
the C standard pertinent to these functions is that the implementation shall
not call them.

The C++ standard does not change that constraint. No C function calls
rand.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[DrPizza]

"tom_usenet" <to********@hotmail.com> wrote in message
news:nc********************************@4ax.com...

The C standard only says that the implementation of the C library
won't call them. Well, no, it doesn't, it simply says that the implementation shall behave as
if no library function calls rand. It doesn't specify which library.
Taking the original quote:
"The implementation shall behave as if no library function calls the
rand function"

The "library" referred to is the C library, not the C++ one. Just
because C++ includes the (slightly modified) C library doesn't mean
that it *is* the C library.

Upon incorporation into C++, "the library" refers to the C++ library. The C++
library is the only library there is, so it's the only one it could refer to.
--
Now Playing: Daft Punk - Around The World
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[DrPizza]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:
>
> You wouldn't want to permit your C++ library to call strtok()
> internally, would you?

Sure. Why not? Because it means you can't use strtok() yourself?

Non sequitur.

If the implementation can call strtok() then I can't be sure what state
strtok()'s static buffer is in -- it need not be in the state I left it in.
This renders strtok() useless. If I use it I risk fucking up the library; if
the library uses it it risks fucking up my program.
The C++ standard does not change that constraint. No C function calls
rand.

Except the "not called by the library" statement refers only to the library of
the implementation, not the C library. Given that in C++ the implementation
is one of C++, and the library is that of C++, the restriction should constain
the C++ library too.
--
Now Playing: Daft Punk - Around The World
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[Pete Becker]

DrPizza wrote:

"tom_usenet" <to********@hotmail.com> wrote in message
news:nc********************************@4ax.com...

The C standard only says that the implementation of the C library
won't call them.

Well, no, it doesn't, it simply says that the implementation shall behave as
if no library function calls rand. It doesn't specify which library.

Taking the original quote:
"The implementation shall behave as if no library function calls the
rand function"

The "library" referred to is the C library, not the C++ one. Just
because C++ includes the (slightly modified) C library doesn't mean
that it *is* the C library.

Upon incorporation into C++, "the library" refers to the C++ library. The C++
library is the only library there is, so it's the only one it could refer to.

Where in the C++ standard do you find this assertion?

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[Pete Becker]

DrPizza wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...
> DrPizza wrote:
> >
> > You wouldn't want to permit your C++ library to call strtok()
> > internally, would you?
>
> Sure. Why not?
Because it means you can't use strtok() yourself?

Non sequitur.

If the implementation can call strtok() then I can't be sure what state
strtok()'s static buffer is in -- it need not be in the state I left it in.

The implementation is not allowed to change the state you left it in.
That's obvious from the semantics of strtok. Whether it calls strtok
internally is irrelevant, so long as it satisfies that requirement.

That's the problem with redundant requirements: people look for meaning
in them.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

[DrPizza]

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

"tom_usenet" <to********@hotmail.com> wrote in message
news:nc********************************@4ax.com...

The C standard only says that the implementation of the C library
won't call them.

Well, no, it doesn't, it simply says that the implementation shall behave as if no library function calls rand. It doesn't specify which library.

Taking the original quote:
"The implementation shall behave as if no library function calls the
rand function"

The "library" referred to is the C library, not the C++ one. Just
because C++ includes the (slightly modified) C library doesn't mean
that it *is* the C library.

Upon incorporation into C++, "the library" refers to the C++ library. The C++ library is the only library there is, so it's the only one it could refer to.

Where in the C++ standard do you find this assertion?

It's the only thing that the restriction could mean.

--
char a[99999],*p=a;main(c,V)char**V;{char*v=c>0?1[V]:V;if(c)for(;(c=*v)&&93^
c;p+=!(62^c)-!(60^c),*p+=!(43^c)-!(45^c),44^c||read(0,p,1),46^c||putchar(*p)
,91^c||(v=*p?main(-1,v+1),v-1:main(0,v)),++v);else for(;c+=!(91^*v)-!(93^*v)
;++v);return v;} /* dr*****@battleaxe.net brainf*** program as argv[1] */

[Pete Becker]

DrPizza wrote:

"Pete Becker" <pe********@acm.org> wrote in message
news:3F***************@acm.org...

DrPizza wrote:

"tom_usenet" <to********@hotmail.com> wrote in message
news:nc********************************@4ax.com...
> The C standard only says that the implementation of the C library
> won't call them.
Well, no, it doesn't, it simply says that the implementation shall behave as if no library function calls rand. It doesn't specify which library.

> Taking the original quote:
> "The implementation shall behave as if no library function calls the
> rand function"
>
> The "library" referred to is the C library, not the C++ one. Just
> because C++ includes the (slightly modified) C library doesn't mean
> that it *is* the C library.
Upon incorporation into C++, "the library" refers to the C++ library. The C++ library is the only library there is, so it's the only one it could refer to.

Where in the C++ standard do you find this assertion?

It's the only thing that the restriction could mean.

Several people have already disagreed with you here, so you are merely
repeating your position. That's a waste of time.

--

Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)