Factors are not first-class citizens in R
win-vector.com
Factors are not first-class citizens in R
1–10 of 18 posts
Re: Factors are not first-class citizens in R
#2I can't even describe how much I wish `stringsAsFactors=F` was the default.
Re: Factors are not first-class citizens in R
#3I can't even describe how much I wish `stringsAsFactors=F` was the default.
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.
Re: Factors are not first-class citizens in R
#4This is really well-written. I was skeptical about the title's claim but truly, the author defines what first-class citizens mean and a wide range of cases where the behavior is inconsistent.
I have gotten used to its behavior but only because I use factors sparingly, having set stringsAsFactors=FALSE as my default. But reshape2::melt() requires a separate argument (factorsAsStrings) if you don't want automatic conversion, and with plyr::ldply() you can't prevent the index column conversion to a factor at all. So factors creep in periodically into my data frames and burns me every now and then.
Re: Factors are not first-class citizens in R
#5I can't even describe how much I wish `stringsAsFactors=F` was the default.
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.
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?
Re: Factors are not first-class citizens in R
#6An aside, on the sidebar there is a link to "Practical Data Science with R", presumably this blog belongs to the author? Apologies for my inexperience here, but can anyone recommend that book? I have "R in Action" and am subscribed to the MEAP for the next edition, is this book a good companion? Appreciate any responses!
Re: Factors are not first-class citizens in R
#7This is really well-written. I was skeptical about the title's claim but truly, the author defines what first-class citizens mean and a wide range of cases where the behavior is inconsistent. I have gotten used to its behavior but only because I use factors sparingly, having set stringsAsFactors=FALSE as my default. But reshape2::melt() requires a separate argument (factorsAsStrings) if you don't want automatic conve…
> But reshape2::melt() requires a separate argument (factorsAsStrings) if you don't want automatic conversion, and with plyr::ldply() you can't prevent the index column conversion to a factor at all. So factors creep in periodically into my data frames and burns me every now and then.
Oh, wow, thanks for that. I generally prefer data.table to plyr, but I do use reshape2 of course so that's great to know.
Re: Factors are not first-class citizens in R
#8Earlier quoted context omitted.
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.
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 tha…
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.
Re: Factors are not first-class citizens in R
#9An aside, on the sidebar there is a link to "Practical Data Science with R", presumably this blog belongs to the author? Apologies for my inexperience here, but can anyone recommend that book? I have "R in Action" and am subscribed to the MEAP for the next edition, is this book a good companion? Appreciate any responses!
One of the blog/book authors here (John Mount). Yes the book and blog are both by Nina Zumel and John Mount. Obviously my opinion is biased, but here is a bit anyway. "R in Action" is one of our favorite R books (that and "The Art of R Programming"). "Practical Data Science with R" is more about working examples of data science (lots of the grungy tubing steps, how to think about some of the statistical tests, what sort of software to use at moderate data size). So if you would like the book depends a lot on if you are interested in those steps are not. My more hard-sell push of the book is here: http://www.win-vector.com/blog/2014/06/how-does-practical-da...
Re: Factors are not first-class citizens in R
#10This is really well-written. I was skeptical about the title's claim but truly, the author defines what first-class citizens mean and a wide range of cases where the behavior is inconsistent. I have gotten used to its behavior but only because I use factors sparingly, having set stringsAsFactors=FALSE as my default. But reshape2::melt() requires a separate argument (factorsAsStrings) if you don't want automatic conve…
> But reshape2::melt() requires a separate argument (factorsAsStrings) if you don't want automatic conversion, and with plyr::ldply() you can't prevent the index column conversion to a factor at all. So factors creep in periodically into my data frames and burns me every now and then. Oh, wow, thanks for that. I generally prefer data.table to plyr, but I do use reshape2 of course so that's great to know.
It's worth taking a look at `dplyr`. You can work with data tables or data frames (or a database), and the functions are in the same neighborhood as data.table functions in terms of speed. Also, in addition to `reshape2`, there is `tidyr`.