Le mardi 22 avril 2014 à 12:18 -0500, Therneau, Terry M., Ph.D. a écrit : > "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? Very interesting. Do you have any written references about this behavior, and how it was eventually changed?
Thanks > Terry T. > > > > > 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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
