▼
Posts: 239
Threads: 55
Joined: Sep 2006
Hi,
I wrote this program for my HP 42s. I wanted to adapte it for the HP 35s and here is the routine. You have to assign the routine with FN= and then to solve for the variable you want. As you know, the Hp 35s has no LN(1+x) function included, so I implemented what is defined in the HP15C Advanced Functions Handbook:
if u= (1+x)
ln(u) = x if u = 1
ln(u)*x/(u1) if u <> 1
References:
Hugh Steers'TVM page
HP15C Advanced Functions Hadbook, page 181
Tommi's Accurate TVM for HP 42s
Variables:
B: present value or "base" value
P: payment
n: periods
i: interest rate in %
E: end/begin modes
F: future value
Equation:
B*(1+i)^n + P*((1+i)^n1)*(1/i+E) + F = 0
(1+i)^n = e^(n*ln(1+i)) = i'
> B*i' + P*(i'1)*(1/i+E) + F = 0
Routine:
T001 LBL T
T002 INPUT N
T003 INPUT I
T004 INPUT B
T005 INPUT P
T006 INPUT F
T007 INPUT E
T008 RCL I
T009 100
T010 /
T011 ENTER
T012 ENTER
T013 1
T014 +
T015 LN
T016 x<>y !switch x with y
T017 LASTx
T018 1
T019 X<>Y? !x not equal to y?
T020 
T021 /
T022 *
T023 RCL* N
T024 e^x
T025 RCL* B
T026 LASTx
T027 1
T028 
T029 RCL* P
T030 RCL I
T031 100
T032 /
T033 1/X
T034 RCL+ E
T035 *
T036 +
T037 RCL+ F
T038 RTN
LN=123
CK=7940
I tried the following examples to compare against the 35s manual's equation, my HP 12C (made in USA) and my HP 12cp 25th annyversary:
Example A:
N= 365x24x60x60
I= 10%/N
B= 0
P= 0.01
E=0
F=?
Example B:
N= 32
B= 999,999
P= 0
F= 1,000,000
E= 0
I= ?
Examples
Program A  B
HP 35s with routine 331,667.006689  3.125014111x106
HP 35s with equation 331,559.383308  3.125500000x106
HP 12c 331,667.0067  3.125004736x106
HP 12cp 25th Ann. 331,667.006691  3.125001000x106
All improvements are welcome as well as other examples to test it.
Regards,
Miguel
Edited: 8 Aug 2007, 6:35 a.m. after one or more responses were posted
▼
Posts: 1,545
Threads: 168
Joined: Jul 2005
Great job, Miguel!
Now, right this up and submit it to Datafile as well and you'll be a published author in the magazine too. :)
Posts: 125
Threads: 11
Joined: Jun 2007
Is this listing correct? I've proofed my input of this program three times and it matches the posted listing, but I get CK=D44E and LN=127 and the program errors with an OVERFLOW when I run it.
▼
Posts: 239
Threads: 55
Joined: Sep 2006
You are correct. I did not write the last version, but I put the checksum of it. I corrected the listing and It should work.
Thanks,
Miguel
▼
Posts: 111
Threads: 22
Joined: Jul 2007
Miguel,
I also tried keying it in, and get:
Checksum 45DC
LN = 123
Also, I'm not quite sure if I understand the methodology behind your INPUTs. How can I decide which variable to solve for?
I'll mention that I am not new to programming on HP machines, just forgive me if I've missed a fundamental point.
Also, as of now I also get OVERFLOW when I XEQ it.
Thanks,
ECL
▼
Posts: 239
Threads: 55
Joined: Sep 2006
I keyed the program and it is correct as it is in the post. Please verify lines:
T0016 x<>y this is switch x and y.
T0019 X<>Y? this is compare if x is different than y.
The confusion may come from there.
To solve the program just assign it to FN= and next you solve it. You do not XEQ it!. See the keystrokes:
[LS][FN=]
T
[SOLVE]
The solver will ask for the unknown variable for which you want to solve, and it will ask for values for the rest of the variables.
Regards,
Miguel
Edited: 7 Aug 2007, 1:03 p.m.
Posts: 376
Threads: 35
Joined: Jul 2007
Good Morning Miguel. This is very interesting. One question I have though is was reason you store as FN= so you could choose what variable you wish to solve for? Can you store multiple FN or just one?
Also, there are about 10 (if I remember correctly) TVN formulas for different things (future value of lump sum, present value of annuity, etc), and then based on various criteria (annual compounding, compounded n times per year, and continuous compounding). I think I might and try and tackle those as a starter to learn how to program with 35s. I working on my MBA (is that funny. Stupid Hungarian working on MBA when he can not even speak language very well).
▼
Posts: 239
Threads: 55
Joined: Sep 2006
Hi Vincze,
You have to tell the calculator which program you want to solve. You do that by selecting the program label with the "FN=" key. The solver will continue to use the program selected as long as you do not change to another program (with another FN= assignment for a different label).
Once called, Solver will ask for the unknown variable and it will ask for values for the rest of the variables that have INPUT instructions.
Also, most of the things that you mention can be solved already with this routine, so you just have to enter the data as it is needed by the problem. That is the beauty of this equation.
Example 1: Future value of a lump sum.
If John invests $1,850 today in an asset earning a 10% rate of return (compounded annually), how much will he have after two years?
Keystrokes:
[LS] FN=
T This is just to do once if you are to do several problems with the same program.
[RS] CLEAR 2
[RS] SOLVE
SOLVE
F The unknown
N?
2 [R/S]
I?
10 [R/S]
B?
1850 [R/S]
P?
0 [R/S]
E
0 [R/S]
F=
2238.50
Example 2: Present value of annuity.
How much should you invest now so that, starting one year from today, your daughter can receive $6,000 per year for the next five years? Assume the discount rate is 15%.
Keystrokes:
[RS] CLEAR 2
[RS] SOLVE
SOLVE
B The unknown
N?
5 [R/S]
I?
15 [R/S]
P?
6000 [R/S]
F?
0 [R/S]
E
0 [R/S]
B=
20112.93
And so on...
Regards,
Miguel
Edited: 7 Aug 2007, 12:57 p.m.
▼
Posts: 376
Threads: 35
Joined: Jul 2007
Miguel, thank you my friend for the example. I see now how FN= work now. One question I do have though is what is the formula i' for? In MBA, I aware of P/i*(1(1+i)^n)+F*(1+i)^n+B=0 to solve for TVM, assuming that this loan payment and payment at end of period and not beginning. For beginning (or lease generally) there different formula. Yours account for that nicely, but I do not understand the i' formula. I would think that if not needed, program might be shorter and more efficient. Let me think through and I will post back.
▼
Posts: 376
Threads: 35
Joined: Jul 2007
Okay, I try my hand at first program. I must admit, harder than I thought. Let me state up front though, that this getting wrong answer **EDIT:(the below program has been corrected)**, so I need help of members to see where I go wrong.
First, I use the following formula:
P/I*(1(1+I)^N)+F*(1+I)^N+B
I then collect like terms and get:
(1(1+I)^N)*P/I+(1+I)^N *F+B
Variables are same as above program, but I is in the factor of %/(n payments per year), so if interest be 5% and 12 payments per year, then
.05/12 = .004167 = I
My **CORRECTED** program steps are below: T001 LBL T
T002 INPUT I
T003 INPUT N
T004 INPUT P
T005 INPUT B
T006 INPUT F
T007 1
T008 RCL + I
T009 RCL N
T010 +/
T011 Y^X
T012 1
T013 X<>Y
T014 
T015 RCL *P
T016 RCL /I
T017 1
T018 RCL +I
T019 RCL N
T020 +/
T021 Y^X
T022 RCL * F
T023 RCL + B
T024 +
T025 RTN
I wonder if I have order of operator error someplace. I look, but sometime it better if fresh eyes look at to see my mistake.
If the following variables are entered, the result should be 1588.9920 when solving for P.
I = .004167
N = 360
P = ?
B = 296,000
F = 0
...but with above formula, I get 1233.432.
**EDIT** Corrected formula yields correct value of 1588.9920.
Edited: 7 Aug 2007, 4:51 p.m. after one or more responses were posted
▼
Posts: 239
Threads: 55
Joined: Sep 2006
Try this:
T001 LBL T
T002 INPUT I
T003 INPUT N
T004 INPUT P
T005 INPUT B
T006 INPUT F
T007 1
T008 RCL + I
T009 RCL N
T010 +/
T011 Y^X
T012 1
T013 X<>Y
T014 
T015 RCL *P
T016 RCL /I
T017 1
T018 RCL +I
T019 RCL N
T020 +/
T021 Y^X
T022 RCL *F
T023 +
T024 RCL +B
T025 RTN
And try to solve for the extreme cases from my original post. What do you get? :)
Miguel
▼
Posts: 376
Threads: 35
Joined: Jul 2007
Yes, I see my error on line T015, and was going to post correction, but you beat me to it. I forgot to multiply there.
With your extreme case example, I don't think you would use this formula normally for continuous compounding (first example), and with second example, yes it extreme, but not realistic.
Edited: 7 Aug 2007, 5:40 p.m.
▼
Posts: 239
Threads: 55
Joined: Sep 2006
The point is that with the program I posted you mantain enough precision to be sure of obtaining accurate results, even in extreme cases where you have too small a interest rate that it can loose decimals because of the precision of the calculator. That is why we make the change in the formula using:
(1+i)^n = e^(n*ln(1+i))
ln(1+i) lets us to preserve accuracy, so the hp 35s can come closer to dedicated calculators as the hp 12c and expands its usefulness.
Regards,
Miguel
Edited: 7 Aug 2007, 6:41 p.m.
▼
Posts: 376
Threads: 35
Joined: Jul 2007
My friend Miguel, I mean no disrespect, but I think your program very good, but again unrealistic in real world situation. Yes, if we have continuous compounding with continuous funding, it does do better than mine, but the basic TVM formula has not changed much in the last 100 years. The reason being is that interest rates have not reached minimal numbers like your program simulate. Yes, in theory it is possible, but not realistic. I think your program a very good example of what we call didaktikus in hungarian (I apologize, I do not have hungarian english dictionary with me to find english same word). It mean example, or teaching. Again it possible to have money continuously grow and add .01 cent continuously, but what bank could ever do that? I think for most real world example, it might be a bit more than need and if I be banker I may want shorter program that be faster. Just my opinion.
I hope there no hard feeling. I still interested though in your formula, as I have never seen the I' portion as when I plan continous equations we do it much differently with much shorter formula.
Thank you again my friend though for enlighten me in different way of doing same thing and letting me get feet wet in HP programming.
▼
Posts: 3,229
Threads: 42
Joined: Jul 2006
Quote: I think your program a very good example of what we call didaktikus in hungarian (I apologize, I do not have hungarian english dictionary with me to find english same word).
I imaging that "didaktikus" translates roughly to "didactic" or a derative form.
Not that I understand any Hungarian :)
 Pauli
