On Mon, Apr 12, 2010 at 07:24:37PM +0200, Moritz Lenz wrote:
: 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.
I also agree, having abused random numbers liberally in a past
(technical) life.
: > 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:
Yes, it's really all about scoping, and the ability to construct (at least in
the abstract)
trees of random sequences.
: > 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.
While I agree that the default should be non-reproducable, the
approach taken in Perl 5 is nice to the extent that if you *do*
seed the built-in RNG with a consistent value, you get a reproducable
result. And reproducable trees of random sequences can be generated
by controlling the seeds of each node in the tree.
To be sure, Perl 5 doesn't try very hard to help you with scoping
issues beyond that.
: > 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?
Certainly the standard approach will involve some such dynamic
variable, or possibly a dynamic &*RAND function. And the intent is
that readonly dynamic variables be optimizable by copy-in much like
environment variables are copied into processes. So performance is
not much of an issue here, if we set up the dynamic context suitably.
This does make me wonder if there should be some support for
auto-temping some or all dynamic variables on thread creation
boundaries...hmm... But what if you *want* to use one sequence across
multiple threads...hmm...
Of course, any give lexical scope can also set up its own lexically
scoped random functions that will override anything in the language,
if you want to do stuff cross-thread. Or just set up a generator
outside your threads that is shared via an outer lexical.
We've got enough rope to hang ourselves differently every day of
the week, with some left over for next week.
Larry
