New Feature Proposals

way to see (a list of) the paths that mxPath creates
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
- Read more about way to see (a list of) the paths that mxPath creates
- Log in or register to post comments

mxRowObjective() interface
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.
- Read more about mxRowObjective() interface
- 1 comment
- Log in or register to post comments

OpenMx on GPU?
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.
- Read more about OpenMx on GPU?
- 1 comment
- Log in or register to post comments

OpenMx 1.x wishlist
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
- Read more about OpenMx 1.x wishlist
- 2 comments
- Log in or register to post comments

Mx RAM speedup comparison test
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)
>
- Read more about Mx RAM speedup comparison test
- 1 comment
- Log in or register to post comments

Sorting Raw Data
I have some questions about the correct approach to sort raw data. Imagine the following dataset:
A | B | C |
---|---|---|
1 | 2 | NA |
1 | 3 | NA |
1 | 2 | 2 |
2 | 3 | 3 |
2 | 2 | NA |
2 | 3 | NA |
- Read more about Sorting Raw Data
- 3 comments
- Log in or register to post comments

mxMatrix() proposed changes
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
- Read more about mxMatrix() proposed changes
- 4 comments
- Log in or register to post comments

mxNormalInterval() proposal
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.
- Read more about mxNormalInterval() proposal
- 52 comments
- Log in or register to post comments

mxUpdate()
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="")) }
- Read more about mxUpdate()
- 7 comments
- Log in or register to post comments

Future proofing the mxRun() function
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.)
- Read more about Future proofing the mxRun() function
- 2 comments
- Log in or register to post comments
Pagination
- Previous page
- Page 2
- Next page