Hi, On Thu, Aug 29, 2013 at 3:03 PM, Rolf Turner <rolf.tur...@xtra.co.nz> wrote: > On 29/08/13 12:10, Ista Zahn wrote: >> >> On Wed, Aug 28, 2013 at 7:44 PM, Steve Lianoglou >> <lianoglou.st...@gene.com> wrote: >>> >>> Hi, >>> >>> On Wed, Aug 28, 2013 at 3:58 PM, Ista Zahn <istaz...@gmail.com> wrote: >>>> >>>> Or go all the way and put >>>> >>>> options(stringsAsFactors = FALSE) >>>> >>>> at the top your script or in your .Rprofile. This will prevent this >>>> kind of annoyance in the future without having to say stringsAsFactors >>>> = FALSE all the time. >>> >>> I go back and forth about doing this too (setting a global hammer to >>> stringsAsFactors), but then other things might mess up -- imagine a >>> scenario where a package is written with the assumption that the >>> default `stringsAsFactors=TRUE` setting hasn't been changed, which >>> could then break when you go the nuclear-global-override route. >> >> Yes, possibly, but I've yet to have that problem, whereas before I >> started changing it globally things used to break fairly regularly. > > > Like Ista I have never had a problem arising from a package's assuming that > `stringsAsFactors=TRUE` --- and I would opine that any package making such > an assumption is badly written. (Of course there is a lot of bad code out > there ....)
It never happened to me either, except when code that *I* wrote was dependent on the global options settings to stringsAsFactors=FALSE. I had to hand over a codebase to a colleague in my lab when I left. Her options(stringsAsFactors) was at the default (TRUE), and things mysteriously broke until we (eventually) sorted out what was the what -- it took a while to find because I *totally* forgot I had set `options(stringsAsFactors=FALSE)` my ~/.Rprofile several years prior (a testament to how little it breaks things I guess). Of course, I can't argue with your premise that code written that depends on the defaults (or changed defaults) is, in the end, poorly written code ... sometimes we have to own up to being the ones who write poorly written code ;-) I only posted my original warning here to serve, more or less, as the sentiment put forth in this poster since a decent amount of time was lost chasing our tails: http://www.despair.com/mistakes.html ;-) -steve -- Steve Lianoglou Computational Biologist Bioinformatics and Computational Biology Genentech ______________________________________________ R-help@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
