>>>>> Therneau, Terry M , Ph D <thern...@mayo.edu> >>>>> on Tue, 22 Apr 2014 12:18:55 -0500 writes:
> "No global options" > I don't have an opinion about type.convert, but I must object to Martin's sweeping > statement about global options, and stringsAsFactors in particular. There have been only > a few decisions in Splus/R that were so bad that our biostat group modified the core > routines in order to return to sane behavior: automatic conversion of strings to factors > was one of them --- not just when reading a data set but every bloody time you modified a > data frame. Addition of the global option was a blessing. > I work in a large biostatistics group whose mission is the advancement of medicine. > Nothing frightens me more about the long term viability of R as a tool than sweeping > announcements about "principles" which brush pragmatic considerations aside as irrelevant. > Some of us need to get work done. (S4 zealots can be particularly annoying in this > regard.) > How many of you remember the orignal S decision to have all modeling functions fail upon > seeing a missing value? The na.action argument was only available within lm() etc calls, > with no global override, because "missing values are serious artifacts and should not be > removed without thought". Martin- should this be removed from the global options as well? Terry, you are right that sweeping statements in general are not something scientists should use often. First note that I would not advocate abolishing existing global options, because at the same time I do advocate back compatibility often more than colleagues. But I do continue the argument that global options are something tempting but never necessary. Almost all agree that their convenience, e.g. for output printing, e.g. number of digits, or plotting -- adapting to "current state" is something we just do want for convenience. But I'm still arguing that using an explicit 'stringsAsfactor' *argument* -- or your own wrapper for read.table() with different defaults, would be much cleaner. There are not so many cases where you'd have to pass such an argument, and - I think also pass a 'na.action' argument to modelling functions, rather than getting these from a global option. Said all that, yes, I'd try to fight hard introducing *more* global options that influence basic R functionality apart from *output* configuration. Martin > On 04/22/2014 05:00 AM, r-devel-requ...@r-project.org wrote: >>>>>>> >>>>>McGehee, Robert<robert.mcge...@geodecapital.com> >>>>>>> >>>>> on Mon, 21 Apr 2014 09:24:13 -0400 writes: >> > Agreed. Perhaps even a global option would make sense. We >> > already have an option with a similar spirit: >> > 'options(?stringsAsFactors"=T/F)'. Perhaps >> > 'options(?exactNumericAsString?=T/F)' [or something else] >> > would be desirable, with the option being the default >> > value to the type.convert argument. >> >> No, please, no, not a global option here! >> >> Global options that influence default behavior of basic >> functions is too much against the principle of functional >> programming, and my personal opinion has always been that >> 'stringsAsFactors' has been a mistake (as a global option, not >> as an argument). >> >> Note that with such global options, the output of sessionInfo() >> would in principle have to contain all (such) global options in >> addtion to R and package versions in order to diagnose behavior >> of R functions. >> >> I think we have more or less agreed that we'd like to have >> a new function*argument* to type.convert(); >> passed "upstream" to read.table() and via ... the other >> read.<foo>() that call read.table. >> >> >> > I also like Gabor?s idea of a ?distinguishing class?. R >> > doesn?t natively support arbitrary precision numbers >> > (AFAIK), but I think that?s what Murray wants. I could >> > imagine some kind of new class emerging here that >> > initially looks just like a character/factor, but may >> > evolve over time to accept arithmetic methods and act more >> > like a number (e.g. knowing that ?0.1?, ?.10? and "1e-1" >> > are the same number, or that ?-9?<?-0.2"). A class >> > ?bignum? perhaps? >> >> That's another interesting idea. As maintainer of CRAN package >> 'Rmpfr' and co-maintainer of 'gmp', I'm even biased about this >> issue. >> >> Martin >> ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel