1

I noticed that I get different results when using MASS::glm.nb as opposed to library(MASS) and then glm.nb. I thought that package::function() would be a good way to avoid namespace conflicts (functions with the same name in different packages used in the same script) and that the results would be equivalent to library(package) and function.

Can anybody explain me why these options lead to different results? Is this a particular issue to do with MASS or can we expect similar behaviour in other packages?

fm_nb_1 <- MASS::glm.nb(mpg ~ cyl+hp, data = mtcars)

library(MASS)
fm_nb_2 <- glm.nb(mpg ~ cyl+hp, data = mtcars)

identical(fm_nb_1,fm_nb_2)
[1] FALSE

Also, the first version cannot be printed with stargazer, while the second version can.

stargazer::stargazer(
  fm_nb_1
  , type = "text"
)

This gives: % Error: Unrecognized object type.

However, this gives a nice output:

stargazer::stargazer(
  fm_nb_2
  , type = "text"
)

Output:

==============================================
                      Dependent variable:     
                  ----------------------------
                              mpg             
----------------------------------------------
cyl                         -0.102**          
                            (0.043)           

hp                           -0.001           
                            (0.001)           

Constant                    3.790***          
                            (0.146)           

----------------------------------------------
Observations                   32             
Log Likelihood              -84.287           
theta             894,228.600 (23,863,364.000)
Akaike Inf. Crit.           174.574           
==============================================
Note:              *p<0.1; **p<0.05; ***p<0.01
iunda
  • 89
  • 7

2 Answers2

3

If you use all.equal(fm_nb_1, fm_nb_2), you get:

[1] "Component “call”: target, current do not match when deparsed"

You can see that the calls are different when you inspect the objects:

Call:  MASS::glm.nb(formula = mpg ~ cyl + hp, data = mtcars, init.theta = 894228.647, 
    link = log)

and

Call:  glm.nb(formula = mpg ~ cyl + hp, data = mtcars, init.theta = 894228.647, 
    link = log)

Otherwise, the models are identical:

anova(fm_nb_1, fm_nb_2)

Likelihood ratio tests of Negative Binomial Models

Response: mpg
     Model    theta Resid. df    2 x log-lik.   Test    df LR stat. Pr(Chi)
1 cyl + hp 894228.6        29       -166.5738                              
2 cyl + hp 894228.6        29       -166.5738 1 vs 2     0        0       1
tmfmnk
  • 38,881
  • 4
  • 47
  • 67
  • Thanks for taking the time to answer this. But I think my question is not answered: There are differences – maybe structural in nature rather than with respect to the content of the models. These differences do have consequences, e.g., when trying to print the information using stargazer. So it's not trivial. I really wonder why this happens and how often the differences cause problems. – iunda Oct 21 '19 at 09:52
  • 1
    As @jay.sf mentioned, the problem is caused by how `stargazer` handles these different calls. It is not really a problem related to the models or the `MASS` library. On the other hand, without looking into the source code of `stargazer`, it is hard to tell what exactly is the problem. – tmfmnk Oct 21 '19 at 10:52
  • Thanks, and agreed, this is not a problem of the `MASS` library. But I still struggle to understand why `MASS::glm.nb` (or any other function of this package) returns a different object than `library(MASS)`and then `glm.nb`. This seems very strange to me and it would be nice to know why this happens and how often this may lead to problems. – iunda Oct 21 '19 at 14:08
1

The only difference is the fm_nb_1$call and fm_nb_2$call, where in the former appears the suffix MASS::. It seems that stargazer has problems with it, whereas texreg::screenreg hasn't. Try texreg::screenreg(fm_nb_1). Or try fm_nb_1$call <- fm_nb_2$call and then again with stargazer.

jay.sf
  • 60,139
  • 8
  • 53
  • 110