▼
Posts: 376
Threads: 35
Joined: Jul 2007
Quote:
I imaging that "didaktikus" translates roughly to "didactic" or a derative form.
Paul, I look in my dictionary this morning and it does not have didaktikus in there to translate to english, but when I look up the word "didactic", the definition is very close too what I mean, so they must be related.
I will email someone who has better Hungarian / English dictionary to double check. Thank you for your help. I see I learn new English word today. Yesterday I learn "ameliorate", or to make better.
Posts: 376
Threads: 35
Joined: Jul 2007
Quote:
(1+i)^n = e^(n*ln(1+i))
ln(1+i) lets us to preserve accuracy, so the hp 35s can come closer to dedicated calculators as the hp 12c and expands its usefulness.
I guess I am still hung up on this part of the formula. Can you point me someplace that discuss this further. Obviously, accuracy a big concern, but in my studies, I have not seen this.
▼
Posts: 239
Threads: 55
Joined: Sep 2006
Hi Vincze,
In my original post, you can click on two excellent links that explain the matter further. You can also see the page 181 of the HP 15c "Advanced functions handbook" for this specific subject, or the entire chapter "Accuracy of numerical calculations" for discussions about different types of problems. If you do not have the book, the best alternative is the DVD from the museum, of course. :)
Miguel
▼
Posts: 376
Threads: 35
Joined: Jul 2007
My friend Miguel, I just read the 15C book example. So what it sounds like is that this deals with convexity and duration vector. Very interesting.
It should be noted, that TVM calculation are basically just estimates. Granted, banks want these as accurate as possible, but I think even with convexity and duration vectors, it will still be an estimate, but obviously much better. The TVM calculation is basically a polynomial, as because of that it will have roots (yes, plural. financial calculators only will find the one, but if you solve the formula and use the standard quadratic equation to solve for the unknowns, you will see what I mean). I wonder if there is a way to harness the polynomial in a different way to get an *even* more accurate solution.
Very interesting my friend. Thank you for the enlightenment.
Edited: 8 Aug 2007, 10:08 a.m.
Posts: 9
Threads: 0
Joined: Jan 1970
Quote:
The point is that with the program I posted you mantain enough precision to be sure of obtaining accurate results, even in extreme cases where you have too small a interest rate that it can loose decimals because of the precision of the calculator. That is why we make the change in the formula using:
(1+i)^n = e^(n*ln(1+i))
ln(1+i) lets us to preserve accuracy, so the hp 35s can come closer to dedicated calculators as the hp 12c and expands its usefulness.
I don't know how 35s does internal computations,
but on most past HPdesigned series,
(1+i)^n is calculated more accurately than e^(n*ln(1+i)) because it is using exactly the same formula internally anyway, but is retaining extended precision, which is lost when the intermediate "user" results are rounded to lesser precision.
In particular, on a calculator which always keeps the same number of digits in intermediate results, the moment we add 1 to a very small value of i, only the leading significant digits of the original i remain, and we have already lost any chance to get a completely accurate final result from the remaining steps.
This happens no matter which way we try to calculate the expression above, but it's worse when we take the log and multiply etc. ourselves, because then our intermediate results get rounded to "user" precision at each step, including the log and multiply, whereas when the calc does it, it can do the log, multiply and final EXP using greater internal precision than we can.
To retain precision for very small "i" and large "n" one really needs the special internal LNP1 and EXPM functions, which for small arguments use series expansions that omit the first term. I'm working on a bit longer document about this, at least as it would apply to numerical methods on older series; perhaps 35s uses different internal numerical recipies, and if so, any experiments which shed light on that would be of interest.
▼
Posts: 9
Threads: 0
Joined: Jan 1970
This longwinded excursion explores the merits of different equations
upon which a TVM solver could be based,
if instead of the closedform solutions available for all variables except interest,
we seek a single suitable formula to use with numeric roothunting algorithms,
to solve all cases of the common fivevariable TVM application.
Some principles to consider:
o Reasonable initial guesses should always send the root hunter
in the right direction, to locate a true and meaningful root,
for all "shapes" of problems, initial guesses, and when solving for any variable.
Suggested formulas of general type 'f(n,i%yr,PV,PMT,FV,PYR,Begin?)=0'
often differ from one another by having both sides multiplied
or divided by some expression  the right side, of course,
always remaining zero under these transformations.
Sometimes we see the FV term having no other variables
in its coefficient,
and sometimes the PV term is chosen
to have the honor instead;
each of these has a characteristic
which is particularly good
if the cash flows are "loaded"
towards one end or the other of the time line,
but may turn out disadvantageously in an oppositely "loaded" case.
Solving for N can also produce a surprise, when for some initial guesses,
the shape of the entire function, plotted vs. N, may send the numeric solver
off in the wrong direction, heading away from the real answer,
flying out towards infinity in a vain effort to make the left side zero.
Among the versions of this formula which I have tried,
the best resistance to that effect in all collected problems I could throw at it
was obtained when the coefficient of the "middle" PMT term
(the "cash flow over the central region of the problem")
was made independent of i (at least when payments occur at end of periods),
rather than the very first (PV) or very last (FV) term,
in which case the PV and FV terms each have coefficients involving "i",
remaining in the ratio (1+i)^n to one another,
as they always are anyway, in all forms of the equation.
But in this form of the equation, unlike some other forms,
there is a certain resemblance of these "end region" terms to one another,
and anomalies involving poor initial guesses seem to be reduced,
for cases that have the largest cash flow "at the wrong end"
for whichever "unbalanced" equation was otherwise chosen.
A final tweak which seemed to improve solving for N
was to multiply the entire equation by N,
which tends to discourage the numeric solver from getting attracted
to exploring distant galaxies when solving for N :)
o It's useful to confine the search for an interest rate
to values which are logically possible, which are i > 100%
(there is no limit in the positive direction).
However, the numeric solver isn't conscious of this,
and can at times wander into an alternate financial universe itself,
announcing 157%, say, as a mathematically correct (but meaningless) answer.
If a new variable is introduced, say j=LN(1+i),
and then the equation is expressed in terms of j,
the legitimate range for j is now from
infinity to +infinity,
which neatly and perfectly remaps the range for j
Another rather elegant feature of this remapping is that if you were
to run time backwards,
exactly reversing the sequence of cash flows of an original problem,
the result is still a valid cash flow sequence,
in which j simply changes sign (and payments flip between "begininning"
vs. "end" of their respective periods), making the problem symmetrical.
A very small rounding error may have to be accepted as a tradeoff
for some of these strategies, in return for other forms of robustness
in the ability of the overall algorithm to take on all conceivable cases.
o Cases involving large N and small I present a special challenge to accuracy.
In those cases, directly computing such expressions as '(1+i)^n1'
tends to lose precision,
because significant digits drop off immediately when adding 1 to small i,
and subtracting 1 at the end may also cause another loss of significance
(also keep in mind that 'i' can legitimately have negative values,
producing different extreme ranges for the final result).
Rewriting '(1+i)^n1' as 'EXPM(n*LNP1(i))' and
'1(1+i)^n' as 'EXPM(n*LNP1(i))' avoids that loss of significance,
whenever the given calculator implements these as builtin functions,
which are mutually inverse and pass thru the origin (0,0);
this technique was apparently introduced way back at the time
of the HP22 financial model, although the EXPM and LNP1 functions
were not then made directly available to the user.
Note also that with the abovesuggested change of variable, we have
j=LNP1(i), '(1+i)^n1=EXPM(n*j)', '1(1+i)^n=EXPM(n*j)' and i=EXPM(j),
giving the equation complete symmetry, in the fact that
a reversal of time corresponds to a change in the sign of j,
whose valid range remains infinity to +infinity.
If anyone would like to try out various equations on a "breadboard rig,"
before investing in detailed implementations:
@ Testing equations on HP48/49/50 (ignoring the builtin TVM solver :)
@ TVM Equation in terms of I (valid only I > 100%)
@ favoring linear middle term and balanced end terms:
'(PV*I/EXPM(N*LNP1(I))+PMT*(1+B?*I)+FV*I/EXPM(N*LNP1(I)))*N'
'TVMI' STO
@ More symmetrical version in terms of J (infinity to +infinity)
@ 'EXPM(J)=EXP(J)1' for calcs not having builtin EXPM
'(PV*EXPM(J)/EXPM(N*J)+PMT*(1+B?*EXPM(J))+FV*EXPM(J)/EXPM(N*J))*N'
'TVMJ' STO
@ Sample problem (B?=1 if payments occur at beginning of periods)
{ 136 50 75 3 0 } { PV PMT FV N B? } STO
TVMI 'I' 1 ROOT @ 0.25 is correct answer
TVMJ 'J' 1 ROOT EXPM @ 0.25 is correct answer
1 'B?' STO TVMI 'PMT' DUP RCL ROOT @ 40 (payment at beginning)
@ Simple solver menu (using equation in terms of I):
TVMI { { N I PV PMT FV B? } } + STEQ 30 MENU HALT
@ continue via CONT
@ In terms of Uniform Series Present/Future Value (like HP17b/19b)
'USPV(N,I)=EXPM(N*LNP1(I))/I' DEFINE
'USFV(N,I)=EXPM(N*LNP1(I))/I' DEFINE
@ If 'EXPM(J)=EXP(J)1' 'LNP1(I)=LN(1+I)' aren't builtin, then
@ 'USPV(N,I)=(1(1+I)^N)/I'
@ 'USFV(N,I)=((1+I)^N1)/I'
{ '(PV/USPV(N,I)+PMT*(1+B?*I)+FV/USFV(N,I))*N' @ TVM equation!
{ N I PV PMT FV B? @ This menu includes USPV USFV keys
{ "USPV" \<< N I USPV \>> }
{ "USFV" \<< N I USFV \>> } } } STEQ 30 MENU HALT
@ continue via CONT
@ MES solver menu (to solve symmetrical "J" equation first)
TVMJ { 'I=EXPM(J)' } + STEQ 63 SF @ Rshift changes var state
MINIT "TVM" { N I PV PMT FV B? J } MITM MSOLVR @ menu order
@ Use Rshift with ALL menu key to see how solved.
@ If the "MES" solver is unfamiliar,
@ a manual may be need to be consulted.
Modern HP financial calculators, as you know,
actually have a slightly different set of variables in their TVM menu,
consisting of N, I%YR, PV, PMT, FV, PYR and BEG[in] mode,
where I%YR is the annual interest rate in percent
and PYR is the number of payments per year,
so that what we were calling I is actually '(I%YR/PYR)/100';
I use this same set of values in my HP32Sii and HP42S formulas,
of course having to choose nonmnemonic single letters on 32Sii
to distinguish Payment from Present value, and from PYR :)
I was going to append my HP32Sii formula and HP42S program,
but I can't seem to find where I wrote them down,
so I'll post this now, and perhaps come back later,
if ever I do find where I hid those listings...

