▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
▼
Posts: 4,587
Threads: 105
Joined: Jul 2005
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 54
Threads: 13
Joined: Feb 2012
FWIW, this example works fine for me, after step (9) I get:
I = 1.204345
(version 3.0 rev 2609)
--T
▼
Posts: 429
Threads: 31
Joined: Jul 2011
In FIX 6 it works, in ALL it doesn't. So it seems to be a question of solver 'accuracy'.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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.
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
STOM and RCLM are designed for this.
Posts: 4,587
Threads: 105
Joined: Jul 2005
Posts: 180
Threads: 23
Joined: Apr 2012
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.
Posts: 3,283
Threads: 104
Joined: Jul 2005
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,283
Threads: 104
Joined: Jul 2005
Modifying SLV is Pauli's territory, I'm afraid.
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 180
Threads: 23
Joined: Apr 2012
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.
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
You should read the manual some more ;-)
- Pauli
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 180
Threads: 23
Joined: Apr 2012
Pauli:
Yes, I second the thanks!
Bruce.
Posts: 653
Threads: 26
Joined: Aug 2010
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
▼
Posts: 180
Threads: 23
Joined: Apr 2012
Dieter:
I agree; I like that. Having the three different rounding functions available would save program space and be an elegant solution!
Bruce.
Posts: 4,587
Threads: 105
Joined: Jul 2005
I think they are available already. Please see ROUND and RSD and more on page 67. :-)
▼
Posts: 653
Threads: 26
Joined: Aug 2010
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
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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?
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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.
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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". ;-)
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
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
Posts: 1,216
Threads: 75
Joined: Jun 2011
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? ;-)
▼
Posts: 429
Threads: 31
Joined: Jul 2011
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. :-)
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
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
▼
Posts: 429
Threads: 31
Joined: Jul 2011
▼
Posts: 1,216
Threads: 75
Joined: Jun 2011
Quote:
!
WOW, such a long and comprehensive reply won't really have been necessary! ;-)
|