HP Forums
Matrix operations -- WP 34S - Printable Version

+- HP Forums (https://archived.hpcalc.org/museumforum)
+-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html)
+--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html)
+--- Thread: Matrix operations -- WP 34S (/thread-199822.html)



Matrix operations -- WP 34S - Paul Dale - 10-06-2011

The matrix support operations are slowly of converging. There might be a few changes from here but most are now finalised.


I've swapped out the LU decomposition wrapper for the row operations. Does anyone want the explicit LU decomposition? Speak now or it is invisible forever -- I'm not aware of a use of the LU decomposition apart from finding determinants, inverses and solving linear equations (all of which we have).

I've updated the matrix multiply so that the result can replace or overlap the source matrices. This means you can square a 10x10 matrix safely. However, I'm at a loss as to how to do something similar for the generalised addition A = A + k B. Any suggestions? Should I split the constant multiple of a matrix from the matrix addition?

The loop index generating functions will probably stay as they are as will the register to I, J index and the reverse.

The matrix row operations are likely to stay but this is not yet not definite. For RREF they are useful. Beyond that???


The row and column query count functions might disappear... Anyone need a nicely behaved version of these instead of a user code version? The difference is lastX and the stack damage. These function are not much more than multiply by 100 and IP.


As for creating & initialising a matrix -- identity & zero are in user code now but they are mostly well behaved -- they damage L & nothing else. Marcus has done a matrix editor which should cover the rest pretty well.

What about a matrix copy? User code with stack damage or C and well behaved?


- Pauli

- Pauli


Re: Matrix operations -- WP 34S - fhub - 10-06-2011

Quote:
I've swapped out the LU decomposition wrapper for the row operations. Does anyone want the explicit LU decomposition? Speak now or it is invisible forever

I would say let it in!

The LU code is there (I guess you use it for DET/INV/LIN), so why not let the user have access to it? It would cost just a few bytes for this one additional opcode, right?
Quote:
Should I split the constant multiple of a matrix from the matrix addition?

I would prefer separated A+B and k*A.
Quote:
The matrix row operations are likely to stay but this is not yet not definite. For RREF they are useful. Beyond that???

Well, if you implement M.RREF then you could remove these row operations. ;-)

But like for M.LU: they already exist, so why hide it from the user?
Quote:
What about a matrix copy? User code with stack damage or C and well behaved?

I don't think this will be needed very often, and moreover it's just a register-copy, so user code would be ok.

A few more matrix functions come into my mind (trace, rank, charpoly, eigenvalues/vectors), but I guess you want the users to code some things by themselves!? :-)

All just my (humble) opinion of course ... ;-)

Franz


Re: Matrix operations -- WP 34S - Paul Dale - 10-06-2011

Quote:
I would say let it in!

The LU code is there (I guess you use it for DET/INV/LIN), so why not let the user have access to it? It would cost just a few bytes for this one additional opcode, right?

It ends up consuming a few hundred bytes of space for this. The routine needs to error check everything and to return the pivot values in a useful format. So the original question should have been what else is the LU decomposition useful for?


Quote:
Well, if you implement M.RREF then you could remove these row operations. ;-)

But like for M.LU: they already exist, so why hide it from the user?

The row operations are stand alone. I don't need them for the LU decomposition which has the code it requires internally -- it isn't doing full row operations, only partial ones.

I'm not planing a M.RREF at the moment, the row operations are more useful I feel. You can apply them to the base matrix and the adjoint components separately e.g.


Quote:
A few more matrix functions come into my mind (trace, rank, charpoly, eigenvalues/vectors), but I guess you want the users to code some things by themselves!? :-)

User code for these unless there is a pressing reason to do them internally -- flash is too full already. Trace is easy & in the library. The rest aren't there. Of course code donations are welcome :-)


- Pauli


Re: Matrix operations -- WP 34S - Marcus von Cube, Germany - 10-06-2011

Quote:
The row and column query count functions might disappear... Anyone need a nicely behaved version of these instead of a user code version? The difference is lastX and the stack damage. These function are not much more than multiply by 100 and IP.

I vote for leaving them in because they know about defaults (rr=cc) which would otherwise be a bit tricky in user code. They are used in the MED routine which would need a rewrite then.

M.CPY can simply be coded with R.CPY so I don't see a need for this.


Re: Matrix operations -- WP 34S - fhub - 10-06-2011

Quote:
It ends up consuming a few hundred bytes of space for this.

Well, then it's indeed a bit too much overkill. I just thought you would use this LU code for the other operations (DET/INV/LIN) so I saw no reason to have the code included but not making it available.
Quote:
I'm not planing a M.RREF at the moment, the row operations are more useful I feel. You can apply them to the base matrix and the adjoint components separately e.g.

Yes, I just remembered another usage where the row operations would be quite useful: solving linear optimization problems (by the Simplex method). Long time ago I've written such a simplex program for the HP-48 (and TI-92+), but since it also covers and calculates multiple solutions it is quite complex, and so I doubt I would like to ever code this program for the WP34s. ;-)

And for the other operations: you're right - there must still be something left to do for the users. ;-)

What you've implemented so far wrt. matrix operations is more than enough (and in fact very useful), many thanks for this!

Franz


Re: Matrix operations -- WP 34S - Paul Dale - 10-06-2011

Check the older revisions of matrix.wp34s on subversion for user code equivalents. They consume three stack levels which makes using them a bit annoying but the number of keystroke steps required wasn't large.

- Pauli