Looking for TVM formulas

[Dave Britten]

I've spent some fruitless time looking for general-purpose TVM formulas for solving the usual 5-variable problems the 12C can do (n, i%, PV, PMT, FV). So far I've only found specific ones that deal with a subset of variables, e.g. PV or FV, but not both. Anybody have a good reference for these? I know i% needs to be solved iteratively, so I'll just use whichever form runs quickest through a numeric solver.

I'd like to have these so I can implement them as needed on scientifics 'just in case', but it looks like most sites take the availability of a good financial calculator for granted, and don't give the full forms of the equation (either that or I'm not enough of a financial analyst to know what to search for, which is to be expected, since I majored in CS).

You never know when you might need to pound out a quick loan amort, right?

[Thomas Klemm]

• Accurate TVM for HP-15C
• Accurate TVM for HP-19C/HP-29C
• Accurate TVM for HP-34C
  

HTH
Thomas

[Dave Britten]

(04-01-2014 12:17 AM)Thomas Klemm Wrote:  

• Accurate TVM for HP-15C
• Accurate TVM for HP-19C/HP-29C
• Accurate TVM for HP-34C
  

HTH
Thomas

Thanks Thomas, that might get me started. I can probably derive a symbolic equation from that program and algebra it into the other direct solutions I'm after (once I've finished with turning 'algebra' into a verb, anyway).

My TI-95 in particular has a soft-key system that's almost as nice as a 48SX, so I'd hate to leave it without a worthy TVM solver! It's a surprisingly cool machine; I highly recommend it to anybody that's not allergic to TI stuff. Or if you are, sell me any old RAM or ROM modules you have laying around.

[Thomas Klemm]

(04-01-2014 12:43 AM)Dave Britten Wrote:  I can probably derive a symbolic equation from that program and algebra it into the other direct solutions I'm after (once I've finished with turning 'algebra' into a verb, anyway).

Just follow the links to find a formula in Miguel Toro's post about a program for the HP 35s. He references Hugh Steers' TVM page. And there's an interesting message #21 Posted by John H Meyers in the same thread.

Cheers
Thomas

[Manolo Sobrino]

(03-31-2014 11:21 PM)Dave Britten Wrote:  I've spent some fruitless time looking for general-purpose TVM formulas for solving the usual 5-variable problems the 12C can do (n, i%, PV, PMT, FV).

Check here.

Regards

[Jeff_Kearns]

  TVM_Equation.doc (Size: 52.5 KB / Downloads: 27) [/quote]
I can probably derive a symbolic equation from that program and algebra it into the other direct solutions I'm after
[/quote]

Here is the equation:

B*(1+i)^n + P*((1+i)^n-1)*(1/i+E) + F = 0

and make the following substitution for increased accuracy:
(1+i)^n = e^(n*ln(1+i)) = i'

where:
n-Number of compounding periods (n on HP-12C)
i=Periodic interest rate (i on HP-12C)
B=Initial Balance or Present Value (PV on HP-12C)
P=Periodic Payment (PMT on HP-12C)
F=Future Value (FV on HP-12C)
E=Begin/End mode (Begin = 1; End = 0)

Use convention that money in or received is positive and money paid out or deposited is negative.

Jeff Kearns

[Dave Britten]

Thanks everyone, that all helps a lot. So basically, if I were to generalize this to a form that assumes effective interest rate, and equal compounding and payment periods (like the 12C), it would look something like this, right? (Extra parentheses included for overly cautious clarification.)

PV * (1 + i)^n + PMT * (((1 + i)^n) - 1)) * ((1 / i) + B) + FV = 0

Where B = 0 for end-period payments, and 1 for begin-period payments.

[Dave Britten]

Looking good so far. I've got direct solutions for PV, PMT, and FV working. Once I integrate the numeric solver (ported directly from the one built in to the HP 20S, roughly 160 steps), the program should weigh in around 600-650 steps. Maybe another hundred or so when I add amorts, though I have to learn how to properly handle beginning/end modes in that context.

The more I mess with this TI-95C, the more I like it. It does a lot of things that even their later graphers don't (indirect branching and addressing, most notably). You can also directly read/write bytes, and branch to assembly routines at any address, so keying in ML programs probably isn't out of the question (but way beyond my current capability with the thing).

