coeftab() stores its information inconveniently

[rpruim]

In particular, @coefs can contain SE information (but only if se = TRUE), and @se has lots of NAs when se = TRUE. Seems like it would be better to keep the coefficient estimates in @coefs and the standard errors in @se and paste things together as needed elsewhere, perhaps keeping a flag to indicate whether standard errors were requested.

> coeftab(m6.11, m6.12, m6.13, m6.14, se = TRUE)@se
                      1        NA          3          4
a            0.04068216 0.4707206 0.04870824 0.46761056
log.sigma    0.17149850 0.1714985 0.17149847 0.17149881
bn                   NA 0.6940375         NA 0.72735651
bm                   NA        NA 0.02028697 0.02245899
a.se                 NA        NA         NA         NA
log.sigma.se         NA        NA         NA         NA
bn.se                NA        NA         NA         NA
bm.se                NA        NA         NA         NA
> coeftab(m6.11, m6.12, m6.13, m6.14, se = TRUE)@coefs
             m6.11 m6.12 m6.13 m6.14
a             0.66  0.35  0.71 -1.09
log.sigma    -1.79 -1.80 -1.85 -2.16
bn              NA  0.45    NA  2.79
bm              NA    NA -0.03 -0.10
a.se          0.04  0.47  0.05  0.47
log.sigma.se  0.17  0.17  0.17  0.17
bn.se           NA  0.69    NA  0.73
bm.se           NA    NA  0.02  0.02

Labeling is broken for @se when se = FALSE

> coeftab(m6.11, m6.12, m6.13, m6.14)@coefs
          m6.11 m6.12 m6.13 m6.14
a          0.66  0.35  0.71 -1.09
log.sigma -1.79 -1.80 -1.85 -2.16
bn           NA  0.45    NA  2.79
bm           NA    NA -0.03 -0.10
> coeftab(m6.11, m6.12, m6.13, m6.14)@se
                   1        NA          3          4
a         0.04068216 0.4707206 0.04870824 0.46761056
log.sigma 0.17149850 0.1714985 0.17149847 0.17149881
bn                NA 0.6940375         NA 0.72735651
bm                NA        NA 0.02028697 0.02245899

[bbolker]

with apologies for my ignorance, I wonder if simply writing a broom::tidy method for coeftabs would be more useful. In an ideal world things should be set up so that users don't have to mess around accessing slots directly/shouldn't need to care about how they are organized ...

[jgabry]

And in terms of preparing stuff for plotting, rethinking could just use our (Stan dev team's) bayesplot package similarly to how rstanarm and brms use it. Richard, if you're interested in that let me know and I can help.

On Mon, Mar 13, 2017 at 1:36 PM Ben Bolker notifications@github.com wrote:

with apologies for my ignorance, I wonder if simply writing a broom::tidy method for coeftabs would be more useful. In an ideal world things should be set up so that users don't have to mess around accessing slots directly/shouldn't need to care about how they are organized ...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rmcelreath/rethinking/issues/71#issuecomment-286183968, or mute the thread https://github.com/notifications/unsubscribe-auth/AHb4Q0s0OL--Fw667WXSIKhs2tHkmPKKks5rlX6tgaJpZM4MbN3C .

[rpruim]

My complaints about the internal organization are directed toward creating things like broom::tidy() or fortify(), or as.data.frame() etc., not because I think end users should be accessing slots directly (they should not need to if all of the appropriate accessors are exported from the package). I wanted to write one of these for my students this morning, but realized that it would be much simpler if the underlying data were stored differently, but I didn't have time to figure out whether the changes I would like to make would have cascading effects elsewhere. So I just created a 1-off plot to show the potential downsides of plotting all the coefficients on the same scale.

[rpruim]

@jgabry, does it make sense to use bayesplot for the rethinking::map() models or is that only a solution for the map2stan() models?

[jgabry]

Mostly map2stan, although some of the bayesplot functionality could be useful for map.

On Mon, Mar 13, 2017 at 3:25 PM Randall Pruim notifications@github.com wrote:

@jgabry https://github.com/jgabry, does it make sense to use bayesplot for the rethinking::map() models or is that only a solution for the map2stan() models?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/rmcelreath/rethinking/issues/71#issuecomment-286215966, or mute the thread https://github.com/notifications/unsubscribe-auth/AHb4Q2hNEFzyEo2jiFIvlkgZw5nPKI34ks5rlZgLgaJpZM4MbN3C .