• Matthew (19/19) Jul 14 2004 By the looks of the documentation - haven't checked the code - the std.r...
• Regan Heath (16/39) Jul 14 2004 In C it's per thread, this caused me to have bugs till I realised that. ...
• Arcane Jill (5/8) Jul 15 2004 etc.random is in the pipeline, if you can wait. This will include all so...

"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.

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/

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)