boundary conditions

5 replies [Last post]
carey's picture
Offline
Joined: 10/19/2009

(1) am trying to write R code to deal with boundary conditions. is there a SIMPLE way in which i can create an R object from a fitted MxModel that generates vectors of lower and upper bounds for the free parameters? ( i have code that does it, but it is pretty ugly).

(2) the documentation for MxBounds and mxBounds speak of a 'spec' matrix. the same term also appears in several documents when i do a search. anybody tell me what that is? suggest that you include an example of using a 'spec' matrix in the documentation for mxBounds.

greg

carey's picture
Offline
Joined: 10/19/2009
mike, muchas, muchas many

mike,
muchas, muchas many gracias for doing this. it will eventually be to the user's benefit, but more on that later.
greg

rgore's picture
Offline
Joined: 01/27/2011
In the subversion repository

In the subversion repository trunk, there is now a programmatic method
to determine whether a free parameter is up against a lower boundary
or upper boundary. Use the following:

summ <- summary(modelOut)
lboundMet <- summ$parameters$lboundMet
uboundMet <- summ$parameters$uboundMet

lboundMet is a boolean vector of TRUE/FALSE values if a parameter
estimate is near the lower boundary to within a value of
getOption('mxOptions')[['Feasibility tolerance']]. To
see if either the lower or the upper boundary has been reached, use
lboundMet | uboundMet. When the summary function is
printed, the lower and upper bounds are printed with an asterisk if a
free parameter is up against a boundary.

mspiegel's picture
Offline
Joined: 07/31/2009
Looks like the mxBounds()

Looks like the mxBounds() documentation is out of date. There hasn't been a 'spec' matrix in a MxMatrix object since version 0.1-1. The mxBounds() documentation states "parameters may be referenced either by name or by referring to their position in the 'spec' matrix of an ‘MxMatrix’ object." It should state that parameters are referenced by their name. It would be possible to add support for using a matrix name and the (row,col) pair within the matrix. The rest of the hits on the search for 'spec' matrix are bringing up webpages from version 0.1-1.

I want to confirm that I understand your request. Given a model, traverse through the model and return all the lower bound and upper bound specifications for the free parameters? I can show you some simpler ways to generate this.

carey's picture
Offline
Joined: 10/19/2009
thanks, mike my goal = create

thanks, mike

my goal = create an R object from summary(myMxModel)$parameters that include the lower and upper bounds.

i currently "transverse" through the model, e.g.,
x <- which(myMxModel@matrices[[i]]@free)
theseLBounds <- append(theseLBounds, myMxMatrices@matrices[[i]]@lbound)
but then do beaucoup checking to make certain that the elements in theseLBounds agree with the final parameter estimates in summary(myMxModel)$parameters$Estimate. the problem occurs with parameters with the same label. e.g., if 5 x 5 diagonal matrix has the same label for each of the parameters, then x <- which(myMxModel@matrices[[i]]@free) gives 5 elements that correspond to one row in summary(myMxModel)$parameters. it is this checking that i want to avoid. it is a real bear to see if the code is working correctly.

anyway, OpenMx must have a vector of bounds for the free parameters because the call to NPSOL requires the arguments bl and bu. is there any way to easily access these vectors?

greg

mspiegel's picture
Offline
Joined: 07/31/2009
Umm, you could access the

Umm, you could access the information passed back to the optimizer but it gets a little tricky. So the fitted model has some information under model@runstate$parameters. This is a list of stuff. This top level list contains N inner lists, where N is the number of free parameters. Each inner list contains three elements. The three elements consist of (lower bound, upper bound, and a vector of three numbers to ignore for now). If all your free parameters have labels, the labels are assigned to names(model@runstate$parameters). But this technique will not work for free parameters that do not have labels. In that case, the i_th entry in the top level list corresponds to the i_th row in the summary() function.

I think I will add the lower bound and upper bound to the summary information. But that will not show up until the next OpenMx pre-release and the next major version number.