7 ms·

They've agreed to do this site-wide at the Mayo Clinic. https://stat.ethz.ch/pipermail/r-help/2007-February/125438.html https://stat.ethz.ch/pipermail/r-help/2

• craigching 12y ago
  I'm still a bit of an R neophyte but, yes, stringsAsFactors=FALSE seems so much more intuitive to me. I seem to assume that's true and write code that explicitly sets strings as factors where appropriate when it's not needed due to the default and get confused when trying to figure out why some are factors and some are not. I'm going to look more into setting this option, but is it consumable by others? I write R that will be consumable by customers, presumably I can set this at the top of my R source files?
  • mapcar 12y ago
    Again, if you remember to include options(stringsAsFactors=FALSE) at the top of your scripts, they are transferable. With other R neophytes who only run code that I write, I tell them to run cat("options(stringsAsFactors=FALSE)\n",file="~/.Rprofile",append=TRUE) at the R console.
    • craigching 12y ago
      gotcha, thanks!
    • jghn 12y ago
      And I'd tell you no. And to the GP, adding that to consumable code, particularly a distributed package, is generally seen as impolite behavior. What happens if I load your package and then another one which assumes the standard default? If you absolutely must mess with peoples options, the way to do it is capture the original state, modify the option, make your affected call and then restore the original options. I do agree that for my purposes I generally would prefer that as the default but even after using R for ~15 years I don't see it as some huge burden to specify it each time.