[Rd] type.convert and doubles

[Therneau, Terry M., Ph.D.]

"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 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
>