Extended TVM-solver for the WP34s



#30

I've now finally finished my extended TVM-program. :-)

The first version of such a TVM-solver I've written in the good old HP-41 days, and since then ported it to many other different calculators (Sharp PC-1500, HP-48, TI-92+ ...).

I call it 'extended' because it has 2 additional parameters NP and NI (in English PF and CF for payment/compound frequency) which allows to set different periods for payments and compounding.

And furthermore it also handles 'perpetual payments' (i.e. where N=infinite), anticipative discount rates (NI<0) and continuous (or theoretical) compounding (NI=0).

It has 256 steps and is in *.wp34s format, so it can be compiled with the WP34S assembler - and a quite detailled description is included.

Let me know if there's any interest - I could either post it directly here in the forum or upload the file to my website.

Franz

Edited: 6 Aug 2011, 11:12 a.m.


#31

Quote:
Let me know if there's any interest - I could either post it directly here in the forum or upload the file to my website.

For sure there's interest! I'd suggest uploading your file to SourceForge where the WP 34S lives. If you agree, please send it to any member of the development team, and we'll put it in for you :-)

Walter


#32

Quote:
I'd suggest uploading your file to SourceForge where the WP 34S lives. If you agree, please send it to any member of the development team, and we'll put it in for you :-)

Well Walter, I prefer a place where I have access to.

What if I would like to change anything?

Or what if a bug has to be fixed - although that's very unlikely because my programs never have bugs. ;-)

I've sent it now to Marcus ...

Of course feel free to add my 'Extended TVM-Solver' to your project site at Sourceforge if you want, but first make sure that it will meet your high quality standards for WP34s programs ... :-)

Franz


Edited: 8 Aug 2011, 8:28 a.m. after one or more responses were posted


#33

I'm sure it will meet our standards. :-)

WP 34S features are still emerging and so it may be necessary to adapt existing software. Remember the recent discussion about labels beyond A to D. We are willing to keep the included programs in sync with the current feature set. If we find any discrepancy between used and available features we will happily adapt the code included in the package, including yours.


#34

A short note, Marcus:

I guess your changes of the shortcut labels are now permanent, so maybe it would be a good idea to also fix the TVM-solver code, because with the current build it doesn't work anymore as expected.

LBL G, H and I (in lines 047, 054 and 061) should be changed to LBL 21, 22 and 23 resp.

And there's a small typo in the description at th beginning:

After "Keyboard-Layout:" in 00N the 00 should be replaced by 2 spaces - I don't know where these 2 zeros are coming from!?

And maybe the 3 occurences of 'FIN' could be changed to 'TVM', but that's just a matter of taste and I let this be your decision. ;-)

Franz

Edited: 9 Aug 2011, 5:57 a.m.


#35

BTW, I've found a nice trick for the problem to clear the stack but retain the X register (which was in discussion about my previously used method):

RCL- X
FILL
RCL L
Of course no big deal, but saves one byte again ... ;-)

PS: Once again I forgot something: since now there's this new error message for SLV, I've also changed this message in the program.

And furthermore I've also included the financial equations which are used in TVM in case someone is interested in these formulas.

The updated current version of TVM can be found here:

http://www.hpmuseum.org/guest/fhub/tvm.zip

Edited: 9 Aug 2011, 7:22 a.m.


#36

An updated version of your code is now in the pre-compiled library. :-)

I have yet to check the latest ZIP package for the documentation changes.


#37

Quote:
An updated version of your code is now in the pre-compiled library. :-)

I have yet to check the latest ZIP package for the documentation changes.


Yes, you should better use this new ZIP, because it contains a few corrections.

You only have to add your 'Intro' (=Vorspann) ... :-)

(maybe a 'sound intro' would be nice, too ;-))


Edited: 9 Aug 2011, 8:10 a.m.

#38

Franz,

Quote:
- program 'TVM' should be loaded into and called from RAM

Any reason for this? The program should work fine in the library space.


#39

