cboettig
commented
11 years ago From @eastman:
The source for updated geiger is on CRAN (binaries to soon follow). There are a couple methods (coef and logLik) that can be applied to fitContinuous and fitDiscrete results. The classes returned differ for multiple traits ("gfits") and single traits ("gfit"), so other methods can be built easily.
fitContinuous returns different kinds of objects when it's given a matrix of traits vs when it's given a vector from that matrix. I can check this case (e.g. looking for the name of the first element) but feels a bit fragile -- ideally the return structure would be the same?
A lot of the wrapping that pmc does around the gieger package is to give a more object-oriented flavor to the fitContinuous return type. e.g. given the output of a fitContinuous fit, it's nice to have methods associated with that output that can simulate, refit (given a new data file, all else constant, or refit with some argument updated). Whatever else it may be, OUCH is a good example of this (though happy to have S3 instead of S4 classes).
Is that something you would consider doing? Right now, the geiger functions ("api") do not provide a consistent way to extract this information. e.g. I used to pull the brownian motion value out of fit[[trait_index]]$beta, now it is in fit$[[trait_index]]$opt$sigmasq. Geiger could instead define functions to access this information, (coef is a standard S3 type for this purpose) that could extract this.
The advantage of such an approach is if you change the back-end arbitarily (e.g. rename all the coefficients; like I think root become z0, lnl became lnL, etc), any code using your API (e.g. getting the coefs with coef, the likelihood with logLik, etc) can also be adjusted on the backend so that they don't break anything. (Not just to make my life easier -- lots of users have scripts that never see the light of day that get broken too...)
Lots of R methods have this structure, with methods
simulate,update,logLik,coef, etc etc. Having these available for Geiger fits would be a huge help, both in terms of making the adjustments to PMC and in general for users to take advantage of other R code and have a more stable and reproducible interface.I hope that doesn't sound like too much of a criticism, and of course I'll understand if now isn't the time for such a change. I might just depricate pmc though until then, since it seems a bit silly to keep writing external wrappers for geiger's interface. (let's be honest, pmc does mostly trivial stuff, so I'm guessing it has only a handful of users...)