Mixture distribution, zygosity example

8 replies [Last post]
neale's picture
Offline
Joined: 07/31/2009

I seem to have this almost working but for a pesky error:

Error: The job for model 'twinACE' exited abnormally with the error message: Objective returned invalid value.
Execution halted

Script and data files attached (albeit with an extra _ in the name of the latter, ffs).

AttachmentSize
sim1.mz_.txt29.08 KB
acemix.R2.66 KB
sim1.dz_.txt29.09 KB
mspiegel's picture
Offline
Joined: 07/31/2009
Right. One strategy for

Right. One strategy for allowing the whole vector of definition variables is to allow the data to appear in the matrix algebras. Well, and we need a mechanism for pulling a column out of a matrix. Plus we need something sane for the case where the data is a data.frame.

Mike N: It almost seems to me that we should be able to refer to definition variables as either the whole vector of them

mspiegel's picture
Offline
Joined: 07/31/2009
Umm, don't we assume that

Umm, don't we assume that algebras are calculated once per optimization iteration? This restriction would prohibit us from using definition variables, as we don't know which value of the definition value should be selected. A follow up question: should we allow the use of data sets in matrix algebra computations? Something like:

alg <- mxAlgebra(model.data %*% B, "alg")

neale's picture
Offline
Joined: 07/31/2009
Ok I think I got it going.

Ok I think I got it going. However, it was quite a bit of a fiddle. I've put it into trunk/models/passing/Acemix2.R

There's a slight disconnect in that a definition variable routinely appears as a 1x1 matrix as far as mxAlgebras are concerned, so to get a vector, as in the vector of likelihoods, we have to work with a separate dataframe, not a definition variable extracted from the mxData() command.

It almost seems to me that we should be able to refer to definition variables as either the whole vector of them (as needed for this weighted likelihood example) or to the individual level elements, which change with each evaluation.

Some distinction between def as a vector and def(i) as a scalar for the ith record in the sample would be required.

neale's picture
Offline
Joined: 07/31/2009
I now have another problem.

I now have another problem. Suppose I want to use a definition variable in the mxAlgebra that is operating on the vector of likelihoods coming back from an mxModel's mxFIMLObjective. For example, with code snippet:

mxModel("MZlike",
mxData(DataMZ, type="raw"),
mxFIMLObjective("twinACE.expCovMZ", "twinACE.expMean",selVars, vector=T)),
mxModel("DZlike",
mxData(DataMZ, type="raw"),
mxFIMLObjective("twinACE.expCovDZ", "twinACE.expMean",selVars, vector=T)),

mxAlgebra(-2*sum(log(MZlike@DataMZ.pMZ%x%MZlike.objective + (1-MZlike@DataMZ.pMZ)%x%DZlike.objective)), name="twin"),
mxAlgebraObjective("twin"))

The mxAlgebra complains that it can't find DataMZ.pMZ. Is there some way I can get a hold of it? I've tried going down the path of
twinACEFit@submodels$MZcorrect@data
but I don't seem to be able to reference the dataframe or matrix's third column.
MZlike@DataMZ[,3] doesn't work, nor does
twinACEFit@submodels$MZcorrect@data$pMZ)
nor
twinACEFit@submodels$MZcorrect@data@pMZ)

and I'm running out of ideas.

Steve's picture
Offline
Joined: 07/30/2009
As far as I know, mxAlgebras

As far as I know, mxAlgebras do not have access to mxData columns. I am not exactly sure why that is. Perhaps Michael Spiegel can let us know about that.

In the mean time, you can always create an mxMatrix for use in your algebra:

> # ----------------------------------
> # Create the data frame.
> 
> tFrame <- data.frame(x=c(1:10))
> 
> # ----------------------------------
> # Create a test model, matrix, and algebra.
> 
> tModel <- mxModel("testModel", 
+     mxData(tFrame, type="raw"), 
+     mxMatrix(type="Full", nrow=length(tFrame$x), 
+         ncol=1, values=tFrame$x, name="x"),
+     mxAlgebra(-2*log(x), name="lumber")
+ )
> 
> # ----------------------------------
> # Evaluate the elements of the model.
> 
> mxEval(lumber, tModel, compute=TRUE)
           [,1]
 [1,]  0.000000
 [2,] -1.386294
 [3,] -2.197225
 [4,] -2.772589
 [5,] -3.218876
 [6,] -3.583519
 [7,] -3.891820
 [8,] -4.158883
 [9,] -4.394449
[10,] -4.605170

mspiegel's picture
Offline
Joined: 07/31/2009
I checked in a patch so that

I checked in a patch so that the error message will now tell you if the objective function is returning NaN or it is returning an infinite value.

neale's picture
Offline
Joined: 07/31/2009
A great patch that. For some

A great patch that. For some reason, the script now works when all I was expecting was better debugging information!

tbates's picture
Offline
Joined: 07/31/2009
:-) "Your error was

:-)

"Your error was interesting: code 2 with little bit of 4 and 7 - Anyhow, I patched myself to cope with this in future, ran the script and emailed you the results in Molecular Psychiatry format.. hope that's OK,
Yours,
O. Supermodeler"