On Thu, Oct 6, 2011 at 11:25 PM, Prof Brian Ripley <rip...@stats.ox.ac.uk>wrote:
> > Why would it make it easier? And how could using a dummy for 'most users' > (who are on Windows) offer them 'good parallel support'? Good point. Most of my users are on unix, because my use of mclapply() is primarily to expedite processing of raw scanner data. Only a handful of users for the packages that call mclapply() are on Windows. Right now, I default to having parallel=FALSE flags all over the place, but I'd prefer for the default to be "go as fast as practical in the common case", i.e., Unix. It would have been more accurate for me to say "I would like to parallelize by default, without having the methods fail on Windows in the default configuration" than to claim that I want "good parallel support" for Windows. When I have tried using the foreach/doMC combination in the past, it has not worked out satisfactorily, so I don't know how well I can support Windows users... period. Take a look at e.g. package 'boot' to see how to offer alternatives. (A > version that uses 'parallel' is pending on CRAN, or see > http://www.stats.ox.ac.uk/pub/**R/boot_1.3-3.tar.gz<http://www.stats.ox.ac.uk/pub/R/boot_1.3-3.tar.gz>.) > Package 'parallel' may in future offer a higher-level abstraction layer > that makes offers such a choice, but as the 'boot' code shows, deciding what > to send to the workers in a snow-style cluster is not simple. > It seems similar to what I do (off topic: why do you use the file extension '.q' for all of the R/S code files?): pass flags around. I suppose I was just being lazy, but I would love to default to "go as fast as possible" without having Windows users get left out in the cold (unless they add flags to their function calls). Thank you for your suggestions, I will look into this further. -- Tim Triche, Jr. USC Biostatistics [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
