Open
Description
I'm working my way through some significant updates to correlation handling, and have some thoughts/questions/requests for comment. (Code is in the ar_memfix branch.)
- Memory allocation error #995 highlights that we are sometimes creating giant correlation matrices, purely for reporting purposes, when we don't really have to. (There are some other issues relating to the creation of giant (dense) contrast matrices, but that's a problem that we will have to deal with in the
reformulaspackage.) - I started by simply chopping out the code that creates the correlation matrices from the
ar1andoucovstructs, e.g. here, only storing thephivalue. - However, I think there should probably be a flag, to be set in
glmmTMBControl(e.g.return_full_corrmat?); the default could be (denoted byNULLvalue?) to return the full corrmat if it would be (say) less than 20x20, or something reasonable. This behaviour should probably apply across all covstruct types. - This is separate from how
VarCorrobjects are constructed on the R side after the model is fitted (VarCorr/mkVC), and howVarCorrobjects are formatted/printed. What should aVarCorrobject actually contain when the covariance matrix is too big to be practical (whenreturn_full_cormatis FALSE)? In some cases it could be a sparse object, but in many cases (e.g. AR1/OU/spatial) it should probably be something like an empty (0x0) numeric matrix ... - I've been writing (S3) methods for printing individual components of VarCorr objects based on their cov structs. These will have to work whether or not the full matrix is available ...
Metadata
Metadata
Assignees
Labels
No labels