Main menu
You are here
Improperly specified threshold matrices need to be detected and handled
Wed, 01/13/2010 - 13:41 — neale
Somehow, even with all the parameters fixed, I cannot escape from a region where OpenMx thinks the ordinal FIML is infinite. As far as I know, the likelihood should not be infinite for these particular parameter values.
| Attachment | Size |
|---|---|
 mddndzf.txt | 3.34 KB |
 BivariateTwinAnalysisOrdinal_MatrixRaw.R | 4.42 KB |
Reporter:
Created:
Wed, 01/13/2010 - 13:41
Updated:
Tue, 10/25/2011 - 12:40
- Log in or register to post comments
Printer-friendly version
Comments
#1
might be dum... but are you not accidentally reading the same data into both mz and dz groups?
mzfData <- read.table("mddndzf.txt", ...)
dzfData <- read.table("mddndzf.txt", ...)
#2
Yeah, for testing purposes only. Should get CE model fitting well :)
#3
Looks like OpenMx is having difficulty with the threshold algebra. This does reflect an open bug--this case needs to be caught and handled, either by an automatic correction or by throwing an error. In the meantime, it can be easily corrected with only slight modifications to the code.
By OpenMx's official specification, any non-threshold values in the threshold matrix must be NA. The Mx1 way of constructing thresholds by building a deviation matrix and multiplying by a lower triangular matrix of ones clashes with this if variables with different numbers of thresholds are included.
I'm attaching an updated version of the code that separates variables by the number of thresholds, handles each calculation separately, and then combines the matrices together again into a single threshold matrix. This requires one new matrix and one new algebra.
#4
Changed title of issue, and changed type to bug report.
When a threshold matrix for ordinal FIML is improperly specified, OpenMx should either correct the misspecification or throw an error. An example of a misspecification that does not throw an error is included in the original issue post.
#5
Hmm, if I apply the identical tests to thresholds specified as algebras that are applied to thresholds as matrices, then models/passing/OrdinalTestAlgebra.R fails with the message: "The number of thresholds in column 't1neur1' is not one less than the number of levels in model 'untitled51'". So the tests that are applied to thresholds matrices cannot be applied to the initial values of thresholds algebras?
#6
Tim - Great! I'm very pleased to have this model running.
I am wondering if we need a helper function or similar to construct these matrices automatically for standard cases.
I'd not caught the deal with NA's. In essence this lets openmx know how many categories there can be in the data, right? So some cross-checking, such that an error is generated if there's a data point outside the range of thresholds (e.g. a datapoint with 100 when there are only 10 thresholds) would be handy. Presently such errors fail with
Error in mxRun(BivariateOrdinalACEModel) :
Requested improper value (12, 0) from (12, 4) matrix.
But that is not very helpful. Ideally, the contents of the data vector that caused the error and which vector that was (position, rownumber) in the dataframe would come back with a bit more information. In my case, I tried a datavector with 19 1 7 0, instead of a legal one 9 1 7 0, but there is no hint of 19 in the improper value error message (I would have thought 19,1 rather than 12,0).
Simpler is the case where we know that a dataset does not include all of the values up to a particular maximum. At most this should generate a warning, not an error. There are times when we wish to fit models of this type to single data vectors (estimating ML factor scores).
#7
OK, I checked in a patch that standardizes the error checking across the two scenarios of either a single thresholds matrix or a single thresholds algebra. When I run the original script from Mike Neale, the following error message is returned: "The number of thresholds in column 't1mddd4l' is not one less than the number of levels in model 'ACE'". Is this message correct? If error checking is working for one thresholds entity, the remaining step is to finish error checking for multiple thresholds entities.
#8
This should be closed now, as thresholds matrices no longer need to be padded with NAs?
#9
I'm closing this issue. It can be reopened later if necessary.