Hi folks, I am just pasting in here some email discussion between Greg Carey and myself concerning the language interface. In the thread we drifted off to talk about models of assortative mating.

Greg Carey's email:

mike,

just looked at openMx and am worried that things might get unnecessarily complicated when dealing with large multivariate problems.

imagine data on twins and families on the WAIS and a factor model. the proposed GUI is like Amos--you will spend so much time drawing paths from 13 variables to X latent factors for father (including 13 specifics), X latent factors for mother (13 more specifics), for son 1, son 2 ... to daughter k that the actual canvas cannot accommodate the number of necessary symbols. in addition, the 13 x 13 covariance matrix between husband's WAIS and wife's WAIS should be predicted by the model of marital assortment. try to express this in jack's RAM notation--it is possible but the only practical way (that i can see) is to define blocks of the path-coefficient matrix and the exogenous-residual covariance matrix in terms of other, more specific matrices.

anyway, what everyone is doing is perfectly fine--for simple models. for complicated models, i suspect that a different interface is required (one that may, in fact, be accommodated by expansion of the python script, mxParser.py). in terms of a positive contribution, i suggest that the old logic of Mx be followed but in the following way:

(1) define the parameter matrices containing free and/or fixed parameters [e.g., what is typically done in Group 1]

e.g.,

begin matrices;

covA sy 3 fr

D di 3 fi

StdE di 3

WhatEver fu 3 6

end matrices;

(2) parse a series of statements that fix, free, equate, etc. elements of the above matrices. these would include the FI, FR, EQ, PA, MA, SP statements of Mx

e.g.,

begin Whatever_You_Want_to_Call_This_Section;

PA StdE

0 1 1

MA StdE

23.6 4 9.3

MA WhatEver

.3 .8 .7 0 0 0

0 .7 .3 .2 0 0

0 0 0 0 .8 .5

FI Whatever 1 1 2 1 3 2

end Whatever_You_Want_to_Call_This_Section;

(3) give the algebra (as in the first group in usual Mx Code) but in R syntax

begin algebra

Example = Stde %*% WhatEver %*% transpose(Whatever)

end algebra

(4) assign the predicted matrices from (3) to the groups in the model

begin PredictGroups

1 CPre1

2 hbind(cbind(Vp,covDZ),cbind(covDZ,Vp))

end PredictGroups

(5) from the above information, it is possible to construct two different numeric vectors:

xfandf = vector of all free and fixed parameters

xf = compact vector of free parameters,

so do the following in the minimization function passed into NAG E04???

(5.a) take the vector xf passed from E04??? and put the appropriate elements into vector xfandf

(5.b) from vector xfandf, construct the parameter matrices specified in BEGIN MATRICES and BEGIN WHATEVER

(5.c) perform the algebra specified in step (3) above

----- CHECK THIS CODE OUT ----------------------------------------------

npheno
begin matrices

Va sy npheno

sigE di npheno

Re st npheno

eta sy npheno

end matrices

begin matrixStuff

PA eta

1 1 1 0 0

1 1 1 0 0

1 1 1 0 0

0 0 0 1 1

0 0 0 1 1

ST 2.5 DIAG(Va)

ST 0.4 OFFDIAG(Va)

ST 3.0 sigE

end matrixStuff

begin algebra

Vp
covE
end algebra

begin predictGroups

1 rbind (cbind(Vp, Va + covE), cbind(Va + covE, Vp))

2 rbind (cbind(Vp, .5*Va + covE), cbind(.5*Va + covE, Vp))

end predictGroups

----- END OF CODE --------------------------------------------------------

mike,

bottom line = if you implement this in the existing openMx framework, it will take pages of code. a suitable preprocessor in python, perl, or (if really interested in a potential gui with web interfaces) java can have a user enter the code and have it translated into Mx equivalent using the above rules.

anyway, just trying to help out.

greg

Editorial Note from Mike Neale: the Pattern command, which is rarely used in Mx, simply identifies which elements should be free parameters without actually assigning parameter numbers (labels in OpenMx) to them. It is equivalent to free=c(T,F,T) syntax in OpenMx.