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.
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. 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 { ... };"
