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