Inconsistent value for attr(model[["se"]], "type")

[vincentarelbundock]

attr(model[["se"]], "type") is inconsistent with the output of etable. The first says “IID” but the second says by: Product:

library(fixest)

mod <- feols(Euros ~ dist_km | Product + Destination + Origin, data = trade)

attr(mod[["se"]], "type")
#> [1] "IID"

etable(mod)
#>                                    mod
#> Dependent Var.:                  Euros
#>                                       
#> dist_km         -47,599.1*** (7,328.6)
#> Fixed-Effects:  ----------------------
#> Product                            Yes
#> Destination                        Yes
#> Origin                             Yes
#> _______________ ______________________
#> S.E.: Clustered            by: Product
#> Observations                    38,325
#> R2                             0.28482
#> Within R2                      0.03063
#> ---
#> Signif. codes: 0 '***' 0.001 '**' 0.01 '*' 0.05 '.' 0.1 ' ' 1

[lrberge]

Hi Vincent,

Inconsistent.... it depends on the viewpoint....

In fixest, unless the argument vcov is explicitly provided by the user the computation of the VCOV is delayed until the user asks for output (e.g. with print, summary, etable, coeplot, etc). This is to avoid computing the default VCOV which may not be the one requested in the end.

In your example, since mod is just the estimation outcome, the default VCOV has not yet been triggered, so only the IID VCOV is stored. The attribute of the SE says IID, because... it's really the IID SE!

library(fixest)
mod = feols(Euros ~ dist_km | Product + Destination + Origin, data = trade)

mod$se
#>  dist_km 
#> 1368.735 
#> attr(,"type")
#> [1] "IID"

se(mod, "iid")
#>  dist_km 
#> 1368.735 

se(mod, "cluster")
#>  dist_km 
#> 7328.605 

Now comes etable: here fixest assumes that the user really wants the default VCOV since no argument vcov has been provided in etable. The function summary is called internally, which procs the computation of the default VCOV which, in this case, is the clustered VCOV.

I understand the annoyance but, from my viewpoint, this is absolutely not inconsistent.
A simple solution is to apply summary to mod which will lead to the result you expect (note that if mod was already a summary [like when vcov is used at estimation time], it would incur no extra processing):

summary(mod)$se
#>  dist_km 
#> 7328.605 
#> attr(,"type")
#> [1] "Clustered (Product)"

[vincentarelbundock]

Thanks Laurent, I didn't realize this was how things work, and it indeed makes a lot of sense.

The fix on my side was super easy, thanks to the info above.