>> 3) Remove 'param parSafe' from methods on RandomStream > > I suspect that there will be other cases like this. I.e. an interface to be > documented has a feature that is unused, as far as we can tell, or perhaps > used infrequently. And, this feature adds substantial bulk to documentation. > > My preference is to avoid dropping such a feature just because it presents a > documentation issue.
I don't think it's accurate to say that I'm proposing dropping it because it presents a documentation issue. It's currently documented, and it doesn't add that much bulk or complexity. It's more that, while documenting it, I found myself surprised that we'd added the capability, unable to rationalize it well, and a little baffled that we'd bothered to. Hence the question to chapel-users asking whether it's something that users value. If they don't, I don't see the point in supporting it. Future users may want and request it (or they may request something else we haven't anticipated), but we can deal with that if/when they do. The main thing I'm worried about is setting a precedent. I.e., having created a generic object with properties A, B, and C, it seems unfortunate to set a precedent that every method should feel the need to allow callers to override A, B, and C from one call to the next. There are other approaches we could consider taking here: * Rather than making parSafe into a param member of the class, it could be made a var member of the class so that the user could change it from true to false whenever they want to over the lifetime of the variable without adding extra arguments to every call. This would add a small amount of execution-time overhead (a few conditionals) to each of the main methods by converting a param conditional to a runtime conditional, but would keep the method interfaces clean by not cluttering them with extra arguments. * Or, we could have the class store both a param member and a var member to indicate whether the object should be parsafe, where the former serves as a static way to optimize away any overhead, and the latter serves as a way to flip a "may be parSafe" object from parSafe to not from one call to the next. * Or, we could introduce language-level notions of mutual exclusion on classes/objects and use that type of capability here. The former seems reasonable to me, but wasn't my preference, so I didn't propose it waiting to see if anyone else's feedback suggested it would be valuable. The middle option would arguably give anyone what they wanted in terms of parallel safety but at the cost of more complexity in the implementation and documentation. The final option sounds attractive, but was more than I wanted to take up here (and also suggests supporting the simpler interfaces). Instead, I proposed the param-only approach with no ability to override, thinking that if someone truly had the need for a single RandomStream to work in both parallel-safe and non-parallel-safe settings, there are still several options available to them: * pay the overhead in all cases * don't pay the overhead and do your own mutual exclusion when you need it * create a new RandomStream when the current one doesn't have the parallel safety you want (potentially with the same seed and fast-forwarded to the same place in the stream) * create a new meta-RandomStream class that does the previous bullet under the covers for you. The principle I wanted to espouse by proposing the simplification was that if you ask for a param-parallel-safe RandomStream at creation time, that's what you should expect to get, rather than one in which the methods should be cluttered in order to give you the option of changing your mind later. >> 1) Parameterize RandomStreams by 'type eltType' >> [...] > > I agree it will make common uses easier/consistent. > > However, what if I need to randomize several arrays of different element > types? This proposal will force me to create several RandomStreams, and I > will have to go through the hassle of ensuring that their random sequences do > not overlap. You're correct that this case would no longer be supported in my proposal. My argument was that supporting getNth() and getNext() routines that generate a logical 'eltType' at the cost of only filling arrays with that eltType was likely to be more valuable than hard-coding the routines to always return real's but to permit those reals to be stored into arrays of imag's and complexes (which seems funny). In saying this, I'm anticipating support for random streams of other types (say, int(8)s) where I'd be disinclined to support fillRandom() on reals or strings or arbitrary types where the conversion from 'eltType' to that type may not be obvious and shouldn't be expected. Again, a user could create a new RandomStream with the same seed and fast-forwarded to element 'n' if they needed to accomplish this. > I propose that we support such a scenario as well, one way or another. Given that our users aren't shy, I was going to propose we go with the simpler approach for now (a random stream of type 'eltType' generates 'eltTypes' and fills random arrays of 'eltType') and wait for them to request "I want to fill an array of type 'eltType2' using my RandomStream of type 'eltType' before worrying about that functionality. -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
