Why? Well mostly for ease of implementation. Partly because there is no PEMDAS equivilent order of operation for Matrices and vectors.
Once I go through an example or two, it should be a little clearer.
To add {1 1 1} and {2 2 2} I run the following command:
vexpr {2 2 2} {1 1 1} +
> 3.0 3.0 3.0
|
Rember though, we are working with a stack. Items are popped on the stack in a first-in first-out fashion. While for addition it doesn't matter what order we do things, subtraction does care.
vexpr {1 1 1} {2 2 2} -
> 1.0 1.0 1.0
vexpr {2 2 2} {1 1 1} -
> -1.0 -1.0 -1.0
|
While with 2 arguments and an opcode this seems silly, imagine a complex operation with several steps. Here we are going to model a robot arm with 3 joints. Each "arm" is one unit long, and when one joint bends, the rest follow suit.
# Positions of the joints
set A_pos {0.0 0.0 0.0}
set B_pos {1.0 0.0 0.0}
set C_pos {2.0 0.0 0.0}
# Rotations of the joints
set A_rot {0 0 45}
set B_rot {0 0 45}
set b_transform [vexpr
$A_pos $B_pos -
affine_translate
$A_rot radiens
affine_rotate
affine_multiply]
> { 0.707 0.707 0.0 -0.707}
{-0.707 0.707 0.0 0.707}
{ 0.0 0.0 1.0 0.0}
{ 0.0 0.0 0.0 1.0}
set b_real [vexpr $B_pos $b_transform vector_transform]
> 0.707106 0.707106 0.0
set c_transform [vexpr
$C_pos $B_real -
affine_translate
load affine_multiply
$B_rot radiens
affine_rotate
affine_multiply]
> { 0.0 1.0 0.0 0.707}
{-1.0 0.0 0.0 2.293}
{0.0 0.0 1.0 0.0}
{0.0 0.0 0.0 1.0}
set c_real [vexpr $C_pos $c_transform vector_tranform]
> 0.0 2.0 0.0
|
If you aren't familiar with 3D math and affine transformations, that may look overly complicated, but as you can see each vexpr call is packed with commands. You can plainly see that after 2 45 degree bends, our "C" point comes to rest at 0.0,2,0 after completing a 90 degree bend.