Hacker News new | ask | show | jobs
by mapcar 4280 days ago
They've agreed to do this site-wide at the Mayo Clinic.

https://stat.ethz.ch/pipermail/r-help/2007-February/125438.h...

I have adopted this approach as well, and for all the scripts I distribute I set options(stringsAsFactors=FALSE) at the top.

1 comments

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?

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.

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.

gotcha, thanks!