Dear all,
I am trying to get a grip on the mxConstraint function. I played around with it a bit and encountered a strange thing. I fitted a model in which different parameters are constrained to be the same. When i specified this with the labels (i.e. both parameters are labeled "b11"), it worked fine.
However, when i try to do this with the mxConstraint function (i.e. the parameters are labeled "b11" and "b13", and I specified mxConstraint("b11"=="b13")), the parameter estimates change. Although the changes are very small I think this is strange. Another thing is that the estimates of all other parameters in the model change as well.
Does anyone have an idea, what could be a reason for this, and how I could overcome the problem?
Thanks for your help and greetings
Jan
Hmm. A couple of issues are occurring together in this example. If a constraint were to be used in this model, it should be specified as
mxConstraint(b11 == b13)
without the double quotes. Quotes should appear only as label names when referencing a matrix row or column, such asmxAlgebra(A['blue', 'cola'])
. Sorry, you've found a bug the mxConstraint() with the quotes should be throwing an error.However, if you have two free parameters and would like to make them equal, we strongly recommend renaming the two free parameters to the same name. mxConstraint() specifies constraints to the numerical optimizer. Which is why equality constraints are not exactly equal to each other: see here.
TODO: modify the function omxSetParameters() to allow the user to rename a parameter. Don't know why we didn't think of that earlier.
The 'newlabels' argument has been added to the omxSetParameters() function in the source code repository. In the next binary release, it will be possible to rename a free or fixed parameter with this function. Here as an example:
Oooh... This is going to be useful!
Pity it can't work with NAs, but still: very helpful helper!!
Also nice that in this example:
model <- omxSetParameters(model, c('a', 'b'), newlabels = c('b', 'a'))
The changes look like they should countermand each other (i.e., a->b, but then the new b's go back to a? But that is avoided - it works as desired rather than as expected :-)
Just need to get people used to
a. using labels so they can address cells
b. thinking omxSetParameters() instead of "Drop @"