Regression stars

To clarify, I favor changing the defaults for stringsAsFactors and
show.signif.stars to FALSE in R-3.0.0, and view any attempt to remove
either functionality as a seemingly simple but fundamentally misguided idea.

This is just my opinion, of course.  The change could easily be accompanied
by a startup notice or release notes indicating that the changes have been
made, and can be reverted to past behavior if the user so desires.  Perhaps
more users will investigate the various settings, as a happy side effect.

My thanks to everyone who spends time supporting and working on R-core.



On Sat, Feb 9, 2013 at 12:44 PM, Tim Triche, Jr. <tim.triche at gmail.com>wrote:

Changing the default for show.signif.stars should be sufficient to ensure
that, if people are going to get themselves into trouble, they will have to
do it on purpose.  It's just a visual cue; removing it will not remove the
underlying issue, namely blind acceptance of unlikely null models and
distributions.

For any complex problem, there is a solution that is simple, elegant, and
wrong.  As grants and careers can depend on these magic numbers, Upton
Sinclair might save everyone some trouble... It is difficult to get a man
to understand something, when his salary depends upon his not
understanding.

stringsAsFactors, however, is responsible for an endless stream of mildly
irritating misunderstandings, and defaulting that to FALSE would be very
nice.

Just my $0.02.  Defaults are one of the most powerful forces in the
universe.

Also, I liked your book.



On Sat, Feb 9, 2013 at 10:48 AM, Norm Matloff <matloff at cs.ucdavis.edu>wrote:

Thanks for bringing this up, Frank.

Since many of us are "educators," I'd like to suggest a bolder approach.
Discontinue even offering the stars as an option.  Sadly, we can't stop
reporting p-values, as the world expects them, but does R need to cater
to that attitude by offering star display?  For that matter, why not
have R report confidence intervals as a default?

Many years ago, I wrote a short textbook on stat, and included a
substantial section on the dangers of significance testing.  All three
internal reviewers liked it, but the funny part is that all three said,
"I agree with this, but no one else will." :-)

Norm

--
*A model is a lie that helps you see the truth.*
*
*
Howard Skipper<http://cancerres.aacrjournals.org/content/31/9/1173.full.pdf>

Regarding stringsAsFactors:  I'm not going to defend keeping it as is, 
I'll let the people who like it defend it.  

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

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?

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"]

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

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@

 mailing list

R-devel@

 mailing list

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

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"]

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

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@

 mailing list

R-devel@

 mailing list

Uwe I've been consulting for decades and have never once been asked for such
stars.

And when a clinical researcher puts a sentence in a study protocol
that P<0.05 will be considered "significant" I get them to take it out.

Frank

Uwe Ligges-3 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

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@

  mailing list

R-devel@

  mailing list

-----
Frank Harrell
Department of Biostatistics, Vanderbilt University
--
View this message in context: http://r.789695.n4.nabble.com/Regression-stars-tp4657795p4658268.html
Sent from the R devel mailing list archive at Nabble.com.

Uwe I've been consulting for decades and have never once been asked 
for such stars.

And when a clinical researcher puts a sentence in a study protocol 
that P<0.05 will be considered "significant" I get them to take it out.

Frank

Uwe Ligges-3 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

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@

  mailing list

R-devel@

  mailing list

-----
Frank Harrell
Department of Biostatistics, Vanderbilt University
--
View this message in context: 
http://r.789695.n4.nabble.com/Regression-stars-tp4657795p4658268.html
Sent from the R devel mailing list archive at Nabble.com.

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

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"]

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 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"]

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 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"]

fs <- c('apple','peach','watermelon','spinach','persimmon','potato','kale')
n <- 1000000

a1 <- data.frame(f=sample(fs,n,replace=TRUE), x1=rnorm(n), x2=rnorm(n), stringsAsFactors=TRUE)
a2 <- data.frame(f=sample(fs,n,replace=TRUE), x1=rnorm(n), x2=rnorm(n), stringsAsFactors=FALSE)

fn <- function(i,x) x[x$f %in% c('kale','spinach'),]
system.time(z <- sapply(1:100, fn, a1))

system.time(z <- sapply(1:100, fn, a2))

 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 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"]

I thought that the default was the way it was for performance reasons. For large data.frames or repeated applications, using factors should be faster for non-trivial strings.

I thought that the default was the way it was for performance reasons. For large data.frames or repeated applications, using factors should be faster for non-trivial strings.

fs <- c('apple','peach','watermelon','spinach','persimmon','potato','kale')
n <- 1000000

