HP Forum Archive 21

[ Return to Index | Top of Index ]

WP-34s: TVM questions Message #1 Posted by W. Bruce Maguire II on 17 Apr 2012, 12:35 p.m. 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.

Re: WP-34s: TVM questions Message #2 Posted by Walter B on 17 Apr 2012, 1:26 p.m., in response to message #1 by W. Bruce Maguire II 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

Re: WP-34s: TVM questions Message #3 Posted by fhub on 17 Apr 2012, 1:29 p.m., in response to message #2 by Walter B 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.

Re: WP-34s: TVM questions Message #4 Posted by W. Bruce Maguire II on 17 Apr 2012, 1:53 p.m., in response to message #3 by fhub 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.

Re: WP-34s: TVM questions Message #5 Posted by fhub on 17 Apr 2012, 2:39 p.m., in response to message #4 by W. Bruce Maguire II 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.

Re: WP-34s: TVM questions Message #6 Posted by Tom Grydeland on 17 Apr 2012, 2:56 p.m., in response to message #4 by W. Bruce Maguire II FWIW, this example works fine for me, after step (9) I get: I = 1.204345 (version 3.0 rev 2609) --T

Re: WP-34s: TVM questions Message #7 Posted by Alexander Oestert on 17 Apr 2012, 3:33 p.m., in response to message #6 by Tom Grydeland In FIX 6 it works, in ALL it doesn't. So it seems to be a question of solver 'accuracy'.

Re: WP-34s: TVM questions Message #8 Posted by fhub on 17 Apr 2012, 4:01 p.m., in response to message #7 by Alexander Oestert 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.

Re: WP-34s: TVM questions Message #9 Posted by Dieter on 17 Apr 2012, 3:11 p.m., in response to message #4 by W. Bruce Maguire II 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

Re: WP-34s: TVM questions Message #10 Posted by W. Bruce Maguire II on 17 Apr 2012, 3:53 p.m., in response to message #9 by Dieter 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.

Re: WP-34s: TVM questions Message #11 Posted by W. Bruce Maguire II on 17 Apr 2012, 4:30 p.m., in response to message #10 by W. Bruce Maguire II 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.

Re: WP-34s: TVM questions Message #12 Posted by Dieter on 17 Apr 2012, 5:16 p.m., in response to message #11 by W. Bruce Maguire II 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.

Re: WP-34s: TVM questions Message #13 Posted by fhub on 17 Apr 2012, 4:33 p.m., in response to message #10 by W. Bruce Maguire II 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.

Re: WP-34s: TVM questions Message #14 Posted by Marcus von Cube, Germany on 17 Apr 2012, 4:46 p.m., in response to message #13 by fhub 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.

Re: WP-34s: TVM questions Message #15 Posted by fhub on 17 Apr 2012, 4:50 p.m., in response to message #14 by Marcus von Cube, Germany 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

Re: WP-34s: TVM questions Message #16 Posted by Marcus von Cube, Germany on 17 Apr 2012, 4:52 p.m., in response to message #15 by fhub Modifying SLV is Pauli's territory, I'm afraid.

Re: WP-34s: TVM questions Message #17 Posted by Dieter on 17 Apr 2012, 6:01 p.m., in response to message #15 by fhub 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

Re: WP-34s: TVM questions Message #18 Posted by fhub on 17 Apr 2012, 6:11 p.m., in response to message #17 by Dieter 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

Re: WP-34s: TVM questions Message #19 Posted by Paul Dale on 17 Apr 2012, 7:35 p.m., in response to message #17 by Dieter 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

Re: WP-34s: TVM questions Message #20 Posted by fhub on 18 Apr 2012, 5:24 a.m., in response to message #19 by Paul Dale 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

Re: WP-34s: TVM questions Message #21 Posted by Paul Dale on 18 Apr 2012, 5:36 a.m., in response to message #20 by fhub 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

Re: WP-34s: TVM questions Message #22 Posted by fhub on 18 Apr 2012, 5:41 a.m., in response to message #21 by Paul Dale 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

Re: WP-34s: TVM questions Message #23 Posted by Dieter on 18 Apr 2012, 5:07 p.m., in response to message #21 by Paul Dale 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

Re: WP-34s: TVM questions Message #24 Posted by W. Bruce Maguire II on 18 Apr 2012, 5:17 p.m., in response to message #23 by 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.

Re: WP-34s: TVM questions Message #25 Posted by Dieter on 18 Apr 2012, 4:37 p.m., in response to message #19 by Paul Dale 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

Re: WP-34s: TVM questions Message #26 Posted by Paul Dale on 18 Apr 2012, 5:43 p.m., in response to message #25 by Dieter You should read the manual some more ;-) - Pauli

Re: WP-34s: TVM questions Message #27 Posted by Paul Dale on 18 Apr 2012, 7:47 a.m., in response to message #17 by Dieter 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

Re: WP-34s: TVM questions Message #28 Posted by fhub on 18 Apr 2012, 1:31 p.m., in response to message #27 by Paul Dale 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

