The Museum of HP Calculators

HP Forum Archive 20

 34s: TVM problem?Message #1 Posted by gene wright on 28 July 2011, 4:30 p.m. I can get the TVM example in the manual to work to solve for a payment, but I can't get it to work solving for the interest rate. I don't see any disclaimer about the interest rate being a special case... ? Here's what I did: -800 STO 80 90000 STO 81 0 STO 82 0 STO 83 360 STO 84 Then set up a program for: LBL IYR SLV 01 NOP RTN LBL 01 STO 83 XEQ TVM RTN and I get positive infinity as the result seemingly regardless of the initial guess. The answer should be about 0.85 (or 0.0085 since it does not use the x100 view). Help? Gene

 Re: 34s: TVM problem?Message #2 Posted by Marcus von Cube, Germany on 28 July 2011, 4:43 p.m.,in response to message #1 by gene wright What happens if you XEQ 01 with your estimated solution in X?

 Re: 34s: TVM problem?Message #3 Posted by gene wright on 28 July 2011, 5:02 p.m.,in response to message #2 by Marcus von Cube, Germany I single-stepped to LBL 01. Keyed in 0.008 and pressed R/S. I saw -36.6560 in the display.

 Re: 34s: TVM problem?Message #4 Posted by Marcus von Cube, Germany on 28 July 2011, 5:09 p.m.,in response to message #3 by gene wright If your assumption is correct, the result should be near zero. Maybe you didn't get the signs of the parameters right?

 Re: 34s: TVM problem?Message #5 Posted by Dieter on 29 July 2011, 9:49 a.m.,in response to message #4 by Marcus von Cube, Germany The result actually is close to zero - for i = 0,008 it's just 36,66 "money units", which is close to nothing compared to the other values. The correct interest rate (0,00846072 to six significant places) returns a value less than 0,0003. Gene's problem most probably is the TVM routine not handling zero interest rates combined with the requirement of two non-zero initial guesses. See my other post below. Dieter

 Re: 34s: TVM problem?Message #6 Posted by Paul Dale on 28 July 2011, 5:41 p.m.,in response to message #3 by gene wright The 12c give 0.85 as the answer to this problem so there is an issue with the TVM routine in XROM. I couldn't be bothered fixing a financial function though :-) The TVM code is exactly: ``` LBL'TVM' RCL 80 RCL 81 RCL+ 82 1 RCL+ 83 RCL 84 y[^x] DEC X / RCL+ 81 RCL[times] 83 FC? 80 SKIP 03 RCL 83 INC X / + RTN ``` Anyone care to try fixing the equation? The solver also makes mistakes from time to time...but that doesn't seem to be the issue here. - Pauli

 Re: 34s: TVM problem?Message #7 Posted by Jim Horn on 28 July 2011, 8:08 p.m.,in response to message #6 by Paul Dale Perhaps I'm mistaken, but the formula shown in the manual is "PMT-"..., not "PMT+"... so I'd expect the second from last step to be a "-", not a "+". Yes?

 Re: 34s: TVM problem?Message #8 Posted by Paul Dale on 28 July 2011, 9:16 p.m.,in response to message #7 by Jim Horn I think the + is correct. If you set the initial bounds to .8 and .9 the solver finds the root in about ten iterations: 0.008460723396753903. Some other bounds I tried failed. So this is more like the solver going awry. - Pauli

 Re: 34s: TVM problem?Message #9 Posted by Miguel Toro on 28 July 2011, 10:30 p.m.,in response to message #8 by Paul Dale Hi Pauli, I think that Jim is correct. I compared the program with the formula in the manual and based on that the last instruction before RTN should be "-", if I am not mistaken. Salut, Miguel

 Re: 34s: TVM problem?Message #10 Posted by Paul Dale on 28 July 2011, 11:44 p.m.,in response to message #9 by Miguel Toro The solver gets the correct answer with a plus and not with a minus but I'll verify the formula this evening. - Pauli

 Re: 34s: TVM problem?Message #11 Posted by Paul Dale on 29 July 2011, 12:07 a.m.,in response to message #6 by Paul Dale I checked this and I am fairly confident the function is correct. I don't know where Walter got the equation in the manual from but the one being solved is: ```PMT + I/k (PV + (PV + FV) / ( (1 + I)^n - 1 ) = 0 ``` This is a rearangement of the PMT = equation in the manual. I don't see where people are coming from saying the first + should be a -. - Pauli

 Re: 34s: TVM problem?Message #12 Posted by Miguel Toro on 29 July 2011, 1:25 a.m.,in response to message #11 by Paul Dale Hi, Yes, you are right. The equation in the manual should then read "PMT +" and so on and not as it is now. Thanks, MiguelEdited: 29 July 2011, 1:28 a.m.

 Re: 34s: TVM problem?Message #13 Posted by Walter B on 29 July 2011, 1:59 a.m.,in response to message #12 by Miguel Toro IMHO the top equation on page 76 of the manual is just a rearrangement of the equation for PMT in the next row. Walter

 Re: 34s: TVM problem?Message #14 Posted by Bart (UK) on 29 July 2011, 6:37 a.m.,in response to message #13 by Walter B Editions of the manual from at least 1.4 up to Edition 2.0 released with build 1107, p72 has the formula incorrect.Later Edition 2.0 (again) of the manual released with build 1173, p73 has the formula corrected.Suggestions:Walter:Better version numbering (many changes were made to the manual released as version 2.0) - perhaps add an alphabetical letter to it?Forumers:Use the lateast version of the manual (latest I can find is version 2.1 released with build 1344)Note: these are observations and suggestions, I am not telling anyone what to do. Please take it in the spirit of trying to help.

 Re: 34s: TVM problem?Message #15 Posted by Miguel Toro on 29 July 2011, 9:00 a.m.,in response to message #14 by Bart (UK) Thank you Bart for pointing to the lastest version of the manual. By the way, I would like to thank Pauli, Walter and Marcus fos this amazing development of a calculator. This is an awesome work what you are doing here, guys! Regards, Miguel

 Re: 34s: TVM problem? Something about our manualMessage #16 Posted by Walter B on 29 July 2011, 12:20 p.m.,in response to message #14 by Bart (UK) Bart, Quote: Editions of the manual from at least 1.4 up to Edition 2.0 released with build 1107, p72 has the formula incorrect.Later Edition 2.0 (again) of the manual released with build 1173, p73 has the formula corrected.Suggestions:Walter:Better version numbering (many changes were made to the manual released as version 2.0) - perhaps add an alphabetical letter to it?Forumers:Use the lateast version of the manual (latest I can find is version 2.1 released with build 1344) Thanks for your report and suggestions. No need for excuses - we've proven we can take whatever comes, but you have to take our response as well ;-) That said, let's start: Edition 1.4 didn't contain TVM at all. Please note you are closely watching a development project. Almost everything we do is reflected in SourceForge. I don't know any other calculator development being so open to the community. OTOH you may see a lot of errors, features coming and going again. If you don't want to cope with that, please wait for the official release. With respect to edition counting: You may have noticed we update our files frequently. If each and every little change or correction would get a new number, the editions would run up to hilarious values IMHO. So we refrain from doing this. But help is near: SourceForge does the counting for us :-) And you find a screen shot of a recent build on the title page of each manual - this may give you some idea what's covered. Real bugs are still found - thanks to the community for reporting them. IF you want to see the latest committed edition of the manual, look here: http://wp34s.svn.sourceforge.net/viewvc/wp34s/doc/ and choose the file "Manual_wp_34s_...". Again, this may be full of errors still - TIA to everybody reading it and reporting to me whatever (s)he thinks is wrong / misleading / arcane / annoying / whatever ... There will happen nothing worse than you get an answer thanking you (see above) etc. ;-) Disclaimer: This is written to advance understanding, no offence intended. HTH, Walter

 Re: 34s: TVM problem? Something about our manualMessage #17 Posted by Bart (UK) on 30 July 2011, 6:54 a.m.,in response to message #16 by Walter B Quote:Edition 1.4 didn't contain TVM at all.You are right, it was another version 2.0 I was looking at, released with a build in June (I don't think there was ever a 1.4 released?)Quote:Please note you are closely watching a development project.Yes, my last sentence intended to convey that these are observations, not criticisms. As I commented in this thread I hold you all in high regard and am very thankful for the effort and time spent on this project.Quote:With respect to edition counting: You may have noticed we update our files frequently. If each and every little change or correction would get a new number, the editions would run up to hilarious values IMHO. So we refrain from doing this.The TVM section changed from one formula to four formulas, which I personally think is quite a major change.However:Quote:But help is near: SourceForge does the counting for us :-) ...Indeed, we can always reference a manual together with the sourceforge no. i.e. "edition 2.1 - 1327" ;-)Thank you again for all the effort,Bart

 Re: 34s: TVM problem? Something about our manualMessage #18 Posted by Walter B on 30 July 2011, 8:16 a.m.,in response to message #17 by Bart (UK) Quote:I don't think there was ever a 1.4 released? None that you could see :-) Quote:As I commented in this thread I hold you all in high regard and am very thankful for the effort and time spent on this project. Thank you for your kind words in other posts as well. Generally, however, my response goes just to the post I'm answering. I apologize for not taking into account all of your publications ;-)Quote:The TVM section changed from one formula to four formulas, which I personally think is quite a major change.Three more formulas in a 80 page paper, well ... YMMV :-) Walter

 Re: 34s: small manual errorMessage #19 Posted by fhub on 30 July 2011, 10:09 a.m.,in response to message #18 by Walter B For Walter: Looking in the manual for S.L and S.R I found a small bug: The statements about multiplication or division with a factor 10^n are correct, but not the decimal point/comma is shifted left or right (for S.L or S.R) but the number itself, i.e. its digits are shifted as the function name suggests - the radix is in fact shifted exactly in the opposite direction as the function name says. Franz Edited: 30 July 2011, 10:10 a.m.

 Re: 34s: small manual errorMessage #20 Posted by Walter B on 30 July 2011, 5:02 p.m.,in response to message #19 by fhub Franz, you're right. Maybe we shall swap the command names. Walter

 Re: 34s: small manual errorMessage #21 Posted by fhub on 30 July 2011, 5:40 p.m.,in response to message #20 by Walter B Quote: Franz, you're right. Maybe we shall swap the command names. But then it won't correspond anymore with the shifting functions of binary integers. I would just say you should simply explain it in the manual as "shifting the numbers/digits left or right" instead of the radix, which is also the usual understanding for binaries. Franz

 Re: 34s: small manual errorMessage #22 Posted by Walter B on 30 July 2011, 6:13 p.m.,in response to message #21 by fhub Well, the commands were called S.L / S.R on purpose ;-) But we may as well call them SDL / SDR :-) Walter

 Re: 34s: small manual errorMessage #23 Posted by fhub on 30 July 2011, 6:18 p.m.,in response to message #22 by Walter B Quote: But we may as well call them SDL / SDR :-) Indeed not a bad idea! This dot in the mid seemed always a bit 'suspicious' to me. :-)

 Re: 34s: small manual errorMessage #24 Posted by Marcus von Cube, Germany on 30 July 2011, 6:23 p.m.,in response to message #23 by fhub SDL and SDR would nicely translate to Shift Decimal (or Digit) Left / Right. In the various binary modes the commands could even be context sensitive shifting the digits depending on the base. Edited: 30 July 2011, 6:24 p.m.

 Re: 34s: small manual errorMessage #25 Posted by fhub on 30 July 2011, 6:30 p.m.,in response to message #24 by Marcus von Cube, Germany Quote: SDL and SDR would nicely translate to Shift Decimal (or Digit) Left / Right. Yes, that was exactly my idea too. Quote: In the various binary modes the commands could even be context sensitive shifting the digits depending on the base. Oh, I think this would give a problem when you use this command in a program - running it in different base modes would then give different results. :-(

 Re: 34s: small manual errorMessage #26 Posted by Paul Dale on 30 July 2011, 7:38 p.m.,in response to message #22 by Walter B We're those two my initial suggestions? Or at least quite like to them? Just checked -- I used SLD and SRD :-) I'd prefer not making these commands available in integer mode if I can help it. They are provided to make breaking a real number into and out of digit fields quick and easy -- they operate by incrementing or decrementing the real's exponent field directly. Combine them with IP and FP and a lot of steps are saved in addition to executing faster. In integer mode, they'll correspond to multiplication or division by a power of the base (which can be any value 2 through 16). There is no way to simplify the operation into shifts and adds and all the overflow and underflow conditions will have to be detected and handled. More effort than it is worth for a specialised function. - Pauli Edited: 30 July 2011, 7:39 p.m.

 Re: 34s: small manual error -> SDL & SDRMessage #27 Posted by Walter B on 31 July 2011, 11:24 a.m.,in response to message #26 by Paul Dale FYI, SDL and SDR are now in and documented. Walter

 Re: 34s: TVM problem? Something about our manualMessage #28 Posted by Walter B on 31 July 2011, 4:49 p.m.,in response to message #17 by Bart (UK) Quote: Quote:But help is near: SourceForge does the counting for us :-) ...Indeed, we can always reference a manual together with the sourceforge no. i.e. "edition 2.1 - 1327" ;-) I forgot: We also have a date in the very last row of the release notes - on the last page of the manual. So belt and braces ... :-) Walter

 Re: 34s: TVM problem?Message #29 Posted by Dieter on 29 July 2011, 8:02 a.m.,in response to message #6 by Paul Dale I haven't checked the formula, but there is one thing I would strongly recommend: Please avoid coding the TVM-formula literally, i.e. do not write it as (1+i)^n - 1. We should be glad to have ln1+x and e^x-1 on the 34s, so please, please use it and write this term as e^x-1(n*ln1+x(i)): ``` ... RCL 83 LN1+x RCLx 84 e^x-1 ... ``` It's shorter and, most important, provides exact results even for low interest rates. If you're not convinced, please see the example in the 15C Advanced Functions Handbook p. 173 and 180ff. I also do not know what initial guesses for the interest rate are used for the 34s solver routine. The standard pac of the 34C with its included TVM program might be a useful source here. Dieter

 Re: 34s: TVM problem?Message #30 Posted by Paul Dale on 29 July 2011, 8:26 a.m.,in response to message #29 by Dieter Dieter, thanks for that. I can't believe I missed this improvement :-( The 34S doesn't provide any initial guesses, the user gets to do that. - Pauli

 Re: 34s: TVM problem?Message #31 Posted by Dieter on 29 July 2011, 9:41 a.m.,in response to message #1 by gene wright Gene, you will get an +/- infinity error because the TVM routine cannot handle zero interest rates - in this case it tries to divide by zero. You can see this if you enter values very close to zero (0.0001, 1E-10, 1E-15...) followed by XEQ 01 and the results will approach -550, while i = 0 returns the mentioned error. This would not happen if the TVM equation was programmed so that it can handle this case as well. ``` (1+i)^n - 1 i -> 0 => ----------- -> n i ``` Instead, the TVM routine tries do divide by (1+0)^n - 1 = 0 and therefore throws an error. Due to the limited precision of the current implementation this is the case for i < 1E-15 (results first lose precision and finally the error message appears). The Solver does not provide any intial guess for the interest rate, so it's up to you to set two estimates in X and Y. If X or Y are zero the mentioned error will abort the calculation. If there are two good guesses before invoking SLV 01 (say: 0,001 ENTER 1), the 34s will return the correct result. I tried this on the emulator (an old version, 2.0 1054) and it returned the correct result 0,00846072 or 0,846%. So, the problem occured because of two ...special features of the TVM routine: First, it does not provide any intial guess - it's up to you to set guess1 ENTER guess 2. And second, the TVM equation is unable to handle i = 0. It should be rewritten to do so. So your approach was fine - and you will get the correct result if (and only if) you provide two non-zero guesses for the interest reate. Dieter Edited: 29 July 2011, 9:56 a.m.

 Re: 34s: TVM problem?Message #32 Posted by fhub on 29 July 2011, 10:40 a.m.,in response to message #31 by Dieter Hi Dieter, it seems I'm not the only 'financial interested guy' here. ;-) Here's my TVM routine which handles also i=0 correctly, and I've also rearranged the equation a bit to make the code shorter (except the new i=0 handling of course): ```LBL 'TVM' RCL 83 x!=0? SKIP 03 RCL+ 84 RCL* 80 SKIP 10 1/x FS? 80 INC X RCL* 80 RCL+ 81 RCL 83 ln1+x RCL* 84 e^x-1 * RCL+ 81 RCL+ 82 RTN ------- 20 steps ``` I've tested it with the above mentioned values and it works perfectly, almost any initial guesses (except complete nonsense values of course) now give the correct solution, and the first guess may even be 0 now. :-) But the problem that most users forget to give 2 initial guesses still exists - and I'd really prefer if the values for I would have to be entered in % (and not as interest 'rate', i.e. divided by 100), because this is much more usual for us humans (and also easier to input). Franz PS: my rearranged TVM formulas: i=0: n*PMT+PV+FV=0 i!=0: ((1/i+k)*PMT+PV)*((1+i)^n-1)+PV+FV=0 with k=0 for END payments and k=1 for BEG payments And if the interest value "I" is given in %, then TVM looks like this: ```LBL 'TVM' RCL 83 x!=0? SKIP 03 RCL+ 84 RCL* 80 SKIP 13 1 % STO Y 1/x FS? 80 INC X RCL* 80 RCL+ 81 x<->y ln1+x RCL* 84 e^x-1 * RCL+ 81 RCL+ 82 RTN ------- 23 steps ``` Edited: 29 July 2011, 1:19 p.m. after one or more responses were posted

 Re: 34s: TVM problem?Message #33 Posted by Tim Wessman on 29 July 2011, 11:37 a.m.,in response to message #32 by fhub Here's a comment from the math library that might interest you: ```//PSI = w^(N-1)+w^(N-2)+...w+1; w=1+i //Two Cases depending on the value of i: // | i=0 | i#0 | // PSI | N | [w^N - 1]/i | // w^N | 1 | (1+i)^N | // Algorithm: For 0 # |i|<<1 accuracy is preserved by using // the functions: E(x)=e^x-1 & L(x)=Ln(1+x). // PSI=[(1+i)^N-1]/i = E{N*L(i)}/i ``` TW Edited: 29 July 2011, 11:38 a.m.

 Re: 34s: TVM problem?Message #34 Posted by fhub on 29 July 2011, 11:49 a.m.,in response to message #33 by Tim Wessman Quote: Here's a comment from the math library that might interest you: Thanks Tim! 'math library' of which calculator? Maybe I can find some other interesting things there ... ;-) Franz

 Re: 34s: TVM problem?Message #35 Posted by Tim Wessman on 29 July 2011, 2:45 p.m.,in response to message #34 by fhub That code comment is from the Saturn Math library. I imagine you want more info about the Napier math library though. Napier is a platform independent C recreation of the saturn math library developed using the Saturn ASM from several units. Developed as part of the 20b and since used in the 30b, 10bII+, 12cp iphone app, some other software calculators (like what comes with the calcpad), and will be used in things moving forward. That is why the solver in the 30b gets exact results as the 48 series, and the forensics are identical. TW Edited: 29 July 2011, 2:48 p.m.

 Re: 34s: TVM problem?Message #36 Posted by gene wright on 29 July 2011, 12:14 p.m.,in response to message #31 by Dieter Ah thanks. I did not see a reference that two guesses were required in the manual. But, hey... my question may lead to a better TVM routine in the unit. Woohoo.

 To TVM or not to TVM?Message #37 Posted by Dieter on 29 July 2011, 1:46 p.m.,in response to message #36 by gene wright In fact we now got a proposal for a better TVM routine in the 34s. Maybe there's an even better solution - let me think one step further: Mathematically, the TVM equation usually does not require any guesses at all to solve for one of their variables. This is because for PV, FV, PMT and N there are more or less simple closed form solutions that do not require any guessing - if you want to know the value for an annual payment, simply calculate it directly. The interest rate is the only exception here - for this case there is no explicit solution, so the Solver is required for an iterative approach. This leads to the Solver numerically solving the TVM equation for the interest rate i, which in turn requires two guesses given by the user. In other words, providing a TVM equation is only useful for this single case, i.e. when the interest rate is unknown. This is where the 34s differs from the way other HPs work: The 35s, for example, also can store such an equation in order to solve for any of its variables. The essential point here is the ability of the 35s to solve for all variables (except i) without any interaction of the user. No initial guesses are required as the user wants to solve for PMT, FV or other values, and the result shows up immediately because it is calculated directly by the 35s. The solver built into this device is able to realize that every variable (except i) shows up only once in the TVM equation, so that it can solve directly for this variable by rearranging the equation. No guesses required. Only if it's the interest rate that has to be solved for, it has to rely on an iterative approach, requiring two guesses. This is what makes the difference between a "sophisticated solver" like the one in the 35s and a purely numeric solver like the one in the 34s (and 34C, 15C etc.). The more "intelligent" version like the one in the 35s is a nice example for using the solver with not more than just one single equation, even in cases where an explicit solution exists - the calculator will return this explicit solution without any initial guesses or more or less time-consuming iterations. On devices where such a solution is not possible, I think it's much better to code the direct solution for every single variable. So does the TVM program in the HP-41 standard pac: variables like PV, FV, PMT and N are evaluated directly, while the interest rate is calculated by iteration. A first estimate is set by the program, the user does not have to care about this. So, what's the use of an TVM equation in the 34s? It is nice for determining the interest rate, using the built-in solver, after the user has provided two initial guesses. Simply because there is no other way to solve for this variable. For all other cases a simple direct solution exists - but since the current approach uses the iterative solver in these cases as well, the user has to enter two estimates for each and every variable - and hope that they are good enough to lead to the correct result. That's why I think the TVM equation does not make much sense in the 34s. As opposed to calculators with more sophisticated solvers like the 35s. For other devices, I think four routines with the explicit solutions of the four variables are a far better solution. So I would recommend to either omit the TVM equation completely, or, if this functionality is really required, provide the four direct solutions. If you dislike both suggestions, at least there should be a clear hint in the manual and the given example, pointing out that using the TVM equation does not only require calling the solver but also two initial guesses. No, I do not think that "this is obvious because it applies to every call of the solver anyway". Just to be sure. ;-) Dieter

 Re: To TVM or not to TVM?Message #38 Posted by fhub on 29 July 2011, 2:27 p.m.,in response to message #37 by Dieter Quote: So I would recommend to either omit the TVM equation completely, or, if this functionality is really required, provide the four direct solutions. Well, of course your 2nd suggestion would be the best solution, but there's just not enough space for all 4 formulas, and financial calculations are simply not of high priority in the WP34s project (I know what I'm talking about - I made some experiences in the past here with my suggestions about this issue ;-)). But I definitely don't agree with your 1st suggestion - although the method with the solver is not optimal, but why should then this TVM equation be completely removed now that my improved version above works so much better and it uses just a few bytes? With the same argument you could remove the whole solver because it can't solve EVERY equation - or the integration routine because it certainly can't integrate EVERY function. And back to TVM: If someone really needs a better TVM routine, there's always the possibility to write those 4 rearranged solution formulas by himself. Franz

 Re: To TVM or not to TVM?Message #39 Posted by Marcus von Cube, Germany on 29 July 2011, 4:32 p.m.,in response to message #38 by fhub There are certainly better TVM machines then the 34S. Take the 30b for example. ;-) TVM was implemented as a goody and it still needs some coding around to be useful. It's more of a proof of concept or nice example with some generic value. It shouldn't be too complicated to code the four equations for a direct solution and set up a routine for the i solver with automatic guesses. This can then be put in a library file and stored in flash. That's the preferred way of adding features to the 34S which do not require extended precision (only internally available) or hardware support (like serial I/O). Many math problems can be solved in user code and be provided as a library. Matrix and vector arithmetic is one the areas which needs a volunteer to port some existing code.

 Re: To TVM or not to TVM?Message #40 Posted by Paul Dale on 29 July 2011, 7:14 p.m.,in response to message #37 by Dieter I looked at including individual routines to solve for each of the parameters using the closed form formulas where possible and the space require was larger than I could justify for a piece of functionality that really is just a nice to have tack on in a scientific calculator. That doesn't mean I'm closed to the idea, just that I'm not going to spend the time writing very compact but still properly functioning versions of this for each of the five possibilities. - Pauli

 Re: To TVM or not to TVM?Message #41 Posted by Paul Dale on 29 July 2011, 7:17 p.m.,in response to message #37 by Dieter Quote:That's why I think the TVM equation does not make much sense in the 34s. This matches my thoughts too but Walter seemed adamant about having it and the implementation then was only about forty bytes (now it is fifty). - Pauli

 Re: To TVM or not to TVM?Message #42 Posted by Walter B on 30 July 2011, 3:38 a.m.,in response to message #41 by Paul Dale Quote: Quote:That's why I think the TVM equation does not make much sense in the 34s. This matches my thoughts too but Walter seemed adamant about having it ... In fact TVM is the only reason why I reach out for a financial calculator. Thus I requested this - thinking it may be more useful than much of the arcane mathematical items we kept adding ;-) Walter

 Re: To TVM or not to TVM?Message #43 Posted by Paul Dale on 30 July 2011, 3:44 a.m.,in response to message #42 by Walter B Quote:...much of the arcane mathematical items we kept adding ;-) You vetoed a lot of really good really arcane stuff :-) Who wouldn't love having Mills's constant built into the device? - Pauli

 Re: To TVM or not to TVM?Message #44 Posted by Walter B on 30 July 2011, 4:33 a.m.,in response to message #43 by Paul Dale Quote: Who wouldn't love having Mills's constant built into the device? Do you want me to start a poll? TVM vs. Mill's? ;-) Walter

 Re: To TVM or not to TVM?Message #45 Posted by Paul Dale on 30 July 2011, 4:36 a.m.,in response to message #44 by Walter B Come on Mills's constant would win by a landslide :-P It is hard to think of a more exciting number. And no, no poll is required. I require my delusions to stay intact :-) - Pauli

 Re: 34s: TVM problem?Message #46 Posted by Paul Dale on 29 July 2011, 7:10 p.m.,in response to message #31 by Dieter Thanks for the suggestions. I've modified the TVM routine to handle the i of zero case. Initial estimates of 0 and 1 work now. So do estimates of 0.8 and 0.9 which aren't even close to bracketing the solution. It is still possible to confuse the solver with estimates that are on the silly side. - Pauli

 Re: 34s: TVM problem?Message #47 Posted by fhub on 30 July 2011, 1:30 a.m.,in response to message #46 by Paul Dale Quote: I've modified the TVM routine to handle the i of zero case. I've looked at your modification, but it's not quite ok. As you do it (with the PLUS and then the SKIP(11) jumps again to the last PLUS), the value PMT is added once more, so your expression is now PV+FV+N*PMT+PMT. Simply making SKIP(11) to SKIP(12) would be ok, BUT it leaves the first entered PMT on the stack, so there has to be done a bit more (e.g. move this first PMT at the end before the last PLUS) BTW, why don't you use my code posted above which is just 20 steps compared to your 24? Franz Edited: 30 July 2011, 2:06 a.m.

 Re: 34s: TVM problem?Message #48 Posted by Paul Dale on 30 July 2011, 3:03 a.m.,in response to message #47 by fhub Quote:I've looked at your modification, but it's not quite ok. As you do it (with the PLUS and then the SKIP(11) jumps again to the last PLUS), the value PMT is added once more, so your expression is now PV+FV+N*PMT+PMT. The code as written is fine. It leaves PMT in Y but that is harmless since this routine is meant to be called by the solver and the solver does it own thing with the stack. Quote:BTW, why don't you use my code posted above which is just 20 steps compared to your 24? I tried your code, it didn't work starting with guesses of 0.8 and 0.9 :-( It was easier to fix my code than figure out what was wrong. - Pauli

 Re: 34s: TVM problem?Message #49 Posted by fhub on 30 July 2011, 3:18 a.m.,in response to message #48 by Paul Dale Quote: The code as written is fine. It leaves PMT in Y ... No, the code is NOT fine! It doesn't leave PMT in Y but adds it once more to PV+FV+N*PMT. And BTW, a guess of 0.8 and 0.9 would mean 80 and 90% !!! Not very useful guesses I'd say (especially if the interest rate of this problem is 0.85%) ... Edited: 30 July 2011, 3:23 a.m.

 Re: 34s: TVM problem?Message #50 Posted by Paul Dale on 30 July 2011, 3:33 a.m.,in response to message #49 by fhub Quote:No, the code is NOT fine! Oops, I should look harder :-( Fixed now. Quote:And BTW, a guess of 0.8 and 0.9 would mean 80 and 90% !!! Not very useful guesses I'd say (especially if the interest rate of this problem is 0.85%) ... I know it is a bit silly, however it is a legitimate initial guess. Especially for someone who forgets to supply any guesses. Robust code shouldn't care too much. - Pauli

 Re: 34s: TVM problem?Message #51 Posted by fhub on 30 July 2011, 4:00 a.m.,in response to message #48 by Paul Dale Quote: I tried your code, it didn't work starting with guesses of 0.8 and 0.9 :-( It was easier to fix my code than figure out what was wrong. Absolute nothing was wrong with my code! I've now tried it here again exactly with your nonsense guesses of 0.8 and 0.9, and the correct result is given without any problems. I really don't know what's your problem with me, but no matter what I post - everything is either criticized or claimed to be wrong, even if I'm 100% right. I've now really enough of your behaviour - I wish you much fun and success in your WP34S development, but don't expect to see any further contribution to your project from ME here in the future! Franz

 Re: 34s: TVM problem?Message #52 Posted by Paul Dale on 30 July 2011, 4:20 a.m.,in response to message #51 by fhub I just tried your code again and the answer it gives for starting guesses of .8 and .9 is 0.4891696495606895. The solver is getting confused and convergence is *very* slow reaching its iteration limit before a solution is obtained. I've triple checked what I've typed in against what you wrote above and am pretty sure I've got the code right. Could you verify that what you're running matches what you entered above. Just to be absolutely sure, the code I'm running is: ```ADDR OPCODE MNEMONIC 0001: 5b64 LBL A 0002: 6100 SLV 00 0003: 013a RTN 0004: 013a RTN 0005: 5b00 LBL 00 0006: 2453 STO 83 0007: 8803 PSE 03 0008: 5301 SKIP 01 0009: 1354 4d56 GTO'TVM' 000b: 5b67 LBL D 000c: 2b53 RCL 83 000d: 0018 x[!=]0? 000e: 5303 SKIP 03 000f: 2c54 RCL+ 84 0010: 2e50 RCL[times] 80 0011: 530a SKIP 10 0012: 020b 1/x 0013: 6d50 FS? 80 0014: 5a64 INC X 0015: 2e50 RCL[times] 80 0016: 2c51 RCL+ 81 0017: 2b53 RCL 83 0018: 0211 LN1+x 0019: 2e54 RCL[times] 84 001a: 0212 e[^x]-1 001b: 0303 [times] 001c: 2c51 RCL+ 81 001d: 2c52 RCL+ 82 001e: 013a RTN ``` - Pauli

 Re: 34s: TVM problem?Message #53 Posted by fhub on 30 July 2011, 4:43 a.m.,in response to message #52 by Paul Dale Quote: Could you verify that what you're running matches what you entered above. Yes, it's the same code. But I must stand corrected: I've in fact confused this 4.89E-1 with the true value 8.46E-3, so with these guesses my routine does indeed not work. But that doesn't change anything on the above mentioned fundamental problem you seem to have with me ... Franz

 Re: 34s: TVM problem?Message #54 Posted by Walter B on 30 July 2011, 5:23 a.m.,in response to message #53 by fhub Franz, Based on my experience, some people here are not accustomed to the direct way we learn in our country. OTOH, you can't expect others being excited about your suggestions everytime, so some "marketing" may be worth considering. And never forget you may get answers of a similar kind - so get used to take them. Walter

 Re: 34s: TVM problem?Message #55 Posted by Dieter on 30 July 2011, 8:13 a.m.,in response to message #54 by Walter B Quote: Based on my experience, some people here are not accustomed to the direct way we learn in our country. ...in our countries - Franz is from Austria. But well, the Holy Roman Empire is not much more than 200 years ago now, so it's still easy to confuse these things. ;-) Quote: OTOH, you can't expect others being excited about your suggestions everytime, so some "marketing" may be worth considering. Advertising. Marketing is much, much more than that. Dieter

 Re: 34s: TVM problem?Message #57 Posted by Paul Dale on 30 July 2011, 3:28 a.m.,in response to message #1 by gene wright I've got a suggestion. First up, I remove TVM from the xrom segment. What is there does what we wanted of it when we decided to include it, however it seems that it doesn't do what the community wants. Secondly, this community writes a suite of financial functions in user code. We then include this code as the one of the user program flash segments as part of the build process. The contents and nature of this suite is completely open. Use the solver or use the dedicated formulas. Add other financial functions. The only limit will be the whole shall be one program flash segment only. That's 506 steps unless some trickery is performed. I'll make a few suggestions and ideas but nothing hard and fast: Avoid using lettered registers as temporaries, they are the easiest ones for users to use and firmware ought to avoid them. The four hot keys are available if a program stops with a R/S rather than a RTN. Subroutines are cheap and space saving, use lots. Make the source compatible with the assembler. So what do people think of this suggestion? What other functionality suites could be included in a similar manner? Volunteers? - Pauli PS: I'd do the two steps in the opposite order -- get the suite going and then I'll remove the TVM routine.

 Re: 34s: TVM problem?Message #58 Posted by Marcus von Cube, Germany on 30 July 2011, 3:53 a.m.,in response to message #57 by Paul Dale I second Pauli's suggestion. Here is a head start for a library application: ```LBL 'FIN' SSIZE4 // We need registers A to D CLa "Finance" aVIEW LBL 00 STOP LBL A ENTRY? SKIP 01 XEQ 'F-A' // compute A STO A GTO 00 LBL B ... ``` This allows A, STO A, RCL A as keys to compute, set or examine parameter A. Hitting A will compute A if the entry flag was not set, otherwise it will store A. You will have easy access to four different parameters. Giving the subroutine that does the actual work an alpha label will make it available to other programs. After each computation, the PC is moved to the beginning of the application in order to make the hot key labels the first to be found when the respective keys are pressed. This suggestion is not in contradiction to Pauli's hint not to use the lettered registers. In this case, it's the user interface and it makes perfect sense to use the lettered registers here, because they match the hot key labels. Happy coding! Pauli, I'd like to have some more special labels such as "I" so that XEQ I may be used. Edit: Added command to set stack size to 4. This might not be the best idea but somehow, A to D need to be made available for general use. Edit: Corrected SSIZE4. Edited: 30 July 2011, 10:26 a.m. after one or more responses were posted

 Re: 34s: TVM problem?Message #59 Posted by Walter B on 30 July 2011, 4:38 a.m.,in response to message #58 by Marcus von Cube, Germany Marcus, Watch it: it's called SSIZE4 :-) Walter

 Re: 34s: TVM problem?Message #60 Posted by Paul Dale on 30 July 2011, 4:42 a.m.,in response to message #58 by Marcus von Cube, Germany Quote:Pauli, I'd like to have some more special labels such as "I" so that XEQ I may be used. We have the op-code space for some more but I'm not sure how much extra flash it will consume.... - Pauli

 Re: 34s: TVM problem?Message #61 Posted by Marcus von Cube, Germany on 30 July 2011, 12:53 p.m.,in response to message #60 by Paul Dale Quote: We have the op-code space for some more but I'm not sure how much extra flash it will consume.... - Pauli I've started working on it but will not have the time to finish it this WE. Maybe Pauli can take over.

 Re: 34s: TVM problem?Message #62 Posted by Dieter on 30 July 2011, 9:14 a.m.,in response to message #58 by Marcus von Cube, Germany Fine - let me add some remarks: First, "Finance" is much, much more than TVM, so I would suggest something more like a simple "TVM". ;-) Using registers and labels with the same letter is not new, but still a good idea. That's how basically all TVM programs since the days of the 65 worked. ;-) However, all these solutions had one major advantage: there were five (!) hotkeys A to E, which really is quite nice if there are also five variables. ;-) These five softkeys would match the five financial keys of HP's financial calculators. Even the sequence was the same: ``` N I% PV PMT FV ``` Looks like a quite logic and intuitive layout to me. Compare that with the current TVM equation which uses registers 80 - 84 for PMT, PV, FV, I%/100 and N. So, to make your idea work there has to be a fifth hotkey, something like this XEQ I you suggested. Or maybe there even is a solution for a fifth "E" hotkey ?-) Regarding the mathematical part and its coding for the 34s: The solution in the 41C standard pac may give a first idea. It can be found on this website. There are some details in this program that deserve a closer look: Basically the 41C program works just like your idea: The "Entry?" test is handled by flag 22, and even STO A or RCL A can be handled by the HP-41 since pressing "A" to "E" here is a shortcut for the register addresses 01 to 05 used by the program. The question wheter to use an interest rate in percent or its decimal value is answered by simply using both: input and output are percentages (R02) while the program internally uses i/100 (R09) and 1+i/100 (R07). If the interest rate has to be calculated the program first checks whether there is a periodic payment or not (PMT=0?). In the latter case the interest rate can be evaluated directly. Otherwise the usual iterative approach is required. Since the 41C does not feature a solver, a kind of Newton's method is used here. Before that, an initial guess of plus or minus 1E-9 is set, so that the routine will correctly find either a positive or negative interest rate. For the following iteration the choice of the equation to solve is crucial. The two different TVM equations given by Franz and Pauli show the importance of this point. BTW - setting a common endpoint for each routine, in your example at Lbl 00, was good practice in the days of the 67/97 and even 41 (when local Alpha labels were used). But does it really make a difference in a calculator as fast as the 34s? Anyway - I like it as it reminds me of the good old days when the '41 was new. ;-) Dieter Edited: 30 July 2011, 10:04 a.m.

 Re: 34s: TVM problem?Message #63 Posted by Marcus von Cube, Germany on 30 July 2011, 10:35 a.m.,in response to message #62 by Dieter Dieter, if you have more then one application that uses hot keys in the same region it makes a difference where the PC is positioned. So good practice isn't the only explanation. Having "only" 4 hot keys is a problem here where 5 variables need to be accessed. It's hopefully not to hard to overcome this in the firmware. If LBL I will not be implemented by Pauli, still LBL 'I' can be used which is called by XEQ ENTER^ I ENTER^. For setting the interest rate, STO I will then be the quicker manual key stroke sequence.

 Re: 34s: TVM problem?Message #64 Posted by Paul Dale on 30 July 2011, 9:14 p.m.,in response to message #62 by Dieter Quote:First, "Finance" is much, much more than TVM, so I would suggest something more like a simple "TVM". ;-) TVM is certainly the starting point. However, if we're putting aside a whole page of flash for this, a lot more than just TVM will fit. - Pauli

Go back to the main exhibit hall