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
