search

RSGInc / RSGHB

Functions for Hierarchical Bayesian Estimation: A Flexible Approach
Other
25 stars 16 forks source link

Fixed effect-only models are bugged #77

Open jeffkeller87 opened 8 years ago

jeffkeller87 commented 8 years ago

Looks like a bug was introduced for fixed effect-only models when code was added for sample-level likelihood calculations. This obviously needs to be fixed but I'd also like to better understand the purpose of these new calculations and the calculations themselves to be better able to integrate them into resultant RSGHB model objects. Specifically, regarding print and summary methods.

ghost commented 8 years ago

Sample-level/upper-level log likelihood is appropriate for model comparisons like the DIC and Bayes factors.

What is this bug? The sample level stuff is a recent addition and hasn't been tested. It is also not on CRAN On Mar 31, 2016 7:18 PM, "Jeff Keller" notifications@github.com wrote:

Looks like a bug was introduced for fixed effect-only models when @jeffdumont https://github.com/jeffdumont added code for sample-level likelihood calculations. This obviously needs to be fixed but I'd also like to better understand the purpose of these new calculations and the calculations themselves to be better able to integrate them into resultant RSGHB model objects. Specifically, regarding print and summary methods.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/RSGInc/RSGHB/issues/77

jeffkeller87 commented 8 years ago

I think the bug is somewhere between lines 166 and 202 of hb.R. I suspect there needs to be logic put in place when gNIV is 0.

Related, but it looks like sLikelihood (which I want to rename to be consistent with ll0 and llf) is calculated at every keeper iteration. Is this intentional? Would it make more sense to calculate it every gINFOSKIP iteration in progreport?

Line 201 adds a call to likelihood, which is going to have big a impact on performance. Can we use the call on line 6, and the resultant p object for this purpose? Wouldn't it make sense to do it here anyway since the value of a at the end of the function is really the set of values for the next iteration?