New Feature Proposals

currently, if you run mxPAth you get something like this

> mxPath(from=latents, arrows = 2, free = T, all = T)
mxPath 
@from:  'F1', 'F1', 'F1', 'F1', 'F1', 'F1', 'F2', 'F2', 'F2', 'F2', 'F2', 'F2', 'F3', 'F3', 'F3', 'F3', 'F3', 'F3', 'F4', 'F4', 'F4', 'F4', 'F4', 'F4', 'F5', 'F5', 'F5', 'F5', 'F5', 'F5', 'F6', 'F6', 'F6', 'F6', 'F6', and 'F6' 
@to:  'F1', 'F2', 'F3', 'F4', 'F5', and 'F6' 
@arrows:  2 
@values:  0 
@free:  TRUE 
@labels:  NA 
@lbound:  NA 
@ubound:  NA 
@excludeself:  FALSE 

At the last developers meeting, we discussed changes to the mxRowObjective() interface that are intended to simplify the treatment of NA values in the backend. Currently there are no legitimate methods for inducing a NA value into a MxMatrix or MxAlgebra object. Any operation that produces a NA value (such as division by zero) should be throwing an error even if it currently does not. However, the mxRowObjective() objective function could allow definition variables to be populated with NA values.

We are investigating the idea to make a GPU-version of OpenMx, in the sense that time consuming matrix functions will be executed on GPU, instead of CPU. I am new to OpenMx, so I don't know whether someone already looked into this, or is working on it. It seems quite straightforward to replace the Fortran implementation of the LAPACK functions being used by a GPU-implementation of LAPACK.

As we get close to the release of OpenMx 1.0, it is time to begin compiling a list of the new features we would like to see in the post-1.0 development cycle. I'll start the discussion with two features that have been on my mind.

Rewrite of mxEval

Hi

I tried running a model with vs. without a feedback loop. There is some penalty if there's feedback in the model, but not as much as I would have expected. This is in a system with 48 latent+observed variables, so I would have thought that inverting 2 48x48 matrices every iteration would have slowed things down a lot more. But perhaps the inversion routine is pretty smart about cases like this. Script attached.

> system.time(twinACEFit <- mxRun(twinACEModel))
Running twinACE
user system elapsed
239.818 0.429 240.693
> #summary(twinACEFit)
>

I have some questions about the correct approach to sort raw data. Imagine the following dataset:

The following proposal would change the behavior of mxMatrix() in some circumstances based on the 'nrow' and 'ncol' arguments. This proposed is based on the following bug report: http://openmx.psyc.virginia.edu/issue/2010/07/matrix-not-populated-expected-r-based-nrow-ncol

Currently the svn repository has an implementation of likelihood-based confidence intervals. For the moment, the interface looks like the following:

model <- mxModel(model, mxNormalInterval(c('A', 'C[,]', 'E[1,1]'), 0.95, 0.95))

The first argument to mxNormalInterval() is a vector of strings. These could be either matrix/algebra names or free parameter names. The second argument is the lower confidence level, and the third argument is the upper confidence level.

I would like to propose a unified method for users to obtain updates to OpenMx.

mxUpdate()

Without any arguments, this would allow people to load the most current version of OpenMx. If a version number was supplied it could load a specific version if they wanted to roll back an upgrade.

In its simplest form it would look something like

mxUpdate <- function(version=NA) {
    if(is.na(version)) source('http://openmx.psyc.virginia.edu/getOpenMx.R')
    else source(paste("http://openmx.psyc.virginia.edu/get", version, ".R", sep=""))
}

Here is a proposed change to the mxRun() command. I've noticed that we have a tendency of adding flags to 'mxRun' as time marches forward. Currently, the signature for 'mxRun' is something like:

mxRun(model, flag1 = value1, flag2 = value2, flag3 = etc.).

The proposal is to change the signature to:

mxRun(model, ..., flag1 = value1, flag2 = value2, flag3 = etc.)