www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - std.random shared state for seed?

reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
By the looks of the documentation - haven't checked the code - the std.random
module shares a single seed state.

IMO this is wrong. What if one wanted to conduct several repeatable tests
concurrently - perhaps because the measured aspects were running in multiple
threads?

It should be rewritten as a class, as in:

    class Random
    {
    public:
        this(uint seed, uint index);
        this();

    public:
        uint rand();

    // Implementation
        . . .
    }

Also, why not use provide extensed sized random values, e.g. 64-bits, perhaps
combining 2 successive uints into a ulong? Sure, it can be done in client code,
but better to have it done once only in Phobos.
Jul 14 2004
next sibling parent Regan Heath <regan netwin.co.nz> writes:
On Thu, 15 Jul 2004 11:02:09 +1000, Matthew 
<admin stlsoft.dot.dot.dot.dot.org> wrote:
 By the looks of the documentation - haven't checked the code - the 
 std.random
 module shares a single seed state.

 IMO this is wrong. What if one wanted to conduct several repeatable tests
 concurrently - perhaps because the measured aspects were running in 
 multiple
 threads?

In C it's per thread, this caused me to have bugs till I realised that. It needs to be per instance of it's use, not global.
 It should be rewritten as a class, as in:

     class Random
     {
     public:
         this(uint seed, uint index);
         this();

     public:
         uint rand();

     // Implementation
         . . .
     }

I agree, this would have the advantage that if you need to re-seed for a specific task, but have already seeded externally for general use, you can, without having to get/remember the external seed and reset when you are done. Isn't the rule "if there is state to be stored in between calls then use a class otherwise make them stand alone functions"? It seems clear to me that there is state to be stored here.
 Also, why not use provide extensed sized random values, e.g. 64-bits, 
 perhaps
 combining 2 successive uints into a ulong? Sure, it can be done in 
 client code,
 but better to have it done once only in Phobos.

Agreed. ulong rand() could be cast to anything smaller as long as casting stays consistent so will the resulting random numbers. Regan -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jul 14 2004
prev sibling parent Arcane Jill <Arcane_member pathlink.com> writes:
In article <cd4l34$14tv$2 digitaldaemon.com>, Matthew says...
By the looks of the documentation - haven't checked the code - the std.random
module shares a single seed state.

It should be rewritten as a class

etc.random is in the pipeline, if you can wait. This will include all sorts of PRNG and TRNG stuff, both cryptographically secure and rand()-like. It will do all that you suggest. Jill (still vaguely sort of here)
Jul 15 2004