Edited: 9 Aug 2007, 5:54 a.m.
Posts: 320
Threads: 59
Joined: Dec 2006
This isn't a program, but this is what I came up with a few weeks ago while camping. It's slightly different than the example from the owners manual; this is the form that I have the compounding interest formula and annuity formula memorized.
Press EQN, then enter the equation...
Q x (1 + R/N)^(N x T) + P x ((1 + R/N)^(N x T)  1) / (R/N) + B
Directly above this equation you could enter the "Equation" TVM as a title to the TVM formula.
Q = present value
P = periodic payment
R = decimal annual interest rate
N = number of compoundings per year
T = time in years
B = balance
This is only for annuities due, (ie, end on period compunding) for simplicity.
Pull up the equation, press solve, the letter, and enter the known values as prompted.
CHUCK
Edited: 7 Aug 2007, 5:14 p.m.
Posts: 93
Threads: 2
Joined: Jul 2005
Miguel, Thank you for the excellent program. Note that Example A needs not 10 but 10/N at the I prompt :)
Best, Tony
▼
Posts: 239
Threads: 55
Joined: Sep 2006
Posts: 2,761
Threads: 100
Joined: Jul 2005
Examples
A  B
HP35s with your routine 331,667.006689  3.125014111x106
HP12C 331,667.0067  3.125004736x106
HP80 312,925.02  3.1 x106
Should I return my HP80 (1247A46954) ? :)
▼
Posts: 239
Threads: 55
Joined: Sep 2006
Hi Gerson,
If you don't want it any more...I accept donations! ;)
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Hello Miguel,
I am not interested in financial calculators, unless they're programmable and miss trigonometric functions. But I will keep this one until one friend of mine confirms he wants to trade it with something else.
An HP35s with your TVM program might be enough for all my modest financial needs :)
Best regards,
Gerson.
Posts: 464
Threads: 10
Joined: Jan 2005
Hello Gerson,
"Should I return my HP80 (1247A46954) ? :)"
Noooooooooooooooooooooo! Please don't do that Gerson :)))
My heart sinks....
Kindest regards from France!!!
Etienne
▼
Posts: 2,761
Threads: 100
Joined: Jul 2005
Quote:
Please don't do that Gerson :)))
I won't, mon ami. Just email me :)
Warm regards from Brazil,
Gerson.
