Re: WP 34S: New Release on SF
Message #8 Posted by Paul Dale on 16 Sept 2011, 7:38 a.m.,
in response to message #7 by Ángel Martin
Don't worry, I'm still thinking about how best to do the matrix code. We can't do it exactly like the 42. We don't have a matrix type for starters. Leave that for the WP 43S :-) I'm quite happy to take suggestions for matrix operations and the primitives needed to support them. We're pretty much working with a blank slate here.
The M1-M3 routines are very useful when you're doing a row operations and no matter how many matrix decompositions I code, there will be more and many of these are done using such operations. So having these in some form kind of makes sense -- they really are basic low level routines. Think of them as the BLAS support code for the features in LAPACK or similar.
M4 and M5 are useful by themselves to convert x, y coordinates to register location and back. Again handy as a building block rather than a high level function. Even though I do like the 42's matrix/matrix an matrix/vector operations, I don't much like the 42's I and J access into matrices.
I've also supplied routines to create loop counters for row/column/entire matrix access. Again useful low level commands. Want an iterator to go down the third column of a matrix -- done.
These basic commands could be put into a keystroke library but then higher level routines that call them will become more complicated and need more temporaries.
I'd like to provide lots of higher level functions as well. Matrix inverse, determinant, eigen decomposition, Cholesky decomposition, LU decomposition, SVD, least squares, Jordan normal form, .... There are lots of possibilities here and a case could be made for any or all of them. Given that flash is quite tight, what subset makes most sense? Given that they will be smaller as keystroke code, what is the best suite of support routines to implement them with? Despite this which should be internal?
Although the low level functions might be annoying to use, XEQ'M^-1' which inverts the matrix from a descriptor on the stack won't be. Some of the above matrix operation might also merit coding in C where there are more resources available for temporary storage. e.g. an in-situ inverse or an eigen decomposition that doesn't require extra registers for temporary storage.
I've coded a matrix multiply internally for precision reasons. This will stay in C since doing it as a keystroke would be very hard without losing accuracy. Calling this is easy: matrix descriptors in Y and Z and a base register for the result in X. Mt* gives a matrix descriptor in X. Almost as good as the 42 and likely the best we can do on the 34S.
I've done a scalar multiply / matrix add operation. This could be coded via keystroke programming and would be smaller done that way. I might yet change it over. The in-situ transpose is another one that might change to key stroke for space reasons. the point is everything here is a space/usability tradeoff. Matrix support is not going to be a core 34S feature so I'm willing to lose a bit on the usability side.
Things are very much in a state of flux at the moment -- these functions are not in the firmware we're putting in the release archive and aren't documented. That will only change when we're happy with the basic suite of operations, if there ever even occurs.
Now if people want to volunteer to code the missing matrix commands as keystroke programs (or even doing them in C), please let us know. If, while doing so, a need appears for more basic operations, they will be implemented. This isn't going to be a trivial effort. I have several thick and heavy books dedicated to the numerical evaluation of matrix functions.
Still people have asked for matrix support and we're trying.
- Pauli
| 
Go back to the main exhibit hall