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.

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

Quote:

---

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

---

Quote:

---

Please tell us the parameters you use where the solver won't find a root.

---

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.

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.

Quote:

---

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

---

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.

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

I = 1.204345

--T

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

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

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.

Quote:

---

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

---

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.

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.

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

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

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.

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.

STOM and RCLM are designed for this.

Quote:

---

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

---

Franz

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

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

... see page 30 :-)

Quote:

---

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

---

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.

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.

Quote:

---

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

---

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

Dieter:

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

Bruce.

Quote:

---

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

---

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

Quote:

---

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

---

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

Franz

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

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

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?

---

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

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

Quote:

---

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

---

Franz

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

Quote:

---

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

---

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.

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

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.

---

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?

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

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.

---

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

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.

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.

---

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

Quote:

---

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

---

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

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.

---

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

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? ;-)

---

Quote:

---

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

---

Franz

!

Quote:

---

!

---

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).

---

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

Pauli:

Yes, I second the thanks!

Bruce.

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

Quote:

---

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

---

Dieter

Quote:

---

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

---

Franz

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

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.

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

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

You should read the manual some more ;-)

- Pauli