Quote:
Any reason for this? The program should work fine in the library space.

Well, I've made some 'strange' experiences while testing the program, and since I have no explanation for this I thought it would be safer to have it in RAM.

The problem was the following:

I've opened the catalog with [h]CAT and clicked ENTER. I don't know exactly what internally happens when doing this, but it seems that the program-counter is then in the Flash-ROM and everything is working fine: I can list the program with [h]P/R and I can XEQ the shortcut labels, but: only those which end with a GTO 00 statement - if e.g. I do a XEQ 09 (which ends with RTN) to evaluate the TVM expression, the program-counter seems to be 'out of flash' after this RTN, and from that moment on none of the number-labels (00-09) is working anymore: trying to XEQ them just gives "No such label" (and also [h]P/R doesn't list the program anymore). I have to select the TVM program once more from the catalog to make it work again. Exactly the same happened after I made a GTO.. (I just wanted to restart it with R/S to reset all values) - after that the 34s also seems to 'forget' my TVM program.

So I believe that manually starting or excuting a program that ends with a RTN (or doing a GTO..) sets the program-counter back into the RAM, and so the program in the flash-ROM is no longer accessable (unless you chose it again).

I'm not sure if this is intended this way, but I just have too little internal knowledge about the WP34s - and I also haven't found any detailed infos about this so far.

Franz


Edited: 9 Aug 2011, 11:59 a.m.


#40

I'll check it with Pauli. Thanks for the info. As long as you stick to the hot keys, everything is fine from the library space.


#41

I just saw another small issue: when you go to program mode and view the listing of a flash program, then the first step starts with 002 (and also all other line numbers are one too high).

And for the other problem above - I think it's just the way RTN is implemented:

if a RTN at the end of a subroutine is executed, then it goes back to the address on the return-stack IF the subroutine was call from within a program. But if the user executes this subroutine manually, then there is no return address on the stack, and so the RTN command just jumps to the beginning of the programspace in RAM!

And this is the point: maybe it should not always return to the top of the programspace in RAM, but to the top of the 'currently selected' programspace, i.e. to the top of the Flash when this Flash was the last being used.


Edited: 9 Aug 2011, 1:23 p.m.


#42

Regarding the listing issue I need to check it for myself.

You have fully understood the RTN problem. I've started a discussion with Pauli what the best way to treat this would be. Your proposal is one possible option.

#43

Quote:
As long as you stick to the hot keys, everything is fine from the library space.

Yes, but - after thinking more about it - this is also working only because my hotkey routines don't end with a RTN but with a STOP command. If they had a RTN at the end then after the first call of such a routine the program counter would be out of the flash again and every further hotkey usage would fail.

So it's indeed really a problem for every program called or used directly from the flash space. :-(

#44

Quote:
Well Walter, I prefer a place where I have access to.

Ask and I'll give you subversion access.

Quote:
Of course feel free to add my 'Extended TVM-Solver' to your project site at Sourceforge if you want, but first make sure that it will meet your high quality standards for WP34s programs ... :-)

The program looks good. Only two very minor things to consider changing. Alpha registers are special so the saving and restoring the value into K at steps 13 and 15 isn't the best -- it will prevent using the statistical distributions and this financial package together. I'd suggest using L for this since that has been destroyed anyway rather than a grabbing another numeric register. Damn, CLSTK wipes out L so that won't work :-(

The other is the relevance of some of the error messages -- "bad mode" is used everywhere else to indicate that the device is in integer/real mode and the operation selected is only valid in real/integer mode. Like I said, fairly minor.

There are also a couple of SKIP statements that SKIP to a RTN. Why not just replace them with a RTN. e.g. Lines 78 and 84. Also, we're in the process of rethinking the extra labels again so there will likely be further changes in this area.

Anyway, a good library routine to have.

- Pauli


Edited: 6 Aug 2011, 8:08 p.m.


#45

How about this to avoid using K:

	010 LBL 00	// return after input or calculation
