Hi, I'm new here. I'm a political scientist/programmer. I was drawn in by conversation about SEM among my psych colleagues at the University of Kansas. Now that you have the gcc-4.3 version of lpsolve.la in your package, I can build OpenMx without any trouble on Ubuntu 9.04 with R 2.9.2
I've been reading through your OpenMxUserGuide and testing the examples and I'm having some reluctance about the style of your R interface/code. I'm pretty sure that R users who come to try OpenMx will have difficulty digesting the way you have designed your interface.
I've been reading your source code a bit and playing with examples. I believe these ideas are feasible, but you do have a lot of code :)
Idea 1. Set the "name" slot of your objects implicitly. Running
myThing <- mxAlgebra( Z )
should create an R object named "myThing" and the mxAlgebra name attribute should be automatically set as "myThing". (Why do you need an mx name slot, I don't know quite yet, but I know you have one).
To an R user, it would be second nature to create a matrix
x <- matrix( c(1,2,3,4), ncol=2, dimnames=list(NULL, c("A","B")))
This thing "x" is an object whose name is x. It will be quite foreign to R users that you have syntax that allows a person to name an object differently than its name. I can't imagine any reason why you should allow:
oneName <- mxAlgebra(A + B, name = "C")
the mxAlgebra object's name is "C" but on the outside its R name is "oneName"??
It seems to me huge confusion will follow from this.
It would be much better if you allowed a user to write
myMxMatrix <- mxAlgebra(A+B)
and if it is necessary to have a "name" slot in mxAlgebra, the interpreter should detect the name and create that slot. And, preferably, it would be impossible for a user to name something differently from the "name" slot inside the object.
Idea 2. If you think of things in that way, then the R commands to run Mx models would be simpler. In the way you describe the mxModel interface, you can have a command that goes on for several pages.
It is much more usual in R to have declarations first, as in
A <- mxWhatever
B <- mxWhatever
C <- mxWhatever
mymodel <- mxModel( A, B, C )
Take a look at the examples for "systemfit", for example.
Or the "sem" package for R that John Fox distributes.
Idea 3. Create separate functions mxModel() and update(). mxModel can only create new objects. update can revise mxModel so that it creates an object with a given name. This is the way other R functions work.
myNamedThing <- lm (y~x)
mxModel is now allowing a person to put in a name of an existing object, or a new name. In other R functions, we usually have a function "update" that performs the revision on the existing result. We don't have
myLM <- lm("someNameHere", function="y~x")
and then
lm(myLM, function="y~x+z")
as you seem to want to do in OpenMx.
Instead, an output object with a name exists, and the update function can modify it.
I guess I should say also that mxModel should not have a name="" option, but rather the output object's name should be noted, as is the case in other R functions.
Idea 4. When you introduce R code, you should use the most succinct way.
On page 12, you have this:
#Simulate Data
x <- rnorm (1000, 0, 1)
testData <- as.matrix(x)
selVars <- c("X")
dimnames(testData) <- list(NULL, selVars)
Many of us would not use as.matrix, but it does work. But there is no real need to create the object "selVars" or run the dimnames after. In 2 steps
x <- rnorm(1000) ### don't need the 0 and 1 because they are default
testData <- matrix(x, ncol=1, dimnames=list(NULL,c("X")))
or in one step
testData <- matrix(rnorm(1000), ncol=1, dimnames=list(NULL,c("X")))
If one did want to create the matrix and then assign column names later, as in your example, I suggest
colnames(testData) <- c("X")
rather than dimnames.
I don't understand yet (because I'm only 1/2 way through your manual) why it is not sufficient in OpenMx to have a vector X created thus:
X <- rnorm(1000)
That is the same thing as the Nx1 matrix. It seems to me you are creating some extra work by wrapping a single column inside a matrix object. But I bet I'm going to find a reason for that later :)
Oh, well, I have run out of energy. I'll be glad to hear your feedback to my feedback!
Paul Johnson
Professor, Political Science
University of Kansas
http://pj.freefaculty.org [6]