[Rd] type.convert and doubles

[Martin Maechler]

>>>>> Therneau, Terry M , Ph D <therneau at mayo.edu>
>>>>>     on Tue, 22 Apr 2014 12:18:55 -0500 writes:

    > "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,  you are right that sweeping statements in general are
not something scientists should use often.

First note that I would not advocate abolishing existing global
options,  because at the same time I do advocate back
compatibility often more than colleagues.

But I do continue the argument that global options are something
tempting but never necessary.  Almost all agree that their
convenience, e.g. for output printing, e.g. number of digits, or
plotting -- adapting  to "current state" is something we just do
want for convenience.
But I'm still arguing that using an explicit 'stringsAsfactor'
*argument* -- or your own wrapper for  read.table() with 
different defaults, would be much cleaner.  There are not so
many cases where you'd have to pass such an argument, and - I
think also pass a 'na.action' argument to modelling functions, 
rather than getting these from a global option.

Said all that, yes, I'd try to fight hard introducing 
*more* global options that influence basic R functionality
apart from *output* configuration.

Martin







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