Dave Whipp wrote:
> masak wrote:
>> Modified:
>>    docs/Perl6/Spec/S32-setting-library/Numeric.pod
>> Log:
>> [S32/Numeric] removed method form of srand
>> Overwhelming consent on #perl6 about this.
>> - multi method srand ( Real $seed: )
>>   multi srand ( Real $seed = default_seed_algorithm())
>>  Seed the generator C<rand> uses. C<$seed> defaults to some combination
> I think that most serious users of random numbers (that includes me) 
> would generally agree that it would be foolish to use the builtin RNG in 
> most languages -- looks like Perl6 would be included in that list. I was 
> wondering if something could be done to at least make the abstraction 
> usable.

I agree, even though I'm only a semi serious user of RNG.

> There are two main issues: the generator algorithm, and the scope of the 
> generator.
> The issue of selecting an algorithm with sufficiently good statistical 
> properties could be addressed simply by allowing a closure/iterator to 
> be passed to srand to set the actual RNG algorithm, not just the seed. 
> That should be fairly simple to implement.
> For my work, the more interesting issue is scope of the RNG. This breaks 
> down into a couple of issues:
> 1. do all implementations of Perl6 generate the same sequence, given the 
> same initial seed. 

I don't think they should. If you want that, use confuse a RNG with a
sequence generator that it is not.

> If the initial "seed" were a closure then of course 
> this question becomes irrelevant. So I'd be tempted to allow closures, 
> and then leave the default RNG as implementation-defined.
> 2. seed stability across multiple "generators":
> 2a. If I spawn two threads (implicitly or explicitly), how do their RNGs 
> interact? I.e. are C<rand> and C<pick> thread-safe?
> 2.b If I create multiple classes/objects, each of which generates a 
> stream of random traffic (a common need generating random tests), can I 
> change the implementation of one of those classes without affecting the 
> traffic generated by the others. The standard way to deal with this is 
> to have a distinct random generator per-object. To have that as the 
> default behavior of Perl6 would probably be too expensive. That said, it 
> would be nice if there were a way to define the scope/multiplicity of 
> the internal RNG so that functions like C<pick> could be used within 
> such a traffic generator scenario.
> I think that all that is needed is to permit some sort of 
> declaration/pragma that creates a dynamic scope for an srand: e.g. "temp 
> srand { ... };"

I'd say

1) A RNG class (don't really care what the name is, for now)
2) An instance of that in $*RAND (which you can temp())
3) rand() and srand() act on $*RAND
4) It should be easy to create instances of the RNG to use in your own

Would that make sense to you?

Reply via email to