[Jeff_Kearns]

(04-01-2014 01:16 PM)Dave Britten Wrote:  it would look something like this, right?

PV * (1 + i)^n + PMT * (((1 + i)^n) - 1)) * ((1 / i) + B) + FV = 0

Where B = 0 for end-period payments, and 1 for begin-period payments.

Only if you are content with inevitable rounding errors. Take a look at p. 180 of the HP-15C Advanced Functions Handbook for an example:

Susan tried to calculate FV=PMT x (((1+1/n)^n)-1)/(i/n), where
payment = $0.01,
i = 0.1125, and
n = 60 X 60 X 24 X 365 = 31,536,000.

She calculated $376,877.67 on her HP-15C, but the bank's total was $333,783.35, and this latter total agrees with the results calculated on good, modern financial calculators like the HP-12C, HP-37E, HP-38E/ 38C, and HP-92. Where did Susan's calculation go awry? No severe cancellation, no vast accumulation of errors; just one rounding error that grew insidiously caused the damage:

i/n = 0.000000003567351598
1 + i/n = 1.000000004

when rounded to 10 significant digits. There is the rounding error that hurts. Subsequently attempting to calculate (1 + i/n)^n, Susan must get instead (1.000000004)^31,536,000 = 1.134445516, which is wrong in its second decimal place.
How can the correct value be calculated? Only by not throwing away so many digits of i/n. Observe that (1 + i/n)^n = e^(n x ln(1 + i/n), so we might try to calculate the logarithm in some way that does not discard those precious digits.

[Dave Britten]

(04-01-2014 07:37 PM)Jeff_Kearns Wrote:  Only if you are content with inevitable rounding errors. Take a look at p. 180 of the HP-15C Advanced Functions Handbook for an example:

Susan tried to calculate FV=PMT x (((1+1/n)^n)-1)/(i/n)
where
payment = $0.01,
i = 0.1125, and
n = 60 X 60 X 24 X 365 = 31,536,000.
She calculated $376,877.67 on her HP-15C, but the bank's total was $333,783.35, and this latter total agrees with the results calculated on good, modern financial calculators like the HP-12C, HP-37E, HP-38E/ 38C, and HP-92. Where did Susan's calculation go awry?
No severe cancellation, no vast accumulation of errors; just one rounding error that grew insidiously caused the damage:
i/n = 0.000000003567351598
1 + i/n = 1.000000004
when rounded to 10 significant digits. There is the rounding error that hurts. Subsequently attempting to calculate (1 + i/n)n, Susan must get instead (1.000000004)31,536,000 = 1.134445516, which is wrong in its second decimal place.
How can the correct value be calculated? Only by not throwing away so many digits of i/n. Observe that (1 + i/n)n = e^(n x ln(1 + i/n),
so we might try to calculate the logarithm in some way that does not discard those precious digits.

Oh yes, I neglected to mention I was using the substitution you recommended for (1 + i)^n. I'll have to take a stab at implementing ln(1+x) as well, I suspect.

EDIT: Sweet, that was pretty easy. I'm now getting FV = -333,783.3499506 when I calculate the Susan problem. My 48SX Equation Library card returns -333,783.349948. I'm fine with that incredibly small error (I suspect the 48 is using extended reals in SysRPL for greater accuracy).

[Dieter]

(04-01-2014 08:01 PM)Dave Britten Wrote:  EDIT: Sweet, that was pretty easy. I'm now getting FV = -333,783.3499506 when I calculate the Susan problem. My 48SX Equation Library card returns -333,783.349948. I'm fine with that incredibly small error (I suspect the 48 is using extended reals in SysRPL for greater accuracy).

I assume there is another reason. Like various other HPs, the 48/49/50 series has a dedicated ln1+x command which is incredibly helpful here. And these machines also feature a special e^x-1 command that will help here as well - just take a look at the formula:

Code:

    FV  =  PMT * (( (1+i/n)^n)-1) / (i/n)
    use ln1+x here   ^^^^^
    and e^x-1 there        ^^^^^
=>
    FV  =  PMT * n / i * e^x-1[n * ln1+x(i/n)]

It's these two matching commands that make the calculation exact.

Evaluating ln(1+x) is pretty easy, a simple way is shown in the mentioned Advanced Functions Handbook. However I do not know of a straightforward method of determining e^x-1. Any suggestions?

Determining the interest rate i requires a numerical solver. Finding a valid solution as well as doing so quickly deserves a closer look at the initial guesses for i. Here you might want to read an earlier thread where this topic has been discussed in detail. You can find it here, especially message #14 ff. You should also take a look at "fhub"'s TVM solver for the 34s and other platforms which has been discussed in the old forum as well.

Dieter

[Dave Britten]

(04-02-2014 12:21 PM)Dieter Wrote:  It's these two matching commands that make the calculation exact.

Evaluating ln(1+x) is pretty easy, a simple way is shown in the mentioned Advanced Functions Handbook. However I do not know of a straightforward method of determining e^x-1. Any suggestions?

I don't see anything obvious. I tried ((e^x - 1) * x) / (x + 1 - 1) just for the heck of it, but the result doesn't appear correct. But getting 10 accurate digits in a contrived example designed to elicit rounding error is probably good enough. I would think the potential error would be immaterial for most realistic scenarios.

[Manolo Sobrino]

I'd try continued fractions (check Abramowitz: (4.2.40)). I like this one:

e^z - 1= z/(1 - z/(2 + z/(3 - z/(2 + z/(5 - z/(2 + z/(7 - z/(2 +...


It works nicely:

http://www.wolframalpha.com/share/clip?f...adhpbqopam

(edit n: for the general results better paste this:
z/(1 - z/(2 + z/(3 - z/(2 + z/(5 - z/(2 + z/(7 - z/(2 ))))))))-(e^z-1)
in Wolfram Alpha, the link might work, but WA/the forum seems to mess with parentheses, system/keyboard language settings and url addresses, that or I'm thick today)

(edit n+k: apparently the caret ^ isn't a proper html character and should be avoided when quoting urls, so it's better to use exp(), or ** instead)

A TI 86 is fine to evaluate this easily, because you don't have to close parentheses with it. At that order I get at least 11 digits right for |z|<1. It shouldn't be hard to code.

[Thomas Klemm]

(04-02-2014 12:21 PM)Dieter Wrote:  However I do not know of a straightforward method of determining e^x-1. Any suggestions?

(04-02-2014 02:15 PM)Dave Britten Wrote:  I don't see anything obvious. I tried ((e^x - 1) * x) / (x + 1 - 1) just for the heck of it, but the result doesn't appear correct. But getting 10 accurate digits in a contrived example designed to elicit rounding error is probably good enough. I would think the potential error would be immaterial for most realistic scenarios.

You could use \(e^x-1=2 \cdot sinh(\frac{x}{2}) \cdot e^{\frac{x}{2}}\) instead.

Code:

001 - 42,21,11  LBL A      
002 -        2  2          
003 -       10  /          
004 - 42,22,23  SINH       
005 -    43 36  LSTx       
006 -       12  e^x        
007 -       20  x          
008 -        2  2          
009 -       20  x          
010 -    43 32  RTN

Cheers
Thomas

[Dieter]

(04-02-2014 05:18 PM)Thomas Klemm Wrote:  You could use \(e^x-1=2 \cdot sinh(\frac{x}{2}) \cdot e^{\frac{x}{2}}\) instead.

Great - that's a nice solution for the 35s and others with hyperbolic functions.

Dieter

[Dieter]

(04-02-2014 04:55 PM)Manolo Sobrino Wrote:  I'd try continued fractions (check Abramowitz: (4.2.40)). I like this one:
e^z - 1= z/(1 - z/(2 + z/(3 - z/(2 + z/(5 - z/(2 + z/(7 - z/(2 +...
...
At that order I get at least 11 digits right for |z|<1. It shouldn't be hard to code.

ln 0,9 < z < ln 2 is all that's required. ;-)
With terms up to n = 9 the result has 11 valid digits.

Dieter

[Manolo Sobrino]

(04-02-2014 07:40 PM)Dieter Wrote:  

(04-02-2014 04:55 PM)Manolo Sobrino Wrote:  I'd try continued fractions (check Abramowitz: (4.2.40)). I like this one:
e^z - 1= z/(1 - z/(2 + z/(3 - z/(2 + z/(5 - z/(2 + z/(7 - z/(2 +...
...
At that order I get at least 11 digits right for |z|<1. It shouldn't be hard to code.

ln 0,9 < z < ln 2 is all that's required. ;-)
With terms up to n = 9 the result has 11 valid digits.

Dieter

You're right, lower bound is wrong for 11 digits. Yet I get 11 up to -0.38. Where did you get the analytical expression for the bounds? (yeah, I'm asking for "here be dragons" stuff )

[Dieter]

(04-03-2014 01:10 AM)Manolo Sobrino Wrote:  

(04-02-2014 07:40 PM)Dieter Wrote:  ln 0,9 < z < ln 2 is all that's required. ;-)
With terms up to n = 9 the result has 11 valid digits.

You're right, lower bound is wrong for 11 digits. Yet I get 11 up to -0.38. Where did you get the analytical expression for the bounds? (yeah, I'm asking for "here be dragons" stuff )

Simple: the basic idea of a dedicated e^x—1 function is better accuracy than a simple e^x minus one.

For x > 0 this is true if the result is less than one. And e^x—1 < 1 means that x is less than ln 2.

For x < 0, e^x—1 is something between –1 and 0. Results within [–1; –0,1] have full accuracy even without a dedicated e^x—1 function. Which is required only for results > –0,1. Which means that x > ln 0,9.

So we only have to consider the interval from ln 0,9 to ln 2. Using the contiued fraction method up to n=9 this yields a largest error (at ln 2) of 3,6 units in the 12th place, i.e. 11 valid digits.

In all other cases a simple e^x minus one will return exact results, so the approximation is not required.

For more details, visit Casio's Keisan calculator, set the accuracy to 22 digits and copy the following code into the "Expression" window:

Code:

approx = z/(1 - z/(2 + z/(3 - z/(2 + z/(5 - z/(2 + z/(7 - z/(2 + z/(9 - z/2)))))))));
exact = e^z-1;
err = approx - exact;
shift = 10^(-(1+int(log(abs(approx)))));
print(exact, approx, err*shift);

Press "Execute", and then enter -1, 0.02, 101 at the now appearing "Variable" input line below. You will get a table for z = –1 to +1 with the true value, the approximation and the error, expressed in units of the nth significant digit (i.e. 3,5E-14 means the approximation is off by 3,5 units in the 14th digit).

Dieter

[Manolo Sobrino]

Dieter,

I see, it seems that you are considering a "what do you really need?" approach as you already have an exp function after all.

Yet the fun part about continued fractions is that, for instance for these exponentials, full expansions (there are several) are true for |z|< Inf, one just might converge faster than others. You could use a truncated continued fraction to perform calculations for every value, but the analytical determination of errors gets pretty technical. My mistake was in being too sloppy about the estimation of the bound.

I tried the keisan Casio site and your code. Looks very nice. Actually the results work better than the calculator that I was using to test it can get. I get 11 digits for (-0.38, 0.38) approx with a 14 digit precision calc. I'll fire up Mathematica when I have a moment.

Thank you!

(Thomas suggestion is neat, just the definition of sinh gets you there for the whole range! I like it a lot. You only need a hard-coded sinh )

[Dave Britten]

Awesome, I used Thomas' suggestion for calculating (1 + i%) ^ n - 1 using the more accurate e^x-1 formula, 2 * sinh(x / 2) * e ^ (x / 2), and now for the Susan example, my TI-95 program is giving me FV = -333,783.3499486. That's dead on, and one more digit than the 48SX Equation Library card gives me!

I've got a couple more things to do before the program is finished:

1. Add a numeric solver routine (tentatively going with the tiny one from the HP 20S ROM, converted for AOS)
2. Find a good way to estimate an initial guess when solving for i% or n (Or is there a direct solution for n?)
3. Add an amort function

Program size is currently 478 steps, and I figure there will be another 150-200 when all that is implemented.