jamesdunham / dgo Goto Github PK

The issue is an unexpected error in shape():

shape(item_data = opinion,
  item_names = "affirmative_action",
  time_name = "year",
  geo_name = "state",
  group_names = c("female", "education"),
  modifier_data = states,
  modifier_names = 'prop_hispanic')

#> Error in !all.equal(dimnames(d_in$ZZ)[[2]], colnames(d_in$XX)) : invalid argument type

A change in PR #25 (v0.2.12) made the column order in model arrays XX and ZZ inconsistent when 1) at least two group_names are specified in an order other than alphabetic and 2) geographic modifier_data is used. Validation leads to a error. The solution is to revert the change.

I believe the parameter in this line should be group_name not group_nameS. (The parameter is also referenced in the line below.

At present, xi and gamma are drawn from a prior centered on their value in the previous period. This made sense when the DLM did not include theta_bar[t-1] because it implied a prior belief that the coefficients in the cross-sectional model predicting theta_bar[t] were stable over time. But now that theta_bar[t-1] is in there, xi and gamma serve a different purpose: xi[t] now captures CHANGES in average opinion from t-1, and the gammas how these changes differ across groups. Drawing these coefficients from a prior distribution centered at their previous value thus implies that we think that trends in opinion are likely to be stable over time (e.g., if everyone got more liberal last year, they probably did again this year). In some cases this may be reasonable, but in other cases it may impose too much stability. I have a suspicion that this may be related to the fact that our model sometimes estimates an oscillating pattern in opinion (i.e., a delta_tbar less than 0), which may be its way of compensating for the hierarchical model's overly rigid insistence on persistent trends. A comprehensive fix to this problem may involve a fundamental change to the structure of the DLM, but here are two more targeted solutions:
(1) Add an option to stipulate that xi and gamma should be drawn independently in each period even if separate_t = 0.
(2) Add an option to drop XX * gamma[t] entirely after the first period—i.e., no hierarchical model, just a DLM (though keeping xi).

When I have more cores (e.g. 8) than chains (e.g. 4), the program only uses 4 (equals to the number of chains) cores. Is it possible to make use of all cores to save time?

dgirtIn is an R6 class returned by shape(). Its methods are documented but its fields are not. It'd be particularly helpful to document the fields passed to Stan.

The current behavior is to return poststratified means. In typical use, we want poststratified means and CIs. To make this straightforward, first allow returning poststratified posterior samples. Then summarize the poststratified posterior.

Hi there,

I'm doing some similar modeling for a project of mine, and I'm curious how you manage ordered items. It looks like the following function creates indicators from ordered variables

I'm looking to use the dgo package to estimate latent immigration opinion at the state-level using (C)CES and I noticed that there's no straightforward way to incorporate survey weights, perhaps intentionally (as in, not including that ability is a purposeful exclusion). Does this mean that, if I want to include weights, I'll need run the model sans weights, get the Stan code out of resulting object, and then add the weights bit a la this post?

Thanks beforehand!