OpenMx
OpenMx copied to clipboard
OpenMx
cope with NA values in matrices
@mcneale wrote:
The propagation of NAs as the result of post-multiplication by a column that includes NAs is a problem that needs to be trapped. Overall I think we should not break backwards compatibility on this one - people have enough trouble getting threshold models to run in the first place. And to converge in the second...
OpenMx has never really supported NAs in matrices. It's too bad the documentation suggested using them. We could automatically replace NAs with some other value. However, I worry that this would preclude a future use of NA.
Wait, we already have a solution? https://openmx.ssri.psu.edu/comment/8538#comment-8538
Yes. There is a specific error message OpenMx gives if one of the thresholds it needs to use is NA.
In an algebra, NA's will propagate to elements that are not supposed to be NA. Suppose one ordinal variable, with the lower triangular trick:
y <- matrix(c(1,1,1,0,1,1,0,0,1),3,3) x <- matrix(c(0, 1, NA),3,1) y%*%x [,1] [1,] NA [2,] NA [3,] NA
@mcneale Correct. And in that case, OpenMx will give the "I hit NA values after only 0 thresholds" error.
Ok, so NAs work as directly specified elements, but they don't work if an algebra is being used. That's perhaps as good as it gets, if a bit confusing for the user.
Ok, so NAs work as directly specified elements, but they don't work if an algebra is being used.
You know what? Maybe at one point, NAs did work if thresholds were specified with an algebra. See issue #240 . We used to use "unsafe" BLAS subroutines that would sometimes evaluate 0 * NA as 0.
We used to use "unsafe" BLAS subroutines that would sometimes evaluate 0 * NA as 0.
Ick
Is this resolved? Has anyone appropriately updated the User Guide so that it no longer recommends a broken way to set up thresholds?