Note that the question on the table isn't whether or not we should support the generation of random integers or add additional standalone functions to the Random module. It's whether, given a RandomStream abstraction, it is reasonable to think of it as generating a given type 't', and whether it's also reasonable not to expect its methods to support filling arrays of a different type 't2'. So, given a RandomStream of real (or int), is it reasonable to expect it not to support methods that fill arrays of ints (or reals or complexes or chars, or strings, or ...).
-Brad ________________________________________ From: Thomas Van Doren Sent: Sunday, February 15, 2015 4:20 PM To: Brad Chamberlain; Nikhil Padmanabhan Cc: [email protected] Subject: Re: Proposed changes to 'Random' standard module In my python experience, I use the random.randint() and random.uniform() functions pretty often when I need a random number (typically in a script or test program). In those cases I am not deeply concerned about a perfectly random distribution; I just want something easy to use that is more random than the current time usually. In chapel, I think this is what is required today to get a random integer between 0 and 100: var rs = RandomStream(); var r = rs.getNext(); var randInt = (100 * r):int; As a user, I would prefer a randomInt function in the Random module that essentially does the above for me, so I can write this: var randInt = randomInt(0, 100); A productivity compromise here might be to implement some functions in the Random module that work with integers (e.g. randomInt(), fillRandom([] int), etc). Under the covers, they could/would use the floating point RandomStream. The documentation for the module would then need to mention potential differences in using the integer functions vs the RandomStream, but that seems ok. On 2/13/15, 1:50 PM, "Brad Chamberlain" <[email protected]> wrote: > >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 ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk _______________________________________________ Chapel-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-users
