search

daijiang / phyr

Functions for phylogenetic analyses
https://daijiang.github.io/phyr/
GNU General Public License v3.0
30 stars 10 forks source link

Bayes fix (plus Poisson support) #12

Closed rdinnager closed 6 years ago

rdinnager commented 6 years ago

Hi Daijiang,

I've fixed the Bayesian implementation to work with the new bipartite syntax and random.effects object. You may have noticed I also allowed for a new type of element in the random.effects with length 2. This is just so it is possible to specify a 'random slopes' (or as I prefer, 'random weights') model with a custom full covariance matrix. In this case the user can put the covariate in the first slot, and the sparse matrix in the second. This is mostly for my own purposes at the moment, it shouldn't effect anything else, and probably shouldn't be exposed to the user at the moment because I haven't done any tests yet.

While I was at it, I added support for the Poisson family to the Bayesian version, because this is the easiest family (no extra parameters). It is possible to do an 'over-dispersed' Poisson model by adding an (1|row_id) random effect, where row_id is a unique id for each row in the data. This can alternatively be accomplished by adding (1|sp@site) to the formula, avoiding the need to add a new row id column to the data. I think I'll next add negative binomial, and then a zero-inflated Poisson, which will be the most challenging, but I think will also increase the generality of the model for ecological data the most.

I also want to submit some ggplot2 based plotting functions. Just wanted to check you are okay with this? I'll have to add ggplot2 (and possibly some ggplot2 extension packages, such as ggtree) to the Imports.

Cheers, Russell

rdinnager commented 6 years ago

Oh yeah, and I forgot to mention, I tested this with removing the bayes = TRUE workaround in the prep_dat_pglmm function and it does work, so you can remove that if you like. I left it in, just because it is possible that using the old structure might be slightly more efficient in the INLA call. I don't think it will make too much difference though, so if you'd prefer to simplify the code by removing it, then it should be no problem.