search

sambrilleman / rstanarm

rstanarm R package for Bayesian applied regression modeling
http://mc-stan.org/interfaces/rstanarm.html
GNU General Public License v3.0
0 stars 1 forks source link

Lagged etaslope association structure #22

Open jburos opened 7 years ago

jburos commented 7 years ago

Summary:

Currently the assoc allows for a lagged etavalue but not a lagged etaslope. For various modeling tasks, it can be helpful to be able to lag both the etavalue & etaslope.

Description:

It has not yet been decided what the user interface for this might look like.

For comparison, the following are currently supported:

# association of current eta-value & eta-slope
assoc = c("etavalue", "etaslope")

# lagging eta-value with & without current slope
assoc = c("etalag(8)")
assoc = c("etalag(8)", "etaslope")

# error-free baseline marker value & current slope
assoc = c("shared_coef(1)", "etaslope")
sambrilleman commented 7 years ago

My suggestion for the interface would be that we deprecate "etalag"/"mulag" and instead introduce a set of association structures: "etavalue_lag" "etaslope_lag" "etaauc_lag" "muvalue_lag" "muslope_lag" "muauc_lag"

More generally, this would mean that any of the association structures with a _* suffix also require the user to specify additional details in parentheses. For example: "etavalue_lag(8)" "etaslope_lag(8)" "etavalue_data(~ gender + trt)" "etavalue_etavalue(2)" "etavalue_muslope(2)"

jburos commented 7 years ago

@sambrilleman I agree with this approach in general. This could likely provide a natural extension to support additional parameterizations within the parenthesis, such as weights on the auc, etc.

One alternative I considered was to treat "lag" like a function applied to the value, so it would look something like:

assoc = "lag(etavalue, 8)" or assoc = lag(etavalue, 8)

But I'm not sure how well this would extend to options like "etavalue_etavalue(2)". What you have above seems more flexible.

sambrilleman commented 7 years ago

I'm going to add a wontfix label to this issue for now, since the temporary approach has been to add a lag argument to stan_jm as described mostly by this commit. I think this approach to the lagged association structure is likely sufficient for now. In a later version of rstanarm, we could always extend this if deemed necessary.

Let me know if you think otherwise.