Hi Nikhil --
Thanks for the input on this question. I've been mulling over your
response below this week and here are my thoughts. I should prefix them
by saying that I'm not at all an expert in PRNGs and so may be being
overly conservative (and am open to being convinced of that).
> I like the idea of making get* and fillRandom generic. Is there really a
> significant advantage to making this generic at the RandomStream level
> instead of the get function level? Most random number generators generate
> integers that get rescaled to eg. reals, so I'd think there is less of a
> gain to putting this at the stream level.
As I've been thinking about this, what I've been wrestling with relates to
the extensive comments in the PRNG that we took our currenet algorithm
from which make certain guarantees about the properties of the spread of
the random numbers between a certain range (which are 64-bit floating
point values). One of the reasons that I think we haven't added support
for filling an array of ints (or even 32-bit reals) as a convenience is
concern that the properties that the PRNG is guaranteeing will be lost if
converting to integers.
For example, I understand that if I wanted pseudo-random integers between
1 and n, I could take the floating point values that the current
RandomStream is returning and multiply them by 'n', but it seems unlikely
to me that we could make any guarantees about all integers between 1 and n
getting generated equally often. I'm basing this assumption simply on the
pigeonhole principle that if the number of possible floating point numbers
doesn't divide evenly by 'n' that some integers will occur more often than
others.
That suggests to me that a given algorithm for generating PRNGs should
focus on only generating types that are "native" to the algorithm, and
that any conversion to other types should be on the user rather than on
the RandomStream itself. Thus, if you wanted to convert the floats we're
generating to integers, you're welcome to do so, but the questions of "How
random" the values are fall on the user rather than the library writer.
That's what led me to the current proposal. A PRNG that only generates
64-bit floating point values should only be useful for generating those
types and conversion to other types would be done by the user, say using
an idiom like:
var A: [1..m] int;
forall (a, r) in (A, myRandomFloatStream) do
a = (r*n): int;
You do more with random numbers than I do... Does this argument hold up?
The other part of my argument, which could be considered laziness (or
trying to simplify the job of the random stream writer) is that for a
PRNG that generates values of a given type t (in this case, float(64)
values), it seems unfortunate to require the author to have to figure
out all the other types that it might be reasonable to fill with that
random stream and how to convert to those types (e.g., all 4 sizes of
int and uint, both sizes of real, imag, and complex, enums?, strings?
characters?). Thus, from a KISS perspective, my thinking was to have
them generate what the algorithm knows how to and have users take care
of the conversion semantics (again, using a loop like the above).
> I don't have a particularly strong opinion on parSafe. Personally, I can't
> see myself writing code that switches between the two --- I suspect I'd
> just eat the overhead for the gain in simplicity.
OK, thanks.
-Brad
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Chapel-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chapel-users
