You are here

Developers Meeting 3/12/10

7 posts / 0 new
Last post
mspiegel's picture
Joined: 07/31/2009 - 15:24
Developers Meeting 3/12/10
  • Mike Wilde progress on swift apply in R
    - create *apply() analogs for swift, in similar style to snow package
    - eventually create a swift package in R, or contribute to the snow package
  • Steve: short cut in mxFIMLObjectiveFunction() using means = 0 as a shortcut for vector of zeros with free=TRUE.
  • as a first step for easy thresholds write a function that takes an ordinal data input and returns a thresholds matrix
  • fetch from the back-burner the project to pretty-print a OpenMx object as a script
  • create a CRAN package from the twins workshop
  • maybe next week create the feature list for the OpenMx 1.0 binary release?
tbrick's picture
Joined: 07/31/2009 - 15:10
I think means=0 should

I think means=0 should auto-generate a fixed (free=FALSE) vector of 0s instead.

The use case I was thinking of for it was one that came up a few times at the Boulder Twin Workshop. As I recall (other folks from the workshop please correct me here), the model featured free thresholds, often a single free threshold in the common binary case. The model therefore becomes underidentified if the means are free.

It also strikes me that since free defaults to FALSE in the mxMatrix command, it seems reasonable for means=0 to default to free=FALSE as well.

Steve's picture
Joined: 07/30/2009 - 14:03
Trouble is, 90% or more of

Trouble is, 90% or more of the cases are going to be free=TRUE. I actually don't like the means=0 fix, because it seems hackish to me. I realize it avoids adding a keyword, except that it actually doesn't avoid it in people's memories, just in the R code.

Tim's statement sounds more like the reasonable default, if we are going to use reason as a criterion. But it just isn't what most people want to do most of the time. If it isn't what most people want to do most of the time, I'd argue we should avoid hackishness and not do anything yet.

At some point we do need to figure out how to help streamline the model building process.

mspiegel's picture
Joined: 07/31/2009 - 15:24
My preference is in agreement

My preference is in agreement with Tim's comment. The curmudgeon's argument goes something like this:

OK, well you want to ignore the means completely from your model. You're going to create a vector of zeros and make them all fixed parameters. I guess I could do that for you with this shortcut for means = 0. Notice that under these circumstances, the auto-generated matrix does not need to appear to the user. The expected means matrix doesn't store any information.

OTOH, you actually want to model the means with a vector of free parameters. In this case you want to add degrees of freedom to the model. Under these circumstances, the auto-generated means matrix would have to appear to the user, because it is the container for the free parameters. This is the source of my opposition. I don't like transformations that occur in mxRun() that change the visible structure of a model.

Ryne's picture
Joined: 07/31/2009 - 15:12
I would have thought that the

I would have thought that the most common use case was freely estimated thresholds and fixed means. My understanding of the threshold model uses estimated thresholds identify cutpoints on an underlying continuous latent variable, which must be fixed to constant mean/variance for identification. Free estimation of means requires a constraint of some type either in the thresholds or elsewhere in the model.

I do agree that means=0 is hackish, but I prefer it to the alternatives. An assumed default would be much worse, and this solution teaches new users to specify means in some way.

neale's picture
Joined: 07/31/2009 - 15:14
I agree with Ryne; while

I agree with Ryne; while means=0 (and fixed) is likely to be a common case, it is not such a great idea to leave it out. People could implement means models within the threshold statement, e.g., by subtracting a matrix Mvec = T - U@M which is generated by Kronecker premultiplying a row vector M by a column vector of 1's, U, which has as many rows as there are thresholds in the matrix T.

So there is a workaround if the means argument is completely forgotten, but I find the idea of being able to specify models for the means in a Threshold context very appealing. The reason for the appeal is that many covariance structure models, such as growth curve models make explicit predictions about how the means change over time. Converting such models to operate with ordinal or binary data is relatively straightforward. The Paras Mehta trick of fixing the first threshold to zero and the second threshold to 1.0 provides the constraints necessary to estimate the means and variances of the continuous variables which are assumed to underlie the ordinal variables. The same model for covariances and means for the continuous case can then be used directly in the ordinal implementation. (Sarah, I know you disagree, sorry!)

Steve's picture
Joined: 07/30/2009 - 14:03
Actually, I would argue that

Actually, I would argue that once we are talking about threshold models we are already talking about only 10% of the models. For most everyone else, free means are the most likely use case.

I had thought that the "easy thresholds" use case was being considered separately from the "easy means" use case.

But still, since we are having this discussion, I think we might reconsider whether we yet know what people want well enough to implement a more-or-less permanent special case like means=0.

Log in or register to post comments