model.data for pgls is tricky

[richfitz]

I may be wrong in some of the logic here...

Usually model.data does not depend on the parameters; it's just the data. However, that's not the case for the PGLS fits, where we care about the residuals. This is fine and easy for ML fits, and I have written a residuals method in diversitree that will get this for us.

However, for Bayesian fits, we will need to get new data for every sample that we care about.

Within as.unit.tree.mcmcsamples, produces a multiPhylo object along the samples, so the high level interface will work fine. However, this function currently works by a single call to model.info which produces a single data object, and then going through make.model.phylo, which assumes that the data object is scalar.

I see two options

1. Define a new as.unit.tree.mcmcsamples.pgls (cumbersome, but that is the full method name!)
2. Set things up to work with non-scalar 'data' objects.

There are plusses and negatives to both. If we take the first route then the bits around sampling from the mcmc object need to abstracted or duplicated anyway. If we take the second, then the design gets more complicated if this is only going to affect a single type of fit.

Something to think about.

[mwpennell]

personally i am in favor of option (1) as i think this way it will be simpler for people to add additional model.data objects for new models. prefer just to make things more complex for special cases but am open to being swayed on this if you are in favor of (2)

[richfitz]

Mostly through implementing (1) now. It's simpler with the new mcmc interface.