as ^ is for element-wise powering. (Note --- I am not trying to multiply the matrix by itself.) But I get the response: "Error: The algebra 'untitled7121' in model 'test' generated the error message: non-conformable arrays"

Same thing if I try to use * or / to multiply or divide by a constant. I know that if I generate an equivalent size matrix full of the desired constant, I can make ^, * and / work. Is there a modification to the code above that would allow me to do element-wise operations on a matrix using constants, without having to generate a separate matrix of constants?

Thanks! I completely overlooked Kronecker powering. I don't know if it is worth it, but a few words in the ?mxAlgebra would probably help clear up the way the element-wise operators are working.

Perhaps this is have been taken care of, but when I do the following:

> A <- mxMatrix("Full", nrow = 3, ncol = 3, name = "A")
> mxAlgebra(A)
mxAlgebra 'untitled46'
formula: A
result:
<0 x 0 matrix>
dimnames: NULL

it seems odd to me that the 'result' is a 0x0 matrix. Perhaps it is meant to do something else, but it seems to me that the 0x0 should be replaced with the dimensions of the resulting matrix.

The OpenMx workflow is demand-driven, which means that the result of algebra expressions are not computed until: (A) the containing model has been executed, and (B) the algebra within the model is needed by the objective function. The 0 x 0 matrix in the result slot of the algebra is our short-hand for saying "this algebra has not been computed". We should change the print function for MxAlgebra and MxObjectiveFunctions to print something to that effect.

On a related note, in order to compute an algebra, create a model with no objective function and run the model. In this case, we compute all the algebras once and return to the user.

> A <- mxMatrix("Full", nrow=3, ncol=3, name ="A")> B <- mxAlgebra(A, name ="B")> model <- mxModel(A, B, name ="model")> modelOut <- mxRun(model)
Running model
> mxEval(B, modelOut)[,1][,2][,3][1,]000[2,]000[3,]000

Being somewhat used to R, it is confusing not to refer to things by their variable names in mxAlgebra, and instead passing along to mxModel by their R name, but having them used by a (potentially different) internal "name" value.

Is there a reason to give things an internal "name" when it would always be as simple to just make the variable with that name?, and this would obviate the need to keep things in sync?

Then instead of the original (copied at the bottom of this comment), you could have

Also, is there a reason why algC can't know enough about matrices A and B with which it deals to allow us to say simply:

mxModel(algC, mxAlgebraObjective(algD))-> modelF

i.e., why pass A and B in mxModel, when algC is alrady on speaking terms with them?

In which case, models seem simple enough to note require mxModel to assemble them: just pass them pieces to a smarter version of mxRun (or to a version of mxModel which can either output a model or run it?

# the algebra B evaluates to the matrix A
A <- mxMatrix("Full", nrow=3, ncol=3, name ="A")
B <- mxAlgebra(A, name ="B")# the algebra C is A + BC<- mxAlgebra(A + B, name ="C")## Not run: # the algebra D is sin(C)D<- mxAlgebra(sin(C), name ="D")# Evaluate the mxAlgebra object 'D'
modelD <- mxModel(model="AlgebraExample", A, B, C, D, mxAlgebraObjective("D"))
modelD <- mxRun(modelD)

I get the impression from the documentation that I should be able to do something like this:

myMatrix <- mxMatrix(type="Full",nrow=3,ncol=3,name="myMatrix",value=1)

mxRun(mxModel("test",myMatrix,mxAlgebra(myMatrix^2)))

as ^ is for element-wise powering. (Note --- I am not trying to multiply the matrix by itself.) But I get the response: "Error: The algebra 'untitled7121' in model 'test' generated the error message: non-conformable arrays"

Same thing if I try to use * or / to multiply or divide by a constant. I know that if I generate an equivalent size matrix full of the desired constant, I can make ^, * and / work. Is there a modification to the code above that would allow me to do element-wise operations on a matrix using constants, without having to generate a separate matrix of constants?

You can include numbers in mxAlgebra and they are upgraded to 1x1 matrices for you.

Hence your element-wise 3x3 ^ 1x1 returns the error "nonconformable matrices"

There is no way to construct a larger matrix inside the algebra: you would want to mxMatrix it and use that.

But there is an easy work-around: Kronecker product:

Thanks! I completely overlooked Kronecker powering. I don't know if it is worth it, but a few words in the ?mxAlgebra would probably help clear up the way the element-wise operators are working.

Many thanks!

added an example using Kronecker ^ and * to the ?mxAlgebra

Perhaps this is have been taken care of, but when I do the following:

> A <- mxMatrix("Full", nrow = 3, ncol = 3, name = "A")

> mxAlgebra(A)

mxAlgebra 'untitled46'

formula: A

result:

<0 x 0 matrix>

dimnames: NULL

it seems odd to me that the 'result' is a 0x0 matrix. Perhaps it is meant to do something else, but it seems to me that the 0x0 should be replaced with the dimensions of the resulting matrix.

A ticket has been made as per the suggestion in comment #5: http://openmx.psyc.virginia.edu/issue/2009/08/print-something-useful-0x0...

The OpenMx workflow is demand-driven, which means that the result of algebra expressions are not computed until: (A) the containing model has been executed, and (B) the algebra within the model is needed by the objective function. The 0 x 0 matrix in the result slot of the algebra is our short-hand for saying "this algebra has not been computed". We should change the print function for MxAlgebra and MxObjectiveFunctions to print something to that effect.

On a related note, in order to compute an algebra, create a model with no objective function and run the model. In this case, we compute all the algebras once and return to the user.

Thanks!

Being somewhat used to R, it is confusing not to refer to things by their variable names in mxAlgebra, and instead passing along to mxModel by their R name, but having them used by a (potentially different) internal "name" value.

Is there a reason to give things an internal "name" when it would always be as simple to just make the variable with that name?, and this would obviate the need to keep things in sync?

Then instead of the original (copied at the bottom of this comment), you could have

Also, is there a reason why algC can't know enough about matrices A and B with which it deals to allow us to say simply:

i.e., why pass A and B in mxModel, when algC is alrady on speaking terms with them?

In which case, models seem simple enough to note require mxModel to assemble them: just pass them pieces to a smarter version of mxRun (or to a version of mxModel which can either output a model or run it?

Comments?

## Existing script

outdated post deleted