You are here

MxRAMModel reduces to MxModel

4 posts / 0 new
Last post
brandmaier's picture
Offline
Joined: 02/04/2010 - 20:45
MxRAMModel reduces to MxModel
AttachmentSize
Binary Data classtest.R936 bytes

Hi guys!

I copied the factor analytic example from the OpenMx main website. When I run the model both the original and the resulting model with estimates will have the class MxRAMModel.
However, if I take the same model, add an arbitrary mean structure and mxData of type "raw", the resulting model will only have class "MxModel". To my understanding, it should still be of class MxRAMModel.
Is this a bug or a feature?
I attached my sample code.

cheers,
Andy

tbrick's picture
Offline
Joined: 07/31/2009 - 15:10
Well, it was a feature

Well, it was a feature originally.

A RAM model that is given raw data is automatically converted into a FIML model with the appropriate RAM algebras upon fitting. When it returns, it's a regular MxModel with a FIML Objective. We figured this didn't violate the "Does Only What You Say" (DOWYS) mantra, because you've asked for a RAM model with raw data, and raw-data RAM uses a FIML calculation.

We are changing the model type out from under you, though, which might cause problems for people who aren't expecting it. For example, people who want to fit an intermediate version, add or alter paths, and then run it again starting from the previous fitted values. There are cases where that could be a reasonable strategy to find starting values for a model that takes a long time to run. Once the model returns, mxPath() no longer works on the fitted model.

This issue also came up here: http://openmx.psyc.virginia.edu/thread/821

We still need to do the conversion in order to do the calculation. But it might be possible to return the model to you as the same type it was when you ran it. There's also a question of what to do with the extra algebras that are generated. We've gotten two notes about this in two days. Maybe we should think changing it for the next version.

Okay, user community:

Is anybody actively counting on the fact that they get back a generic MxModel when they fit an MxRAMModel with raw data?

Is there anybody else inconvenienced by it?

mspiegel's picture
Offline
Joined: 07/31/2009 - 15:24
I've checked in a patch to

I've checked in a patch to the trunk that adds the slots "expCov" and "expMean" to the RAM objective function. These slots are populated at the end of optimization with the expected covariance and expected means matrices. The remaining step is to implement RAM in the backend for raw data. I would prefer following that strategy, rather than convert RAM + data to FIML, and then convert the FIML objective back to RAM at the end of optimization.

For the set of users who want RAM converted to FIML, and would rather have "expCov" and "expMean" appear as MxAlgebra statements instead of as slots in the objective function, we can add an option to mxOption() that would enable the old behavior.

mspiegel's picture
Offline
Joined: 07/31/2009 - 15:24
The RAM + raw data

The RAM + raw data transformation has been fixed. See http://openmx.psyc.virginia.edu/2011/05/phasing-out-ram-fiml-transformation