Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-25 Thread Gabor Grothendieck
On Mon, Jan 25, 2010 at 10:36 AM, Terry Therneau wrote: > Kudos to Peter for actually answering the question of why the > inconsistency was there.  It might be well to add a bit to the > documentation. > >  As to the larger discussion of global defaults let me offer two > opinions: >  1. They are

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-25 Thread Terry Therneau
Kudos to Peter for actually answering the question of why the inconsistency was there. It might be well to add a bit to the documentation. As to the larger discussion of global defaults let me offer two opinions: 1. They are the salvation of those of us who do not agree with certain global de

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-23 Thread hadley wickham
On Sat, Jan 23, 2010 at 5:12 AM, Peter Dalgaard wrote: > Stavros Macrakis wrote: >> >> Martin, >> >> I agree that global options settings that affect computations are >> problematic. >> >> But that's not the issue I was addressing.  If for some classes, >> func.CLASS >> has certain defaults for so

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-23 Thread Peter Dalgaard
Stavros Macrakis wrote: Martin, I agree that global options settings that affect computations are problematic. But that's not the issue I was addressing. If for some classes, func.CLASS has certain defaults for some arguments, it is surprising that for other classes, it has different defaults,

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-22 Thread Stavros Macrakis
Martin, I agree that global options settings that affect computations are problematic. But that's not the issue I was addressing. If for some classes, func.CLASS has certain defaults for some arguments, it is surprising that for other classes, it has different defaults, whether these defaults ar

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-22 Thread S Ellison
>> Some of us (including me) have strongly argued on several >> occasions that global options() settings should *not* have an effect >> on anything "computing" ... > ... Global options are less of a problem where a function allows them to be overridden by the user or programmer. If something is

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-22 Thread hadley wickham
>> 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

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-22 Thread hadley wickham
On Fri, Jan 22, 2010 at 2:17 AM, Martin Maechler wrote: >> "SM" == Stavros Macrakis >>     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

Re: [Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-22 Thread Martin Maechler
> "SM" == Stavros Macrakis > 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 d

[Rd] Inconsistency in as.data.frame.table for stringsAsFactors

2010-01-21 Thread Stavros Macrakis
I noticed that in as.data.frame.table, the stringsAsFactors argument defaults to TRUE, whereas in the other as.data.frame methods, it defaults to default.stringsAsFactors(). The documentation and implementation agree on this, so this is not a bug. However, I was wondering if this disparity was in