I support the proposals to make RandomStreams generic and remove the per-method parSafe arguments.
On 2/6/15, 4:55 PM, "Brad Chamberlain" <[email protected]> wrote: > >Hi Chapel Users -- > >This week, I've been working on converting the documentation for Chapel's >standard 'Random' module from being part of the language specification to >the up-and-coming chpldoc feature that will put the documentation on the >web in a more interactive and dynamic style -- it's a very nice feature! > >Anyway, in documenting the interface, I found some aspects of it that >feel >like they reveal the evolution of the code rather than the way I think >we'd want it to be, and so wanted to propose some changes. If you're >interested in the topic, please send your feedback/objections. > > >1) Parameterize RandomStreams by 'type eltType' > >This first change is motivated by the fact that, currently, the >RandomStream class's getNext() and getNth() methods generate values of >type real(64) while its fillRandom() method supports arrays of type >real(64), imag(64), and complex(128), which feels like somewhat of a >disconnect. > >My proposal is to make RandomStream generic with respect to a type >'eltType' (defaulting to 'real(64)' as it currently does), and to have >getNext() and getNth() generate values of that type. > >In doing so, I'm also proposing changing the RandomStream.fillRandom() >method to take only arrays of '[] eltType' where today, it takes arrays >of >type '[] real(64)', '[] imag(64)', or '[] complex(128)'. The rationale >for this is primarily an assumption that this supports the common case >while also simplifying the implementation. For example, if the user >created a RandomStream of complexes and then chose to fillRandom() an >array of reals with an odd number of elements, it feels fussy to deal >with >things like "what should happen to the last half-complex value?" > > >2) Rename some arguments > >In documenting the routines in chpldoc, the names of arguments are more >pronounced, and a few arguments that were not very imaginatively named, >I've renamed. E.g., fillRandom() used to take an array 'x' and now it >takes an array 'arr'. > > >3) Remove 'param parSafe' from methods on RandomStream > >The RandomStream class is guarded by a param bool 'parSafe' which says >whether or not the class should guard its key methods with mutexes in >order to ensure that multiple tasks accessing the stream do so in a >coordinated manner. In addition, all methods on the RandomStream class >take a similar param bool (which defaults to this.parSafe), permitting a >user to override the class-level parallel safety for a given call. > >In documenting the interface, this felt like it was probably unnecessary >that (I'm guessing) probably isn't used in practice. That is, I suspect >that I'm probably always going to use my RandomStream class in a manner >that's parallel safe or not rather than using it in different modes in >different parts of my program. > >To that end, I've been toying with keeping the class-level 'parSafe' but >removing the per-method 'parSafe' arguments to keep things simpler. > >Thoughts on any of this? > > >Note that there are still several TODOs noted in the module documentation >itself, such as supporting other element types, supporting other PRNG >algorithms, etc. that remain longer-term efforts at present (and will >likely require additional changes to the interface). I'm not proposing >tackling any of those at present, though I have started looking into what >it would take to support the Mersenne twister algorithm. > > >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 ------------------------------------------------------------------------------ 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
