I am trying to run a CFA where one latent variable is regressed on four manifest variables. I am trying to constrain the pattern coefficients ($\lambda$) mean to equal one, according to Kline's (2015, p. 200) effects coding method:
$$ \frac{\lambda_1 + \lambda_2 + \lambda_3 + \lambda_4}{4} = 1 $$
Below is a code example. I tried adding an mxConstraint() function in mxModel() but the syntax is not correct. How can I apply the constraints properly?
library(OpenMx) data <- mxData(observed = mydata, type="raw") # residual variances res_var <- mxPath( from = paste0("x", 1:4), arrows = 2, free = TRUE, values = 1, labels = paste0("e_x", 1:4) ) # latent variance lat_var <- mxPath( from = "L", arrows = 2, free = TRUE, values = 1, labels = c("var_L") ) # factor loadings fac_loads <- mxPath( from = "L", to = paste0("x", 1:4), free = c(TRUE, TRUE, TRUE, TRUE), values = 1, arrows = 1, label = paste0("L__x", 1:4) ) # means means <- mxPath( from = "one", to = c(L, paste0("x", 1:4), arrows = 1, free = FALSE, values = 0, labels = c(paste0("mean_", student_sci_ach), "mean_stSCI") ) model <- mxModel( "My Model", type = "RAM", manifestVars = paste0("x", 1:4), latentVars = "L", data, var, lat_var, fac_loads, means, # I tried defining a constraint here, but this obviously doesn't work. mxConstraint(mean(paste0("L__x", 1:4)) == 1) ) results <- mxRun(model) summary(results) <\blockcode>
Printer-friendly version
In an MxConstraint, both sides of the comparator (
=in this case) have to be valid MxAlgebra-like expressions, evaluable in the MxModel's namespace; mere character strings aren't accepted. Try something like this:That worked after I added an extra line
model <- omxAssignFirstParameters(model)to copy the values in theAmatrix intoLmat.That is one way to avoid trying to start parameters at different values when they appear in different places in the model. Good solution, although it's a bit less controllable than manually setting parameters to the same value wherever they appear, in this case I think changing the mxMatrix line to
Use of omxAssignFirstParameters() means that you don't actually know which starting value was used. Sometimes that's ok, but, (e.g., to debug bad starting values) it's not always ideal.