nutterb / pixiedust

Tables So Beautifully Fine-Tuned You Will Believe It's Magic.
179 stars 18 forks source link

Significance stars #68

Open grantmcdermott opened 7 years ago

grantmcdermott commented 7 years ago

Apologies if this issue already has an answer. (I couldn't find anything in the pixiedust manual.)

How about adding an option for appending significance stars to regression coefficients? Perhaps: "sprinkle(stars...)"

Rightly or wrongly, published regression tables are almost universally expected to come with stars representing statistical significance in addition to standard errors.

In line with most statistical software, defaults could be three stars for p<.0001, two stars for p<.01 and one star for p<.05. I would suggest dropping the "p.value" column as default too, if the sprinkle(stars...) option is called.

nutterb commented 7 years ago

I'm not sure a separate sprinkle for the stars is the direction I would go for this. Aside from my personal feelings that the stars are tacky (I've never included them in anything I've published), I think it becomes rather difficult to allow any flexibility beyond the customary defaults. I think it might be better to to encourage use of the fn sprinkle. One such example that I use would be (notice the last call to sprinkle)

library(pixiedust)

fit <- lm(mpg ~ wt + qsec + am, data = mtcars)

dust(fit) %>%
  sprinkle(pad = 3) %>%
  sprinkle(cols = 2:4,
           round = 3) %>%
  sprinkle(cols = "p.value",
           fn = quote(pvalString(value)))

Where pvalString is a function in pixiedust that does various formatting of the p-values. (see ?pvalString)

image

You could write a similar function that produces the stars, or I'm open to adding a stars argument to pvalString.

Omitting the p-value column

This one gets a little trickier, because I've never really envisioned pixiedust as an engine for adding or dropping rows from a table. In fact, I don't think there's a safe way to do it when you involve the header, footer, and interfoot components. (Dimensional coordination can become a real problem). This is a case where pre-processing probably makes sense; and it wouldn't be difficult to write a function that takes a model, preprocesses it with broom::tidy, and then returns the dusted object. Something like (in pseudocode)

dust_star <- function(fit, ...){
  tidy_fit <- broom::tidy(fit, ...)
  tidy_fit$estimate <- pval_stars(append_to = tidy_fit$estimate, 
                                                 pval_column = tidy_fit$p.value)
  dust(tidy_fit)
}

Thoughts?

grantmcdermott commented 7 years ago

Thanks for the reply. I'll take a look ?pvalString and tinker with it to get stars as needed.

FWIW, I share your personal scepticism w.r.t. the use of stars in regression tables. However, it is still very much a cultural norm in my field (economics), as well as many others. Part of my motivation for filing an issue is that I think pixiedust is great little package and adding this tiny bit of stylistic sugar to the package would encourage wider adoption by researchers. After all, we can be a pretty lazy and conservative bunch.

nutterb commented 7 years ago

That took an unexpected turn. See my gist here where I've added some functionality for stars to pvalString https://gist.github.com/nutterb/4a827cfe2403900d72153451c493ccc6

Running the code in that gist gives me the table depicted below

image

notice that the alignment on the values is off. I'm not sure how to fix that, but it seems that this isn't going to be as straightforward as I had hoped.

grantmcdermott commented 7 years ago

Excellent. Thanks!