01142014, 05:57 PM
Now that I have the printed manual and had the opportunity to read it in more detail, I am somewhat shocked at the rather primitive nature of matrix handling on the WP 34S as compared to the HP 42S, or even the HP 15C.
There is no matrix data type on the WP 34S, and matrices are defined by "descriptors" that point to a range of data registers where the matrix elements are stored. Matrix elements cannot be selected by their normal two digit row/column id, and instead it's up to the user to write down and remember which register contains which element. Furthermore, direct math operations cannot be performed e.g. RCL MAT1 RCL MAT2 x. In order to do this on the WP 34S one has to do something like RCL 89 RCL 99 70 h MATRIX Mx, where registers 89 and 99 contain the matrix descriptors and 70 is the base address for the result, which is not checked by the OS for overlap. In order to perform the equivalent of RCL MAT1 RCL MAT2 +, the only matrix operation I could find is M+x, which does not designate a result matrix and will overwrite the X matrix. To avoid this problem, one must first copy the X matrix to another nonoverlapping set of registers something like RCL 89 RCL 99 70 h MATRIX M.COPY h MATRIX M+x. On the HP 15C, one simply defines data matrices A and B, and a result matrix C, where the results of all operations are automatically stored without overwriting the original matrices.
For example, I wrote the following program function for my HP 15C to use with the Solver to find eigenvalue roots:
Where the operation MATRIX 9 is the determinant. Also, prior to execution, The result matrix C was created with the same dimension as A and B.
On the WP 34S this became:
Which is far more cumbersome and difficult to understand IMO.
Of course, I may have missed something here, and welcome any input if there is a better way to do this.
There is no matrix data type on the WP 34S, and matrices are defined by "descriptors" that point to a range of data registers where the matrix elements are stored. Matrix elements cannot be selected by their normal two digit row/column id, and instead it's up to the user to write down and remember which register contains which element. Furthermore, direct math operations cannot be performed e.g. RCL MAT1 RCL MAT2 x. In order to do this on the WP 34S one has to do something like RCL 89 RCL 99 70 h MATRIX Mx, where registers 89 and 99 contain the matrix descriptors and 70 is the base address for the result, which is not checked by the OS for overlap. In order to perform the equivalent of RCL MAT1 RCL MAT2 +, the only matrix operation I could find is M+x, which does not designate a result matrix and will overwrite the X matrix. To avoid this problem, one must first copy the X matrix to another nonoverlapping set of registers something like RCL 89 RCL 99 70 h MATRIX M.COPY h MATRIX M+x. On the HP 15C, one simply defines data matrices A and B, and a result matrix C, where the results of all operations are automatically stored without overwriting the original matrices.
For example, I wrote the following program function for my HP 15C to use with the Solver to find eigenvalue roots:
PHP Code:
LBL A
RCL MATRIX B
X
RCL MATRIX A

MATRIX 9
RTN
Where the operation MATRIX 9 is the determinant. Also, prior to execution, The result matrix C was created with the same dimension as A and B.
On the WP 34S this became:
PHP Code:
LBL 'EGV'
+/
RCL 89
RCL 99
70
M.COPY
M+x
DET
RTN
Which is far more cumbersome and difficult to understand IMO.
Of course, I may have missed something here, and welcome any input if there is a better way to do this.