Thresholds are not in order

mspiegel's picture
Category:bug report


I wrote a simple OpenMx script to do LCA on ordinal variables. It works fine on simulated data. When I run it on real data, the estimated thresholds are not in order. I then included constraints on the thresholds (simple enough to do) so that they are monotonically increasing. This seems to work as the threshold estimates monotonically increase. From reading the manual, I was sure constraints weren't necessary.


tbates's picture


I think this is fixed (I've not seen thresholds get out of order). Does anyone have a script that does let them get out of order (and therefore break, I guess).

We also throw an error if the user supplies out of order thresholds

 m1 = mxRun(m1);
Running ACE 
Error: In model 'ACE' the thresholds in column 'ORDER_T1' of matrix/algebra 'top.threshMat' 
are not in ascending order. 
The current order is:  
'0.502278707081169', '0.1427282567208', '0.796488486601088', '1.11374922033532', '1.36331347193658', '1.62096376811414', '1.79737850662286', '1.99263413447754', '2.16364965092772', '2.28036398908342', '2.3202473850114', '2.49991358917899', '2.61074800550596', '2.7676314242183', '2.7676314242183', '2.7676314242183', '2.93015621262521', '2.93015621262521', '3.25615885822543', and '3.25615885822543' and ascending order is:  '0.1427282567208', '0.502278707081169', '0.796488486601088', '1.11374922033532', '1.36331347193658', '1.62096376811414', '1.79737850662286', '1.99263413447754', '2.16364965092772', '2.28036398908342', '2.3202473850114', '2.49991358917899', '2.61074800550596', '2.7676314242183', '2.7676314242183', '2.7676314242183', '2.93015621262521', '2.93015621262521', '3.25615885822543', and '3.25615885822543' . Only the first 20 element(s) 

What we don't error on is adjacent thresholds which are identical: Seems to me this should be an error, as it makes it arbitrary which threshold a given latent score will lead too...

Perhaps set a minimum delta of + .0001 or something?

jpritikin's picture


Believed to be fixed.

jpritikin's picture


Status:active» closed
neale's picture


I don't think that this problem was ever fixed. It can be difficult to reproduce, however. Internally we had considered automagically adding linear inequality constraints, which in some optimizers can be specified so as to never be violated. However, this has not been implemented afaik, and would be optimizer specific.

The general and infallible solution is to respecify the model for the thresholds and use bounds on the parameters. Let L be lower triangular with the diagonal and sub diagonal elements set to 1 (the upper triangle elements are zero). Let D be a matrix of threshold deviations. The first row of this matrix should be unbounded, but rows 2...nrow are set to have a lower bound close to zero (say .001). Then the matrix product L%*%D will result in row i having elements that always are at least .001 greater than the element above it in row i-1. A code snippet illustrates:

	Dmat <- mxMatrix("Full", name="thresholdDeviations", nrow=nThresholds, ncol=nVariables,
            values=.2, free = TRUE, lbound = rep( c(-Inf,rep(.01,(nThresholds-1))) , nVariables),
            dimnames = list(c(), fruitynames))
        Lmat <- mxMatrix("Lower",nThresholds,nThresholds,values=1,free=F,name="unitLower")
        thresholds <- mxAlgebra(unitLower %*% thresholdDeviations, name="thresholdMatrix")