Square bracket operator implemented
mspiegel
Joined: 07/31/2009
I implemented the square bracket operator for MxAlgebra expressions. In an algebra it is now possible to write A[x, y] or A[,y] or A[x,] or A[,]. x and y must be either numeric literal values, or they can also be an arbitrary 1 x 1 matrices if you want to get fancy. A lion's share of the credit should be attributed to Tim Brick. The matrix operator and function interface that we designed made it fairly easy to implement this operator. It seemed like the square-bracket operator might be useful. See models/passing/AlgebraComputePassing.R for some examples.
For developers: in R the expression A[x,] is parsed as a function with three arguments. The three arguments are A, x, and "". The OpenMx library will now translate any "" it sees inside an algebra expression into a 0 x 0 constant matrix. This is legitimate because we have forbidden the use of "" as either a free/fixed parameter label or the name of an entity. I don't know if this trick will be recycled for other uses, but feel free to use it.
One comment on the current changes: I decided that A[x,] should return a row matrix and A[,y] should return a column matrix. This is different from the behavior in R. R will return a vector in either case (not a matrix). It would appear that when vector and matrix are used in R in an operation, the vector is converted to the "correct" dimensions to make the operation succeed. Thoughts on my implementation? Should both cases return a row matrix? Should both cases return a column matrix? Currently conformability testing will succeed on some error conditions because R is flexible with vectors and matrices. I believe I can convert the A[x,] expressions into the correct as.matrix() expressions inside the mxEval(compute=TRUE) call. Any problems with this approach?
Nifty! I intuit that this is
Nifty!
I intuit that this is the correct behavior; it is what I would expect.
Do you think that doing things at variance with what R does will be problematic? My feeling is that it's better to have matrices of everything, so that we can continue algebraic operations with them. Otherwise formulae would end up full of as.matrix() functions, I suspect.
Log in or register to post comments
In reply to Nifty! I intuit that this is by neale
Yeah, I'm going to implement
Yeah, I'm going to implement tonight the change in mxEval() that inserts as.matrix() or t(as.matrix()) around expressions of the form A[x,] or A[,y] so that mxEval() will always return a matrix just like the back-end. Otherwise we can't match the native behavior in R, because we don't want to support vectors in the back-end.
Log in or register to post comments
In reply to Yeah, I'm going to implement by mspiegel
I committed the changes such
I committed the changes such that conformability checking is in effect. So if A and B are 3 x 3 matrices, then mxEval(A[1,] + B[2,], compute=TRUE) will succeed but mxEval(A[1,] + B[,2], compute=TRUE) will throw an error. This is good stuff because the conformability checking in OpenMx uses mxEval(...,compute=TRUE) to check the dimensions of algebra expressions.
Log in or register to post comments
> I decided that A[x,] should
> I decided that A[x,] should return a row matrix
> and A[,y] should return a column matrix.
That will be helpful for users: More so than getting a row or column when asking for the other.
Log in or register to post comments
In reply to > I decided that A[x,] should by tbates
I also agree with this logic.
I also agree with this logic. I don't expect it would surprise anyone.
Log in or register to post comments
In reply to I also agree with this logic. by Steve
As requested in the last
As requested in the last developers meeting, when using the square bracket operator A[x,y] then x or y can be either a string or a global variable that stores a string. The string should be a row or column name of the matrix/algebra A, or an error is thrown. This has been implemented in revision 981. Note that if you attempt to use a string inside an MxAlgebra expression in any other context, then you will get an error message.
Log in or register to post comments
As discussed at the last
As discussed at the last developer's meeting, the square-bracket operator can now be used in MxMatrix labels just as it can be used in MxAlgebra expressions. Previously the square-bracket operator was restricted to constant values for row and column argument when the operator was used in a MxMatrix label. You can see an example of the new notation here: http://openmx.psyc.virginia.edu/repoview/1/trunk/models/failing/MultilevelLongFormatFailing.R.
There was some trickery in autoboxing the MxMatrix label into an MxAlgebra expression. The hard part was not the translation itself, but rather hiding any effects of the translation from the user. I say this only because I have tested a number of error conditions. But some error condition will probably surface that I have not imagined. So have fun.
Log in or register to post comments