I've put up version 2.1 of the software on SourceForge.

Remarks:

1. Before you update: Use the wp34s_asm tool to transform your programs to text form. We've made changes that force a memory clear on the update. Flash libraries need to be recreated, too.

2. The number of flash regions is now 10 (0-9), including the backup. This will most probably change in later versions when we add more functions.

Please report back any findings. I'll be off to San Diego from Monday on till end of September with limited opportunities to fix bugs.

Thanks Marcus! See you in San Diego next week!

Quote:

---

I've put up version 2.1 of the software on SourceForge.

---

Franz

Quote:

---

Marcus, why is the matrix stuff not included yet?

Is it still not ready?

There's a matrix.wp34s in the SVN/library folder, but without the matrix stuff compiled in it's of course useless. :-(

---

You got it. The matrix stuff is for version 2.2. It's not yet ready for a release because Pauli is still working on it. There will eventually be versions in SVN with the routines built in. One major drawback is space: They cost us several K which reduces the number of user flash regions so it doesn't make sense to include them before they are finished.

From what I believe, it is not ready yet.

At HHC next week, I hope to show the PPC ROM translated matrix routines for the 34s, but I know the 34s native changes that will eventually be unveiled will be better.

So... Patience! It isn't quite ready yet. :-)

The native matrix code isn't necessarily better. It is different.

To start with, the space cost for them will be (much) larger than the keystroke programs. For the space of the internal versions you can easily have keystroke equivalents plus lots of other stuff in the lost flash pages. The keystroke versions would be less flexible but sufficiently functional.

The PPC ROM routines (M1 - M3) are utilities that allow easy row operations on matrices. We've not decided if the internal versions of these are worthwhile space wise or not -- the PPC code is very compact and quite usable. The internal code for these three routines is equivalent to many more steps than the PPC code requires. The internal code for M3 will be more accurate than a straight translation -- it is a vector multiply add -- but the keystroke program could be updated to match. On the plus side, the internal equivalents to these, if included, won't change the stack when run.

The PPC ROM routines M4 and M5 will likely exist as internals. I'm using a different format for matrix descriptors and having stack friendly ways to manage these makes any keystroke programs using them much simpler. Again, the keystroke code would be smaller but in this case flexibility is definitely more important. There will be a couple of other routines to manipulate matrix descriptors easily -- to build ISG or DSE loops for rows and columns e.g.

The internal code will also support matrix addition and multiplication. Both of these are missing from the PPC ROM. Multiplication in particular will benefit from the extended internal precision (although cases that exceed even this are possible). I've also done an in place transpose which might be better suited as a keystroke program.

I've not implemented a matrix inverse or determinant routine yet but I suspect the PPC example RRM code will be the way to go here.

Then there will need to be a pile of utility routines (matrix norms, min and max elements etc). These will best be done as keystroke code I suspect.

Anyway, lots of balancing to go.

- Pauli

I understand the real life constrains and practical reasons to consider using the M1-M5 routines - yet it's a pity that the 42 code couldn't be leveraged.

Sure being MCODE doesn't make it an easy (suitable?) candidate for direct translation, and I suppose the same issue exists with the CCD/Advantage matrix implementation. However I for one would not touch the M1-M5 with a 12-ft pole after having used the "real" stuff.

I'm not trying to create controversy here, just my individual opinion.

ÁM

Edited: 16 Sept 2011, 6:20 a.m.

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

Quote:

---

Please report back any findings.

---

IIRC then after opening any catalog (e.g. [h][P.FCN]) you were able to quickly jump to the functions by pressing their initial letters, and this even worked if you pressed another letter (e.g. if you've used a wrong one first) - at least I can remember that it has been so in previous versions.

But now only the first pressed/clicked letter is accepted, after this you can't access any other letter anymore!?

Is this a new bug introduced in the last few versions?

Franz

Pauli, I just read your post - got no time at this moment for a more elaborate answer but if FOCAL routines are a possible avenue, I'd suggest taking a detailed look at JM-Baillard's matrix libary:

http://hp41programs.yolasite.com/eigen.php

http://hp41programs.yolasite.com/matrixop.php

http://hp41programs.yolasite.com/determinant.php

Obviously all my Matrix modules are not useful, since it's all based on the CCD/Advantage foundation.

Cheers,
ÁM

Grüßdi Franz,

Quote:

---

... after opening any catalog (e.g. [h][P.FCN]) you were able to quickly jump to the functions by pressing their initial letters, and this even worked if you pressed another letter (e.g. if you've used a wrong one first) ...
But now only the first pressed/clicked letter is accepted, after this you can't access any other letter anymore!?

---

Walter

Quote:

---

... and make sure you read the footnote, too.

---

Didn't know that I would need a stopwatch (3 sec) for navigating through the menus. ;-)

Franz

It's just a way to navigate to the second or third letter of the name if you type fast enough. The arrow keys reset the search as does the 3 seconds delay.

I've looked at JM-Baillard's matrix code in some detail. I've been basing some of the decisions involved on his implementations -- he seems to have done the most key stroke matrix operations of anyone and has a rich suite available already.

I did change the matrix descriptor format to better match the 34S's memory layout and to improve the easy of use a little. There are utility routines to create and disassemble these currently, there will likely be a few more.

FOCAL is definitely the path to matrix functionality -- we don't have enough spare flash for a full implementation in C. We might have enough flash for key stroke programs even though they won't be as easy to use.

- Pauli

As mentioned, reading the manual may help sometimes - more often than you may expect 8-)

XROM may hide the differences.

Specially if the CPU is fast enough :)