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