Closed finnlindgren closed 1 year ago
Solving #33 would also mean that there would be no need for the extra mdata$y.inla
step in inla.stack.mdata
, as there would already be exactly that information under a special inlabru name. (In fact, inla.stack.mdata
could just be an alias for INLA::inla.stack.data
.
All of the above has been fixed in the development version, except for multicolumn matrix covariate collection support.
This could easily be handled via a mapper class and special model name for "iid with precision set to the fixed effect precision" (also needed for factors), or if "linear" can detect matrix input and change to fixed-precision-iid.
The special model="fixed"
feature solves this.
The
inla.stack.mjoin
function and its relatives ignore subtle internal structures of theINLA::inla.stack
functions, such as keeping track of what is a matrix (or not) in the input. Related to #33 and #34.Some of those features are currently (v2.1.4) likely not accessible via the inlabru model interface, but robustifying the inlabru internals will allow those features later. Having a collection of covariates stored as a multicolumn matrix that can be used directly in a formula instead of specifying each individual covariate is the main such feature.
The main changes are to use inla.stack.LHS() and inla.stack.RHS() instead of directly accessing and/or changing the internal data structure.
The documentation for
inla.stack.mdata
claims thatINLA::inla.stack.data
does not produce a multiple-column observation matrix, but this is incorrect. The issue is that the internal stack data structure is accessed in several places without taking the internal matrix information into account, so that gets lost somewhere on the way, beforeinla.stack.mdata
is called. Usinginla.stack.LHS()
andinla.stack.RHS()
(inla.stack.data()
is simply the union of those two, plus additional user supplied objects) is the supported way of accessing this in a way that reconstructs any matrices that were used asinla.stack
input.inla.stack.e
is not needed at all (relates to #34) since E should be a vector, not a matrix. As far as I can tell, the separately constructed matrix-e is never accessed; inbru.inference.R
, the code isE = INLA::inla.stack.data(stk)$e
, which accesses the regulare
information in the stack, whereasinla.stack.mjoin
places it in a special place that is never accessed (whereas the special "y" is accessed, byinla.stack.mdata
).inla.stack.y
should expand a "y" vector to multicolumn data within each stack. After thatinla.stack.join
will create the correct internal information. By solving #33, there will no longer be any need to store the "y" and "e" separately, as the regular stack structure will have the required information.