[Rd] type.convert and doubles
Therneau, Terry M., Ph.D.
therneau at mayo.edu
Tue Apr 22 19:18:55 CEST 2014
"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?
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
More information about the R-devel