You are here

Order of operations in mxAlgebra()'s

I had thought that there would be a default order of operations of mxAlgebra() operators. Indeed, consultation of the wiki https://openmx.ssri.psu.edu/wiki/operator-precedence seems to confirm that binary + should be done after %*%
However, the following example suggests that this order is not followed. The only difference between the equations is that the two parts separated by the binary + have been offset by (). Since this is lower precedence than the other operations, it should have been done last (the binary - should have been done earlier inside the solve() function call). But different results emerge.

> mxEval((solve(ACE.I-ACE.at) %&% (ACE.ai %% t(ACE.ai)) + (ACE.fl %&% (ACE.alp %% t(ACE.alp)))), TraitStateACEFixFl1stModelFit)
[,1] [,2] [,3] [,4]
[1,] 0.4580807 0.4580807 0.4580807 0.4580807
[2,] 0.4580807 0.4805261 0.4504615 0.4625746
[3,] 0.4580807 0.4504615 0.4609001 0.4564178
[4,] 0.4580807 0.4625746 0.4564178 0.4593563
> mxEval(solve(ACE.I-ACE.at) %&% (ACE.ai %% t(ACE.ai) + ACE.fl %&% (ACE.alp %% t(ACE.alp))), TraitStateACEFixFl1stModelFit)
[,1] [,2] [,3] [,4]
[1,] 0.4580807 0.3635496 0.3346717 0.2606875
[2,] 0.3635496 0.3109715 0.2579885 0.2113850
[3,] 0.3346717 0.2579885 0.2473290 0.1887942
[4,] 0.2606875 0.2113850 0.1887942 0.1496293
>

Reporter: 
Created: 
Wed, 08/10/2011 - 13:48
Updated: 
Thu, 08/18/2011 - 09:39

Comments

If I'm reading this correct, the first line is evaluating:
A %&% B + C %&% D
And the second line is evaluating:
A %&% (B + C %&% D)

Yup, my bad - parenthesis in the wrong place!

mxEval(solve(ACE.I-ACE.at) %&% (ACE.ai %% t(ACE.ai) + ACE.fl %&% (ACE.alp %% t(ACE.alp)))

should have been

mxEval(solve(ACE.I-ACE.at) %&% (ACE.ai %% t(ACE.ai)) + ACE.fl %&% (ACE.alp %% t(ACE.alp))

  • was hard to spot as I was working on someone's pc at the time. Speaking of which, OpenMx seems very happy working with OS X Lion (10.7), as am I.