Re: random_shuffle seed

Discussion in 'C++' started by DrPizza, Nov 2, 2003.

  1. DrPizza

    DrPizza Guest

    "Peter Ammon" <> wrote in message
    news:bnpfl8$mqb$...
    > 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/wg21/docs/lwg-active.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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 2, 2003
    #1
    1. Advertising

  2. In article <TT_ob.101487$2.webusenet.com>,
    "DrPizza" <> wrote:

    > "Peter Ammon" <> wrote in message
    > news:bnpfl8$mqb$...
    > > 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/wg21/docs/lwg-active.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
    Howard Hinnant, Nov 3, 2003
    #2
    1. Advertising

  3. DrPizza

    Pete Becker Guest

    DrPizza wrote:
    >
    > "Peter Ammon" <> wrote in message
    > news:bnpfl8$mqb$...
    > > 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/wg21/docs/lwg-active.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)
    Pete Becker, Nov 6, 2003
    #3
  4. DrPizza

    DrPizza Guest

    "Pete Becker" <> wrote in message
    news:...
    > DrPizza wrote:
    > >
    > > "Peter Ammon" <> wrote in message
    > > news:bnpfl8$mqb$...
    > > > 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/wg21/docs/lwg-active.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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 6, 2003
    #4
  5. DrPizza

    Pete Becker Guest

    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)
    Pete Becker, Nov 6, 2003
    #5
  6. DrPizza

    DrPizza Guest

    "Pete Becker" <> wrote in message
    news:...
    > 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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 6, 2003
    #6
  7. DrPizza

    tom_usenet Guest

    On Thu, 6 Nov 2003 13:19:32 -0000, "DrPizza"
    <> 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
    tom_usenet, Nov 6, 2003
    #7
  8. DrPizza

    Pete Becker Guest

    DrPizza wrote:
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > 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)
    Pete Becker, Nov 6, 2003
    #8
  9. DrPizza

    DrPizza Guest

    "tom_usenet" <> wrote in message
    news:...
    > 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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 7, 2003
    #9
  10. DrPizza

    DrPizza Guest

    "Pete Becker" <> wrote in message
    news:...
    > DrPizza wrote:
    > >
    > > "Pete Becker" <> wrote in message
    > > news:...
    > > > 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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 7, 2003
    #10
  11. DrPizza

    Pete Becker Guest

    DrPizza wrote:
    >
    > "tom_usenet" <> wrote in message
    > news:...
    > > 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, Nov 7, 2003
    #11
  12. DrPizza

    Pete Becker Guest

    DrPizza wrote:
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > DrPizza wrote:
    > > >
    > > > "Pete Becker" <> wrote in message
    > > > news:...
    > > > > 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)
    Pete Becker, Nov 7, 2003
    #12
  13. DrPizza

    DrPizza Guest

    "Pete Becker" <> wrote in message
    news:...
    > DrPizza wrote:
    > >
    > > "tom_usenet" <> wrote in message
    > > news:...
    > > > 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;} /* brainf*** program as argv[1] */
    DrPizza, Nov 7, 2003
    #13
  14. DrPizza

    Pete Becker Guest

    DrPizza wrote:
    >
    > "Pete Becker" <> wrote in message
    > news:...
    > > DrPizza wrote:
    > > >
    > > > "tom_usenet" <> wrote in message
    > > > news:...
    > > > > 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)
    Pete Becker, Nov 7, 2003
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Peter Ammon

    Re: random_shuffle seed

    Peter Ammon, Oct 31, 2003, in forum: C++
    Replies:
    0
    Views:
    458
    Peter Ammon
    Oct 31, 2003
  2. Peter Ammon

    Re: random_shuffle seed

    Peter Ammon, Oct 31, 2003, in forum: C++
    Replies:
    1
    Views:
    1,666
    Chris Theis
    Oct 31, 2003
  3. Ronak
    Replies:
    1
    Views:
    656
    tom_usenet
    Nov 17, 2003
  4. steflhermitte
    Replies:
    1
    Views:
    823
    Kanenas
    Apr 21, 2005
  5. Nelis Franken
    Replies:
    2
    Views:
    419
    Nelis Franken
    Aug 22, 2006
Loading...

Share This Page