011 FS?C 00
012 SKIP 04
013 STO L
014 0
015 FILL
016 RCL L
017 STOP // wait for input or calculation
018 BACK 01 // [R/S] -> clears ENTRY? flag

Costs one step and saves using one register.

This also avoids zeroing the I register which CLSTK does.


- Pauli

Edited: 6 Aug 2011, 8:20 p.m.


#46

Quote:
Costs one step and saves using one register.

Well, I've now changed it (a 2nd time) to:
010 LBL 00	// return after input or calculation
011 FS?C 00
012 SKIP 03
013 STO 09
014 CLSTK // remove intermediate results
015 RCL 09
016 STOP // wait for input or calculation
017 BACK 01 // [R/S] -> clears ENTRY? flag
Now it uses R09 instead of K - this register is only used internally and is always re-initialized before any new calculation, so using it here won't hurt (and all following line numbers don't change with this method).


Edited: 7 Aug 2011, 5:37 a.m.

#47

Quote:
Damn, CLSTK wipes out L so that won't work :-(

Haha, using L is exactly what I also tried first.
Quote:
The other is the relevance of some of the error messages -- "bad mode" is used everywhere else ...

Well, it's the best error message I found for this case. ;-)

Trying to use a 'final' value (FV) for an 'infinite' number of periods (N) is something that could also be seen as "being in a bad mode". :-)
Quote:
There are also a couple of SKIP statements that SKIP to a RTN. Why not just replace them with a RTN. e.g. Lines 78 and 84.

That's just my tidiness: I like to have a 'logical' program structure, and one thing that belongs to this is that a procedure of function has exactly one entry point and one exit point. So it's easier to see where the end of a subroutine is: just look for the next RTN - with several RTNs this is a bit confusing.

And for your other suggestion to replace this register K usage:

Well, clearing the stack at the end won't really be necessary at all - once again the fault of my tidiness. ;-) I just don't like to have any useless (intermediate) results on the stack. But maybe a simple FILL (the stack with the result) would be the best solution and even save a few bytes more!? :-)

Franz


#48

Quote:
Well, clearing the stack at the end won't really be necessary at all - once again the fault of my tidiness. ;-) I just don't like to have any useless (intermediate) results on the stack. But maybe a simple FILL (the stack with the result) would be the best solution and even save a few bytes more!?

Hmmmh, my understanding of tidiness at the end of a routine is having the result in X, and the other levels containing what was therein before calling said routine. Finishing a routine with CLSTK or FILL is a strategy of "burnt soil" IMHO ;-)

Walter


#49

Quote:
Hmmmh, my understanding of tidiness at the end of a routine is having the result in X, and the other levels containing what was therein before calling said routine. Finishing a routine with CLSTK or FILL is a strategy of "burnt soil" IMHO ;-)

Yes, in a strict sense you're right, Walter. :-)

But this would require saving the stack before and restoring it after any calculations.

And since there's no such command in the WP34s (unless you're using still other registers Rnn), you would have to code it yourself.

Ok, not really a big problem (in SSIZE4 mode):

SaveStack:
cpx STO A
cpx x<>y
cpx STO C
cpx x<>y

RestoreStack:
cpx RCL C
cpx RCL A

But this would cost another few bytes in the (always too small) RAM ... ;-)

BTW, the 2 routines above together with

SwapStack:
cpx x<>A
cpx x<>y
cpx x<>C
cpx x<>y
would be a nice enhancement of the 34s commands: S-SAVE, S-REST and S-SWAP (or S-STO, S-RCL and S-SWP) like the similar R-commands, won't it? :-)

(SaveStack and SwapStack work even in SSIZE8 mode, only RestoreStack needs some modifications for SSIZE8)

Franz


Edited: 7 Aug 2011, 7:17 a.m.


#50

What about STOS and RCLS ??

We don't have a swap stack command but it doesn't seem all that useful to me.


- Pauli


#51

Quote:
What about STOS and RCLS ??

