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.

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/

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)