a1 <- data.frame(f=sample(fs,n,replace=TRUE), x1=rnorm(n), x2=rnorm(n), stringsAsFactors=TRUE)
a2 <- data.frame(f=sample(fs,n,replace=TRUE), x1=rnorm(n), x2=rnorm(n), stringsAsFactors=FALSE)

fn <- function(i,x) x[x$f %in% c('kale','spinach'),]
system.time(z <- sapply(1:100, fn, a1))

  user  system elapsed 
19.614   4.037  24.649 

system.time(z <- sapply(1:100, fn, a2))

  user  system elapsed 
19.726   7.715  36.761 

system.time(z <- sapply(1:100, fn, a1))

rm(z)
gc()

system.time(z <- sapply(1:100, fn, a2))

On Feb 12, 2013, at 10:40 AM, Ben Bolker <bbolker at gmail.com> wrote:

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 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"]

On Feb 12, 2013, at 17:05 , Brian Lee Yung Rowe wrote:

I thought that the default was the way it was for performance reasons. For large data.frames or repeated applications, using factors should be faster for non-trivial strings.

I think not. Historically, it's more like "In statistics we have two kinds of variables, numerical and categorical. OK, so we have the occasional truly character-type variables like name and address, let's handle those as a special case".

On 02/12/2013 08:20 AM, peter dalgaard wrote:

On Feb 12, 2013, at 17:05 , Brian Lee Yung Rowe wrote:

I thought that the default was the way it was for performance reasons. For large data.frames or repeated applications, using factors should be faster for non-trivial strings.

I think not. Historically, it's more like "In statistics we have two kinds of variables, numerical and categorical. OK, so we have the occasional truly character-type variables like name and address, let's handle those as a special case".

<sarcasm>

Since character vectors are sooooo bad and people use them where
they should instead use a factor, I propose to go all the way and
by adding the stringsAsFactors arg to character() too. That way
people are put on the right track from the very start.

</sarcasm>

No seriously, if my variable is categorical, it's already in a factor
and that's how I pass it to data.frame(). But if I have it in a
character vector, it's because that's how I want it. It's my choice.
How could anybody ever think that having data.frame() alter his/her
data is a good thing?

Please *remove* the stringsAsFactors arg of data.frame() in R 3.0.
You'll do a big favor to your user base.

On 12/02/2013 1:47 PM, Herv? Pag?s wrote:

On 02/12/2013 08:20 AM, peter dalgaard wrote:

On Feb 12, 2013, at 17:05 , Brian Lee Yung Rowe wrote:

I thought that the default was the way it was for performance

reasons. For large data.frames or repeated applications, using factors
should be faster for non-trivial strings.

I think not. Historically, it's more like "In statistics we have two

kinds of variables, numerical and categorical. OK, so we have the
occasional truly character-type variables like name and address, let's
handle those as a special case".

<sarcasm>

Since character vectors are sooooo bad and people use them where
they should instead use a factor, I propose to go all the way and
by adding the stringsAsFactors arg to character() too. That way
people are put on the right track from the very start.

</sarcasm>

I think you are misreading what Peter wrote.  He wasn't defending that
point of view, he was describing it.

No seriously, if my variable is categorical, it's already in a factor
and that's how I pass it to data.frame(). But if I have it in a
character vector, it's because that's how I want it. It's my choice.
How could anybody ever think that having data.frame() alter his/her
data is a good thing?

Please *remove* the stringsAsFactors arg of data.frame() in R 3.0.
You'll do a big favor to your user base.

That's a really bad suggestion -- it would break code for people who set
stringsAsFactors=FALSE as well as those who rely on the current default
behaviour.   We certainly won't do that.

Duncan Murdoch

I think you are misreading what Peter wrote.  He wasn't defending that point of view, he was describing it.

On Feb 12, 2013, at 20:19 , Duncan Murdoch wrote:

I think you are misreading what Peter wrote.  He wasn't defending
that point of view, he was describing it.

Yes. However, that being said, there is the point that the whole
thing has been designed to work within the paradigm that I described,
and, for better or worse, things are reasonably coherent and
consistent within that framework.

The thing that always worries me, when people get bothered by some
aspect of software design, is that, if you change only that aspect,
you may find yourself with something that is incoherent and
inconsistent. I have quite a few times found myself realizing that
"Uncle John was right after all".

For instance, if you change the paradigm to say that "character
variables are character, unless explicitly turned into factors", and
then ameliorate the inconvenience by changing code that relies on
factors to convert character variables on the fly, then you will lose
the otherwise automatic consistency of level sets between subsets of
data. (So, the math department not only has zero female professors,
the entire female gender ceases to exist for that subgroup.)