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
class.
Would that make sense to you?
Moritz
