Is there some way to export the likelihood function for a vector of observations equivalent to the 1st column of the classic Mx MX%P= command?
I am unfamiliar with "MX%P=" but it sounds similar to the vector=TRUE argument of the mxFIMLObjective() function. The demo 'OneFactorModel_LikelihoodVector' has an example of using this argument.
Thanks! That is exactly what I wanted to know.
A related issue:
The documentation shows that mxRAMObjective allows a parameter "vector", but my version mxVersion=="0.3.3-1264" does not implement this parameter. Has this been changed in a more recent version?
0.3.3 is an old version. Install the current 1.0.7 release by following these instructions:
Further, you can install the beta 1.1 release and use/test even newer features like so:
Please download the most recent stable release, which as of July 20, 2011 is OpenMx 1.0.7: source('http://openmx.psyc.virginia.edu/getOpenMx.R').
Although one can use vector=TRUE, it is a bit of a shame that one cannot see the vector of individual likelihoods unless one uses this alternative approach - which involves using an mxAlgebra and mxAlgebraObjective. Unless someone knows another way to retrieve them?
We have talked about this feature for several months. So I implemented it today. In the latest version from the svn repository, I've added the '@likelihoods' slot to MxFIMLObjective and MxRAMObjective objects. It stores a vector with the likelihood values. This will be included in the OpenMx 1.2 release. We need some test cases to verify this feature is working correctly. The ordinal and joint ordinal/continuous implementations are trickier than the continuous implementation, so it would be good to test all three alternatives.
Really superb! So pleased to have this information coming back. The only case when one might not want it to be potentially available would be where bandwidth is a concern and a large raw dataset is being analyzed. In this case one might want to switch it off. This might apply to the contents of other slots, so I am wondering whether an argument of the form
would offer the user control over the volume of information being passed back to R from the backend.
I think mxOption is a better place for this than mxRun.
First of all, we need to limit the number of argument to mxRun to keep complexity down for the user.
Second, this is actually an option that people would want to change for each individual objective function, rather than for each overall run.
Third, it's something that many people will either want to have returned, or just won't care about at all. Since it's fairly cheap to return in the general case, it's unlikely to be changed by many folks. That means that an argument to mxRun runs a higher risk of confusing people than it does of helping them.
I'd recommend instead that we use the mxOption interface the way that we do for the RAM Optimization and Data Sorting; these can be set for each child model or for the parent model as a whole, and we can add options boundlessly without adding too much confusion.
I'd probably also stick to names like "Return Row Likelihoods" so that what they do is clear.