Message-ID: <f8e6ff051001220545h7318068s849bf22e074cb363@mail.gmail.com>
Date: 2010-01-22T13:45:55Z
From: Hadley Wickham
Subject: Inconsistency in as.data.frame.table for stringsAsFactors
In-Reply-To: <19289.24362.734838.778263@lynne.math.ethz.ch>
On Fri, Jan 22, 2010 at 2:17 AM, Martin Maechler
<maechler at stat.math.ethz.ch> wrote:
>>>>>> "SM" == Stavros Macrakis <macrakis at alum.mit.edu>
>>>>>> ? ? on Thu, 21 Jan 2010 20:19:28 -0500 writes:
>
> ? ?SM> I noticed that in as.data.frame.table, the stringsAsFactors argument
> ? ?SM> defaults to TRUE, whereas in the other as.data.frame methods, it defaults to
> ? ?SM> default.stringsAsFactors().
>
> ? ?SM> The documentation and implementation agree on this, so this is not a bug.
>
> ? ?SM> However, I was wondering if this disparity was intended or if it might be
> ? ?SM> some sort of unintentional oversight. ?If it is intentional, I wonder what
> ? ?SM> the rationale is.
>
> Some of us (including me) have strongly argued on several
> occasions that ?global options() settings should *not* have an effect
> on anything "computing" but just on "output"
> i.e. printing/graphing of R results.
> As it is currently, potentially R scripts and R functions may
> only work correctly for one setting of
> ? ? options( stringsAsFactors = * )
> which is against all principles of functional programming.
A similar argument would also seem to apply to defaultPackages,
deparse.max.lines, download.file.method, encoding, expressions, warn
and na.action. There are plenty of functions in R that violate other
principles of functional programming, so, by itself, this argument
seems a little weak to me. There are obviously differences of opinion
about this issue in R core, and it's unfortunate that the user has to
be exposed to them through inconsistent function definitions.
Hadley
--
http://had.co.nz/