[Rd] Regression stars

[Duncan Murdoch]

On 12/02/2013 10:40 AM, Ben Bolker wrote:
> On 13-02-12 09:20 AM, Uwe Ligges wrote:
> >
> >
> > On 12.02.2013 14:54, Ben Bolker wrote:
> >> Duncan Murdoch <murdoch.duncan <at> gmail.com> writes:
> >>
> >>    [snip]
> >>>
> >>> Regarding stringsAsFactors:  I'm not going to defend keeping it as is,
> >>> I'll let the people who like it defend it.
> >>
> >>    Would someone (anyone) like to come forward and give us a defense
> >> of stringsAsFactors=TRUE -- even someone who doesn't personally like
> >> it but would like to play devil's advocate?
> >
> > Sure:
> > I will have to change all my scripts, my teaching examples, my book, and
> > lots of code examples for research and particularly consulting jobs.
> >
> > Personally, I think having stringsAsFactors=TRUE is not too bad for
> > read.table() but less useful for data.frame().
> >
> > And since you ask for the devil's advocate already, related to the
> > subject line: Removing stars is horrible for consulting: With all those
> > people from biology, medicine and other fields who even ask us questions
> > in term of significance stars that are obviously very common for them.
> > Many of them will certainly ask us for the stars, and ask us to switch
> > to another software product once they do not get it from R. They may not
> > be interested in being taught about the advantages or disadvantages of
> > p-values or stars.
> >
> > There are different use cases of R, and I want to keep stars for
> > consulting tasks where things have to be delivered within minutes. I am
> > happy with or without for teaching, where I have the time and can easily
> > talk about the sense and nonsense of p-values.
> >
> >
> > Best,
> > Uwe
>
>    Thanks, Uwe.
>    Now let me go one step farther.
>
>    Can you (or anyone) give a good argument **other than backward
> compatibility** for keeping the stringAsFactors=TRUE argument on
> data.frame()?

I can, under two assumptions:

   1.  We keep stringsAsFactors=TRUE on read.table().
   2.  We keep the stringsAsFactors argument in data.frame().

Under those assumptions, it would just be confusing to have opposite 
defaults.  (Just in case someone hasn't read all of this thread: I'd be 
happier to have the default be FALSE in both cases, but not until 
3.1.x.  For 3.0.x I think I'd just change the default value of 
default.stringsAsFactors() to FALSE, so people could easily get the old 
behaviour.)

Duncan Murdoch

>
>    I appreciate your distinction between data.frame() and read.table()'s
> use of stringAsFactors, and I can see that there is some point for
> quick-and-dirty interactive use in setting all non-numeric variables to
> factors (arguing that wanting non-numerics as factors is somewhat more
> common than wanting them as strings).
>
>    It might be nice to add an optional stringsAsFactors (and check.names)
> argument to transform(): I've had to write my own Transform() function
> to allow the defaults to be overridden, since transform() calls
> data.frame() with the defaults.  (Setting the stringsAsFactors option
> globally would work, although not for check.names.)
>
>    Ben BOlker
>
> >
> >>
> >>> What I will likely do is
> >>> make a few changes so that character vectors are automatically changed
> >>> to factors in modelling functions, so that operating with
> >>> stringsAsFactors=FALSE doesn't trigger silly warnings.
> >>>
> >>> Duncan Murdoch
> >>>
> >>
> >>   [apologies for snipping context: "gmane made me do it"]
> >>
> >> ______________________________________________
> >> R-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-devel
> >>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel