[Rd] type.convert and doubles

[Milan Bouchet-Valat]

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-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
> https://stat.ethz.ch/mailman/listinfo/r-devel