[Rd] type.convert and doubles
nalimilan at club.fr
Tue Apr 22 22:47:34 CEST 2014
Le mardi 22 avril 2014 à 12:18 -0500, Therneau, Terry M., Ph.D. a
> "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
> 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?
> Terry T.
> On 04/22/2014 05:00 AM, r-devel-request at r-project.org wrote:
> >>>>>> >>>>>McGehee, Robert<Robert.McGehee at 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 at r-project.org mailing list
More information about the R-devel