You could adhere to R conventions more closely

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.