Re: WP-34s: TVM questions Message #29 Posted by Dieter on 18 Apr 2012, 4:39 p.m., in response to message #28 by fhub 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

Re: WP-34s: TVM questions Message #30 Posted by fhub on 18 Apr 2012, 4:58 p.m., in response to message #29 by Dieter 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

Re: WP-34s: TVM questions Message #31 Posted by Paul Dale on 18 Apr 2012, 5:38 p.m., in response to message #30 by fhub 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

Re: WP-34s: TVM questions Message #32 Posted by W. Bruce Maguire II on 18 Apr 2012, 2:00 p.m., in response to message #27 by Paul Dale Pauli: Yes, I second the thanks! Bruce.

Re: WP-34s: TVM questions Message #33 Posted by Dieter on 17 Apr 2012, 5:35 p.m., in response to message #14 by Marcus von Cube, Germany 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

Re: WP-34s: TVM questions Message #34 Posted by W. Bruce Maguire II on 17 Apr 2012, 5:47 p.m., in response to message #33 by Dieter Dieter: I agree; I like that. Having the three different rounding functions available would save program space and be an elegant solution! Bruce.

Re: WP-34s: TVM questions Message #35 Posted by Walter B on 18 Apr 2012, 1:36 a.m., in response to message #33 by Dieter I think they are available already. Please see ROUND and RSD and more on page 67. :-)

Re: WP-34s: TVM questions Message #36 Posted by Dieter on 18 Apr 2012, 5:27 p.m., in response to message #35 by Walter B 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

Re: WP-34s: TVM questions Message #37 Posted by W. Bruce Maguire II on 17 Apr 2012, 4:46 p.m., in response to message #13 by fhub 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.

Re: WP-34s: TVM questions Message #38 Posted by Marcus von Cube, Germany on 17 Apr 2012, 4:50 p.m., in response to message #37 by W. Bruce Maguire II STOM and RCLM are designed for this.

Re: WP-34s: TVM questions Message #39 Posted by Walter B on 17 Apr 2012, 5:06 p.m., in response to message #37 by W. Bruce Maguire II ... see page 30 :-)

Re: WP-34s: TVM questions Message #40 Posted by W. Bruce Maguire II on 17 Apr 2012, 5:31 p.m., in response to message #37 by W. Bruce Maguire II 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.

Re: WP-34s: TVM questions Message #41 Posted by Paul Dale on 18 Apr 2012, 6:00 a.m., in response to message #1 by W. Bruce Maguire II 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

Re: WP-34s: TVM questions Message #42 Posted by fhub on 18 Apr 2012, 6:07 a.m., in response to message #41 by Paul Dale 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.

Re: WP-34s: TVM questions Message #43 Posted by Paul Dale on 18 Apr 2012, 6:42 a.m., in response to message #42 by fhub 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

Re: WP-34s: TVM questions Message #44 Posted by fhub on 18 Apr 2012, 7:06 a.m., in response to message #43 by Paul Dale 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?

Re: WP-34s: TVM questions Message #45 Posted by Paul Dale on 18 Apr 2012, 7:14 a.m., in response to message #44 by fhub 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

Re: WP-34s: TVM questions Message #46 Posted by fhub on 18 Apr 2012, 7:17 a.m., in response to message #45 by Paul Dale 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.

Re: WP-34s: TVM questions Message #47 Posted by Paul Dale on 18 Apr 2012, 7:30 a.m., in response to message #46 by fhub 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.

Re: WP-34s: TVM questions Message #48 Posted by fhub on 18 Apr 2012, 7:35 a.m., in response to message #47 by Paul Dale 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". ;-)

Re: WP-34s: TVM questions Message #49 Posted by Alexander Oestert on 18 Apr 2012, 7:57 a.m., in response to message #48 by fhub 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.

Re: WP-34s: TVM questions Message #50 Posted by Paul Dale on 18 Apr 2012, 8:00 a.m., in response to message #49 by Alexander Oestert 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

Re: WP-34s: TVM questions Message #51 Posted by fhub on 18 Apr 2012, 8:00 a.m., in response to message #49 by Alexander Oestert 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? ;-)

Re: WP-34s: TVM questions Message #52 Posted by Alexander Oestert on 18 Apr 2012, 8:43 a.m., in response to message #51 by fhub 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. :-)

Re: WP-34s: TVM questions Message #53 Posted by fhub on 18 Apr 2012, 8:51 a.m., in response to message #52 by Alexander Oestert 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

Re: WP-34s: TVM questions Message #54 Posted by Alexander Oestert on 18 Apr 2012, 9:12 a.m., in response to message #53 by fhub !

Re: WP-34s: TVM questions Message #55 Posted by fhub on 18 Apr 2012, 9:18 a.m., in response to message #54 by Alexander Oestert Quote: ! WOW, such a long and comprehensive reply won't really have been necessary! ;-)

[ Return to Index | Top of Index ]

Go back to the main exhibit hall