Well, you seem to have overlooked my comment "(unless you're using still other registers Rnn)". ;-)
Quote:
We don't have a swap stack command but it doesn't seem all that useful to me.

You can never have enough stack manipulation commands ... :-)

Such a SwapStack command would be like a 'quad' x<>y (compared to the existing 'cpx' x<>y)

Franz


Edited: 7 Aug 2011, 8:53 a.m.

#52

Quote:
What about STOS and RCLS ??

I just had another idea:

What if these commands would accept A as destination (STOS A and RCLS A)?

Of course this should only use 4 stack registers (storing XYZT and recalling ABCD) even in SSIZE8 mode - this would then (almost) exactly do what I've intended with my above SaveStack and RestoreStack: in SSIZE4 it saves and restores XYZT, and in SSIZE8 it would just act as XYZT->ABCD (for STOS A) and ABCD->XYZT (for RCLS A).

Edited: 7 Aug 2011, 9:21 a.m.


#53

Well Franz, you've got 100 general purpose registers - use four of them at a nice address :-)


#54

Quote:
Well Franz, you've got 100 general purpose registers - use four of them at a nice address :-)

100? My other calculators let me use thousands registers ... ;-)

#55

Honestly, what do you want to do with more than 100 general purpose registers in such a calculator? Will be difficult to keep track of them already :-/


#56

Quote:
Honestly, what do you want to do with more than 100 general purpose registers in such a calculator? Will be difficult to keep track of them already :-/

Well, as soon as you would like to deal with matrices, 100 registers are almost nothing.

#57

Quote:
as soon as you would like to deal with matrices, 100 registers are almost nothing.

You're right in principle, but
  1. I won't like to deal with them, since IMHO matrix math exceeds the limits of the UI of such a small scientific calculator - people are used to viewing a whole matrix at once nowadays, which is obviously impossible with the HW given,
  2. if I were forced do deal with them, I won't employ any matrices larger than 4x4,
  3. even with 5x5, two complete different systems of linear equations are easily stored simultaneously in the memory provided so far,
  4. I didn't hear a widespread request for matrix math library routines yet.
Thus I don't see a problem here :-) YMMV

Edited: 9 Aug 2011, 5:40 p.m.


#58

Yes, I agree with you in (almost) all points - matrix math is definitely "one shoe number too large" (as we say in German ;-)) for the 34s.

And if you have to address them via sequential register numbers Rnn (instead of A[i,j]) the handling would in fact be a nightmare.

But I'm using it on the HP48GX and the TI92+ without problems, and especially on the latter it really makes fun - but of course not 100x100 monsters. :-)


Possibly Related Threads...
Thread Author Replies Views Last Post
  hp-prime solver and variable name fabrice48 22 2,685 12-10-2013, 03:25 AM
Last Post: fabrice48
  HP Prime Triangle solver BruceH 29 2,584 11-28-2013, 12:03 AM
Last Post: Dale Reed
  Using units in Numeric Solver Harold A Climer 1 394 10-13-2013, 10:44 AM
Last Post: Tim Wessman
  Does Prime Have a Multiple Equation Solver? Norman Dziedzic 2 424 09-20-2013, 09:43 AM
Last Post: Norman Dziedzic
  TVM again ;-) fhub 17 1,465 09-02-2013, 11:03 AM
Last Post: fhub
  ILPer with "auto-extended addressing" Christoph Giesselink 0 356 07-23-2013, 03:28 PM
Last Post: Christoph Giesselink
  Just a lazy solver algortihm PGILLET 1 397 06-28-2013, 11:47 PM
Last Post: Namir
  TVM WP34s trouble Jim P 4 632 06-28-2013, 07:31 AM
Last Post: fhub
  [43s] : How the solver will be implemented Miguel Toro 3 566 03-14-2013, 06:09 PM
Last Post: Walter B
  TVM-Solver for the PC fhub 14 1,273 12-26-2012, 03:24 PM
Last Post: fhub

Forum Jump: