WP-34s: TVM questions



#2

Hello all:

I have two questions about the TVM program in the flash library:

(1) The documentation ("TVM.wp34s") says: "program 'TVM' should be loaded into and called from RAM." How is this done? I scoured the manual, but I could not find any mention of copying a program from the flash-library into RAM.

(2) When I run the TVM program (from the flash library!), I cannot solve for an interest rate ('i'). A TVM calculation where I solve for a 'PMT' works fine, but when I change the 'PMT' ever so slightly and try to solve for 'i', I get nothing but "root not found". (This is *not* because there is no real solution!) Is this because I am running from flash, which is causing some problem for the solver?

Thanks,
Bruce.


#3

Bruce,

Some answers: (1) Please see the bottom of page 105 for loading the respective programs into flash memory. AFAIK it should be possible to run TVM in flash (but I didn't try yet). (2) I think that must be a bug in the SW ... :-/ Again, TVM should run in flash correctly, but I didn't write it.

Anyway, we'll check. Please tell us the parameters you use where the solver won't find a root. TIA

Walter


#4

Quote:
I think that must be a bug in the SW ... :-/

I'd rather vote for a bug in the user ... ;-)

(or anyone has changed ("vermurkst" in German) the solver code)
Quote:
Please tell us the parameters you use where the solver won't find a root.

Yes, that's the only way I could check it.

Edit: As for copying from flash to RAM: this isn't necessary anymore!

When I wrote the TVM program we still had a different local/global label handling, so it was more safe running TVM in RAM. But now it should work also directly in flash without problems.


Edited: 17 Apr 2012, 1:50 p.m.


#5

SORRY... That's what I get for not previewing first!

STEP ACTION
---- ------

(1) [CAT] and navigate to "TVM"
(2) R/S (to execute 'TVM' to initialize)

First a non-interest-solving problem:

(3) 12 [A] (N = 12 periods)
(4) 100 [B] (PV = 100)
(5) 0 [D] (FV = 0)
(6) 1 [XEQ][Rv] (i = 1% per period)
(7) [C] (solve for payment)

Display shows: -8.88488 (payment per period is $8.88)

Now, change the payment to -9.00, and solve for the interest rate:

(8) 9 [+/-] [C] (PMT = -9.00)
(9) [XEQ] [Rv]

Display shows: "No root Found"

However, if we then change the interest to 1.21% per period, we see that is basically what we should have gotten from the solver:

(10) 1.21 [XEQ][Rv] (i = 1.21% per period)
(11) [C] (solve for payment)

Display shows: -9.00320

So, why can't I solve for 'i', given N, PV, PMT, and FV?

Thanks,
Bruce.


#6

Quote:
So, why can't I solve for 'i', given N, PV, PMT, and FV?

Well, it should of course also solve for 'I' correctly, but you're right - I've checked your example and I also get this solver error message.

But try the same with I=5%, and then again change PMT just a bit, and in this case the solver works.

So the problem seems to be in the solver SLV, but since this is ROM code I can't do anything for this problem - that would be a task for Pauli or Marcus.

Edited: 17 Apr 2012, 2:40 p.m.

#7

FWIW, this example works fine for me, after step (9) I get:

I = 1.204345
(version 3.0 rev 2609)

--T


#8

In FIX 6 it works, in ALL it doesn't. So it seems to be a question of solver 'accuracy'.


#9

Quote:
In FIX 6 it works, in ALL it doesn't. So it seems to be a question of solver 'accuracy'.

Yes, you're right, FIX mode works.

But even in ALL mode when this example fails with an error message, both registers X and Y contain exactly the same (and correct) values to all digits, [-] gives exactly zero and Z contains 10^-15.

This strange SLV behaviour should indeed be changed, else it won't be useful to use this command in any serious program.

#10

Bruce, some time ago we had a discussion on a similar problem with a Cash-Flow program where the interest rate was the variable to solve for. The reason behind this was the solver itself that simply was too picky when it finally had to judge its own result (i.e. was a solution found or not). This may happen if even the best possible 16-digit interest rate will not return (quite) exactly zero for the function that's solved here.

However, a workaround was discussed: if Solve says it did not find a root, the returned result may be checked manually in order to see if it is "good enough" to be considered correct.

I am by no means sure that this is also the problem behind your case. But you can do a simple check: as soon as the "Solve Failed" message appears, please take a look at the returned value in X. What is your result here? If it looks like the correct interest rate it's exactly the same problem as the one that has been discussed earlier.

Dieter


#11

Dieter:

I am using "ENG 5" as my display mode. I just tried the entire sequence again, and after the "No root Found" message, I hit [EXIT] to clear the message, and the X-register contains 0.0120435, which *does* appear to be the correct amount (expressed as a fraction, not percent). So I think you nailed it.

The strange thing is that I even tried giving the root-solving process a second initial guess, using register-00, and no matter how good that second-guess is, the solver just *cannot* find the zero! (The source file says that the first guess is hard-coded to zero.)

I tried using "FIX 2" display mode, and I still frequently get "No root Found".

Thanks,
Bruce.


#12

Dieter:

Please ignore my comments about the second guess and the FIX mode; of *course* those will not help if the problem is internal to the solver.

I would definitely say that this should be addressed in the internal solver, because it *will* cripple its use...

Thanks for the help,
Bruce.


#13

Quote:
I would definitely say that this should be addressed in the internal solver, because it *will* cripple its use...

Yes, definitely. I thought this problem had been addressed after it has been discussed here half a year ago. Please take a look at
this thread from October 2011. Message #4, especially section 3, describes exactly the same problem you encountered. If you read further down the thread, you will find more details, thoughts and workarounds that may be applied here as well.

For example, take a look at message #8 and the IRR code starting at LBL C, especially line 061 ff. Here, the two returned solver results first are compared, and if they agree to (here) six digits, the result is considered okay. If they differ slightly, a second test checks whether f(x) in Z (which here is the NPV for the returned interest rate) is less than half a cent. In this case the solver result should be fine as well.

It is also explained why a fixed limit (maybe here 1E-16) for the function result simply makes no sense at all: if the function itself returns values near, say, 1E6 or 1E8, one ULP is as much as 1E-9 or 1E-7. The given examples of simple functions like x^2 - 7 = 0 throwing errors show that in many cases even the best possible 16-digit value does not return a function result that rounds to zero. Even worse, in SCI or ENG mode this never happens unless f(x) is exactly zero. ;-)

Also, the solver still seems to quit sooner or later depending on the set display format, i.e. as soon as the two most recent results agree in all displayed digits, and/or the function result rounds to zero. I think this should be removed from the solver code - the HPs with classic "HP Solve" function work independent from the display setting. If the user wants to set his own exit condition he may simply use something like a "FIX 4 ROUND" sequence at the end of his user function.

Dieter


Edited: 17 Apr 2012, 6:10 p.m.

#14

Bruce, until this problem is solved in the SLV routine, here's a workaround:

1) Load TVM into RAM: select it in the CATalog and press [RCL], then it's in the RAM

2) now do a [g][RTN] to go to LBL'TVM' in RAM

3) go to program mode with [h][P/R]

4) go before the last END with up-arrow

5) and insert the following 3 lines:

FIX 09
ROUND
ALL 00
Now running this modified TVM program should work also for interest calculations.

Edited: 17 Apr 2012, 4:34 p.m.


#15

fhub:

That answers my question about how to copy a flash-file into RAM!

Is there a mechanism in the WP-34s to store the display format? That is very handy when you want to change it in a program, but then restore it to the user's original condition at the end.

Thanks,
Bruce.


#16

STOM and RCLM are designed for this.

#17

... see page 30 :-)

#18

I know... I know... I managed to miss a lot in my first read-through! The manual is certainly information-dense! ;-)

(It is also an outstanding documentation effort!)

Thanks,
Bruce.

#19

Franz, you should use STOM nn and RCLM nn instead of hardcoding ALL 00. The commands are easily available by typing STO (or RCL) and then the CPX (MODE) key. They take a register to store and retrieve the present user visible mode settings.

Once the program has been fixed it can be copied back to flash by selecting it in CAT (watch for the RAM version!) and pressing STO which executes the PSTO command (also available in P.FCN). The present version in flash will be deleted and the new version will be added at the end of flash memory.


#20

Quote:
Franz, you should use STOM nn and RCLM nn instead of hardcoding ALL 00.

Yes Marcus, I know, but this would require an additional register.

And furthermore it was just a quick-and-dirty workaround, because I still hope that this SLV issue will be solved in the future. If not, then I'll certainly permanently modify my TVM program.

Franz

Edited: 17 Apr 2012, 4:52 p.m. after one or more responses were posted


#21

Modifying SLV is Pauli's territory, I'm afraid.

#22

Quote:
Yes Marcus, I know, but this would require an additional register.

For instance one of the stack registers. ;-)
STOM T
FIX 09
ROUND
RCLM T

Or, even better, imagine we had a round-command that accepts the number of digits as a parameter.

Dieter


#23

Quote:
Or, even better, imagine we had a round-command that accepts the number of digits as a parameter.

Yes, that's something that I've missed (and wondered about) since I discovered the WP34s project one year ago.

Definitely an excellent idea - but I don't make any suggestions anymore, so it's good that this idea comes from someone else. ;-)

Franz

#24

You mean the RSD command that has been in the firmware for quite a while now? Or isn't this command suitable for some reason?


- Pauli


#25

Quote:
You mean the RSD command that has been in the firmware for quite a while now? Or isn't this command suitable for some reason?

No, it doesn't round 1e-15 to zero, and this would be necessary for being accepted by the solver as solution.

BTW, trying to modify my TVM program I just tried to use x[approx]0? and found that even values upto 1e-40 gave "false" as result?

So which values are in fact 'approximately' zero, or is this a bug in this x[approx]0? function?

Franz


#26

RSD rounds to significant digits. The number 1e-15 has one significant digit '1'. It will never be rounded to something else. This command doesn't round to n decimal places which is what you seem to be wanting.

x[approx]0? rounds using the current display mode and compares against zero -- this is unfortunate because many near zero values don't get rounded in SCI, ENG or ALL display modes. It will do what you want in one of the FIX modes. This is not a bug, it is the intended behaviour of this comparison. We can't just pick a small number out of the air and pretend that that is near enough zero -- the number required would vary user to user and program to program.

And yes, using the round to display semantics makes the solver trickier. Trying to solve a function where f(0) = 0 will encounter this every time and I don't have a good solution.


- Pauli


#27

Quote:
This command doesn't round to n decimal places which is what you seem to be wanting.

Yes, that's exactly what I would like to have and also what Dieter suggested.

Franz

#28

As far as I understand the way X~~0? works, it simply rounds X according to the current display setting. In other words, it essentially behaves like the sequence "ROUND" and "X=0?". Please correct me if I'm wrong here.

This means that in ALL, SCI and ENG mode, X~~0? will never test true unless X is excactly zero. And that's what makes the solver think it failed. Even if f(x) is 1E-100, this result will not round to zero - it only will in FIX mode.

Within the solver it is impossible to set a fixed limit that ends the iteration if f(x) drops below that value. Simply because this limit depends from the magnitude of f(x):

Consider the example x^2 - 7 = 0. The best possible 16-digit solutions return either 2E-15 or -3E-15.

Now let's change this to x^2 - 7E10 = 0. The two best solutions return either 0,00002 or -0,00003.

Finally let's try x^2 - 7E-50 = 0. Even X=0 returns f(x) = -7E-50. This is extremely close to zero. So is this a root of f(x)? No, it's not.

IMHO the only useful option here is a test that determines where we the sign of f(x) changes as x is altered by one ULP. I think that the classic HP Solve implementation simply returns these two values that define the interval where the true X can be expected: For the last example, the (12-digit) HP-35s returns 2,64575131106 E-25 in X (best) and ...07 in Y (second best).

Do you think something like this may be a good solution?

Dieter


#29

Dieter:

That sounds a lot like the solution labeled "Sign Reversal" that some HPs I've used returned (HP-28s?). And in every case that I saw that, the two values returned represented the true zero, and the function was well-behaved in the region (no discontinuity).

Bruce.

#30

Oops - I was not aware of such a function. #-)

So we now have both RSD, rounding to n significant digits, and RDP which rounds to the specified number of decimals. Great. :-)

Dieter


#31

You should read the manual some more ;-)

- Pauli

#32

In the latest images is a new command RDP which takes an argument and rounds the value in X to that many decimal places (honouring the currently set rounding mode).


- Pauli


#33

Quote:
In the latest images is a new command RDP which takes an argument and rounds the value in X to that many decimal places (honouring the currently set rounding mode).

Now that's really a great new function, many thanks! :-)

I would have preferred the token RND, but that could be confused with the keyboard label RND for ROUND.

BTW, I see the following in wp34s.op:

0x9600 arg RDP max=100,indirect

I guess this 100 is not really intended - unless you're already working on triple or quad precision mode. ;-)

Franz


#34

Quote:
I guess this 100 is not really intended - unless you're already working on triple or quad precision mode. ;-)

Well, quad precision already got implemented. It's just called "double precision". ;-)

Dieter


#35

Quote:
Well, quad precision already got implemented. It's just called "double precision". ;-)

And I'm still waiting for arbitrary precision, i.e. implementing a CAS in the WP34s. :-)

Franz


#36

Quote:
And I'm still waiting for arbitrary precision, i.e. implementing a CAS in the WP34s. :-)

Memory constraints will prevent this I'm afraid. The 43S on the other hand....


The 100 decimal place limit is intentional. This will let you round very small numbers (e.g. 1.2345e-64 RDP 66 -> 1.23e-64). I'm not sure of the utility of this but the extension beyond the number of digits in a real doesn't cost any space at all.


- Pauli

#37

Pauli:

Yes, I second the thanks!

Bruce.

#38

Quote:
Franz, you should use STOM nn and RCLM nn instead of hardcoding ALL 00.

I would generally avoid ALL 00 since ALL 03 is much more useful anyway. ;-) But I want to address another point here:

Yes, the RND command in classic HPs used to round X to the number of displayed digits (or, in FIX mode, small values down to zero). If the user wants to round a number to n decimals or significant digits, the display format has to be altered first. And, as you said, the previous format should be restored afterwards.

All this could be avoided if the ROUND command accepted a parameter, i.e. the number of rounded digits. To please everyone, there may even be three different commands: ROUND works the way it used to, RNDD n rounds to n decimals (like FIX n, ROUND) and RNDS m will round to m significant digits (like SCI m-1, ROUND).

I would consider this a very useful feature. What do you think?

Dieter


#39

Dieter:

I agree; I like that. Having the three different rounding functions available would save program space and be an elegant solution!

Bruce.

#40

I think they are available already. Please see ROUND and RSD and more on page 67. :-)


#41

ROUND is no solution here since it does not accept a parameter. It simply rounds according to the display mode, and that's exactly what's not desired here. However, RSD works the way I suggested (sorry I did not realize that it was already there). An finally, in the meantime there also is the missing counterpart RDP. ;-)

Dieter

#42

Found and fixed a solver bug :-( Your problematic sequence works in the console emulator now -- a build will be forthcoming in due course.

The solver produced an error when the bounds on the estimate converged sufficiently rather than reporting success. The f(0) = 0 problem is still outstanding.


Pauli


#43

Quote:
The f(0) = 0 problem is still outstanding.

Just for curiousity: could you describe the problem with f(0)=0 ?

I can't imagine what/why could be a problem here? And if it is indeed, then why not just test for this condition?

Franz

Edited: 18 Apr 2012, 6:10 a.m.


#44

A function f such that f(x) -> 0 as x -> 0 runs into a rounding issue in all display modes except FIX. Both x and f(x) will be rounded to a non-zero value.

The solver rounds the function evaluation to the display mode and compares this against zero to decide if a root has been found. As f(x) goes to zero, this rounding does essentially nothing and the comparison is always false. Not a problem, I've got a check for this -- when the next estimate for x is approximately equal to the current, the searching stops.

The trouble stems from this approximately equal check of the estimates. Again, a round to the current display mode is used and if the estimates are close to 0 this doesn't do anything productive. In other words the interval of search keeps getting smaller and smaller and smaller but the bounds never actually compare equal after rounding. At least not before underflow, which isn't usually within the iteration limit.

I could introduce an equality threshold, but I'd never get the value right -- everyone would want different values at different times.


- Pauli


#45

Quote:
The trouble stems from this approximately equal check of the estimates. Again, a round to the current display mode is used and if the estimates are close to 0 this doesn't do anything productive.

Ok, why then not doing an exact equal check of the estimates before any rounding?

In the example TVM calculation in this thread both estimates (X and Y) are exactly the same values to all 16 digits when th solver stops with the error message. So a test for 'exactly equal' before any rounding and testing for 'approximately equal' should have avoided this problem, shouldn't it?


#46

Comparing the unrounded values is a stricter check than comparing the rounded ones, so there is no benefit to be gained unless I completely drop the rounded compare and then the solver will be less likely to converge.

The TVM problem is different, there was a bug in the solver -- it was raising the fail flag when it should have succeeded. Fixed in the next build hopefully.


- Pauli


#47

Quote:
Comparing the unrounded values is a stricter check than comparing the rounded ones, so there is no benefit to be gained unless I completely drop the rounded compare and then the solver will be less likely to converge.

Ok, then what about this idea:

Since you said that only in non-FIX mode you have those problems with f(0)=0, why not temporarily change to 'FIX n' mode only during the solving process (using the same 'n' as currently set with SCI, ENG or ALL by the user)?

Edited: 18 Apr 2012, 7:18 a.m.


#48

I'd already thought of this one :-) While this would address the problem of f(0)=0, the user wouldn't be getting what they asked for or what we promise.


- Pauli

BTW: n in ALL mode means something quite different to the other display modes.


#49

Quote:
I'd already thought of this one :-) While this would address the problem of f(0)=0, the user wouldn't be getting what they asked for or what we promise.

At least better than "No root found". ;-)

#50

Quote:

At least better than "No root found". ;-)


I prefer "no root found" and being able to decide if I want to use what's in X and Y over having a "root" displayed that really is none.

#51

I agree, that's why I discarded this solution.

The main cause of the "no root found" should have been addressed in the latest image.

Just not for zeroes at zero :-(


- Pauli

#52

Quote:
I prefer "no root found" and being able to decide if I want to use what's in X and Y over having a "root" displayed that really is none.

Well, probably not if you're writing a program and have to add a bunch of code just to check for these X & Y values in case of failure.

And the question remains: when is a root really a root? ;-)


#53

Quote:

Well, probably not if you're writing a program and have to add a bunch of code just to check for these X & Y values in case of failure.

And the question remains: when is a root really a root? ;-)


Well, probably yes - for the exact reason you're giving in your second sentence. :-)

#54

Quote:
Well, probably yes - for the exact reason you're giving in your second sentence. :-)

There would even be another approach that I've already suggested last year in a discussion about the same problem:

The solver could return "Dubious accuracy" (or something similar) in these special cases, so you would know you'd have to check the result. It's like having 3 states: root found, root probably found or no root found.

That's the way the TI-92+ shows that he had to do any 'dubious' calculations or assumptions.

Franz


#55

!


#56

Quote:
!

WOW, such a long and comprehensive reply won't really have been necessary! ;-)

Possibly Related Threads…
Thread Author Replies Views Last Post
  [WP-34S] Unfortunate key damage with update to V3 :( svisvanatha 5 3,299 12-10-2013, 11:37 PM
Last Post: Les Bell
  WP-34S (Emulator Program Load/Save) Barry Mead 1 1,878 12-09-2013, 05:29 PM
Last Post: Marcus von Cube, Germany
  DIY HP 30b WP 34s serial flash/programming cable Richard Wahl 2 2,607 12-04-2013, 11:14 AM
Last Post: Barry Mead
  WP 34S/43 ?'s Richard Berler 3 2,130 11-10-2013, 02:27 AM
Last Post: Walter B
  My FrankenCulator (wp-34s) FORTIN Pascal 4 2,250 11-09-2013, 06:18 PM
Last Post: FORTIN Pascal
  WP 34S Owner's Handbook Walter B 5 2,755 11-09-2013, 05:34 PM
Last Post: Harald
  wp 34s overlay and programming. FORTIN Pascal 6 2,988 11-08-2013, 01:28 PM
Last Post: Nick_S
  m.dy in display of WP-34S Harold A Climer 3 2,003 11-05-2013, 11:28 AM
Last Post: Andrew Nikitin
  WP 34s : An old problem coming back Miguel Toro 2 1,804 11-05-2013, 03:00 AM
Last Post: Marcus von Cube, Germany
  [WP 34s] Pressure Conversion Factors Timothy Roche 8 3,271 11-04-2013, 07:17 PM
Last Post: Dave Shaffer (Arizona)

Forum Jump: