TVM formula error in programming manual?

[dm319]

I've gone on a little bender trying to create the best TVM program I can on my DM42 (which normally runs in NSTK mode). While the set-up with a program that =0 and using the solver works fine and appears correct, I wanted something that functioned more like the HP-12c, especially with regards to not polluting the stack, so I took the program from the HP-42s programming manual, and modified it to work with NSTK, and also operate a bit more like the plus42 TVM solver.

I basically ended up almost completely rewriting it (with a side quest of relearning some algebra to solve the equation for N - the program only solves for 'i', the rest returns an algebraic 'solve'). I was getting completely stuck at the last hurdle which was the equation for overall formula to be used to solve for 'i', when I noticed that maybe the formula from the programming manual might have been wrong.

If you look at page 92 in the HP-42s programming manual, it has the 'PV' term as '-PV'. This is different to the HP-42s owners manual where on page 193 it has the code for the TVM formula, and it ends with RCL+ "PV". It also seems to be at odds with the re-arranged formula for PV on page 93 of the programming manual.

Has this been noticed before? Am I right, or is my algebra wrong? I suspect the latter, but I just can't see how these formulas can agree.

[Thomas Klemm]

(10-30-2023 09:36 AM)dm319 Wrote:  Am I right, or is my algebra wrong?

I think you are right.

Additionally, there appears to be a typo in the comment of the program "TVM" in the HP-42S Owner's Manual on page 193 related to the following code:

Code:

15 FC? 00
16 CLX
17 +

Comment:

Quote:If flag 00 is clear (End mode), calculates (i + 0).
If flag 00 is set (Begin mode), calculates (i + 1).

Should be:

Quote:If flag 00 is clear (End mode), calculates (1 + 0).
If flag 00 is set (Begin mode), calculates (1 + i).

[dm319]

Ah yes, good spot on that. The code seems ok though. I have several sides of A4 where I've tried several times to rearrange the TVM equation for N. I finally got it apparently right, where it was returning the same result as TVM solve and the HP-12c. If it is working correctly, it is now making me think I rearranged it wrong, and two wrongs are making a right!

[Thomas Klemm]

As far as I understand the program "TMV2" the subroutine at LBL 10 is only used to calculate \(i\) and \(\mathit{MODE} = 1 + p \, i\).
With this the following formula is used to solve for \(N\) in the subroutine at LBL 01:

\(
\begin{align}
(1 + i)^N = \frac{\frac{\mathit{PMT}}{i} - \frac{\mathit{FV}}{1 + p \, i}}{\frac{\mathit{PMT}}{i} + \frac{\mathit{PV}}{1 + p \, i}}
\end{align}
\)

From here it's easy to solve for \(N\) using LN1+x and LN.

---

If you wonder how to come up with this equation, substitute:

\(
\begin{align}
a &= \mathit{PV} \\
\\
b &= \frac{(1 + p \, i)\,\mathit{PMT}}{i} \\
\\
c &= \mathit{FV} \\
\\
x &= (1 + i)^{-N} \\
\end{align}
\)

And then solve the following equation for \(x\):

\(
\begin{align}
0 = a + b \, (1 - x) + c \, x
\end{align}
\)

The solution is:

\(
\begin{align}
x = \frac{b + a}{b - c}
\end{align}
\)

[Albert Chan]

(10-30-2023 09:36 AM)dm319 Wrote:  If you look at page 92 in the HP-42s programming manual, it has the 'PV' term as '-PV'.

Yes, it is a typo.
Beware, some calculators (e.g. TI BA-35 Solar) do use this loan convention.

If compounding effect is high, solve NPV=0 for i is not ideal.
Same for NFV=0, since TVM is time symmetrical, NPV(n,i,pv,pmt,fv) == NFV(-n,i,fv,-pmt,pv)

It is better to pick a middle ground, a straighter curve.

Let C = i*n/(1-(1+i)^-n)      → Let NPMT = C*NPV

(07-11-2022 09:08 PM)Albert Chan Wrote:  NPMT = C*pv + C(n=-n)*fv + n*pmt

If time flow backward, we get back same NPMT

C(n=-n)*fv + C*pv + (-n)*(-pmt) = NPMT

(07-11-2022 09:08 PM)Albert Chan Wrote:  NPMT tends to be more "straight" than (NPV, NFV), with values inside (NPV, NFV)
Thus, f = NPMT/n = 0 is great for solving rate x, using Newton's method.

Newton's method for f=0 is the algorithm used in Plus42 TVM, to solve for i.
see TVM solve for interest rate, revisited

[Albert Chan]

(10-30-2023 04:39 PM)Thomas Klemm Wrote:  As far as I understand the program "TMV2" the subroutine at LBL 10 is only used to calculate \(i\) and \(\mathit{MODE} = 1 + p \, i\).
With this the following formula is used to solve for \(N\) in the subroutine at LBL 01:

\(
\begin{align}
(1 + i)^N = \frac{\frac{\mathit{PMT}}{i} - \frac{\mathit{FV}}{1 + p \, i}}{\frac{\mathit{PMT}}{i} + \frac{\mathit{PV}}{1 + p \, i}}
\end{align}
\)

From here it's easy to solve for \(N\) using LN1+x and LN.

Let P = PV + p*PMT
Let F = FV − p*pMT

We shift (PV, FV) in BEGIN mode (p=1), so that we always work in END mode (p=0)

\( \displaystyle
(1 + i)^N - 1 =
\frac{\frac{\mathit{PMT}}{i} - F}{\frac{\mathit{PMT}}{i} + P} - 1
= i\;\left(-\frac{P+F}{\mathit{PMT} + P\;i}\right)
= i\;N_0
\)

If i → 0, (1+i)^N - 1 = expm1(N * log1p(i)) ≈ N * i      → N = N₀

Otherwise, we apply log1p to both side, solve for N       → N = log1p(i*N₀) / log1p(i)

[rprosperi]

The sign convention for HP financial machines, for the associated cashflow diagrams to look 'right', is the Present value has the opposite sign of the Future Value (since one is paying, the other receiving) so the "-PV" may be negating the negative value you're supposed to use, if the underlying equations are assuming both positive. Not a math issue, just a sign convention issue.

[Thomas Klemm]

(10-30-2023 08:18 PM)rprosperi Wrote:  Not a math issue, just a sign convention issue.

The formula is correct in the Owner's Manual on page 192:

\(
\begin{align}
0=PV+(1+ip)PMT\left[\frac{1-(1+i)^{-N}}{i}\right ]+FV(1+i)^{-N}
\end{align}
\)

The formula is wrong in the Programming Examples and Techniques on page 92:

\(
\begin{align}
0=-PV+(1+ip)PMT\left[\frac{1-(1+i)^{-N}}{i}\right ]+FV(1+i)^{-N}
\end{align}
\)

The formula is correct in the Programming Examples and Techniques on page 93:

\(
\begin{align}
PV=-(1+ip)PMT\left[\frac{1-(1+i)^{-N}}{i}\right ]-FV(1+i)^{-N}
\end{align}
\)

---

From page 192 of the Owner's Manual:

Quote:The correct sign (positive or negative) for TVM numbers is essential. The calculations will make
sense only if you consistently show payments out as negative and payments in (receipts) as positive.
Perform a calculation from the point of view of either the lender (investor) or the borrower, but not both!

[rprosperi]

Thanks. Still, odd that such a casual error would have crept in here...

Sadly, I left out a much-needed question mark on my final comment, intended to be: "Not a math issue, just a sign convention issue?"

[Thomas Klemm]

(10-30-2023 08:50 PM)rprosperi Wrote:  Still, odd that such a casual error would have crept in here...

It happens to the best.

[dm319]

Thanks all, really enlightening. Thomas, thank you for the break down rearranging that equation! I did something similar but it was so messy comparatively. Yes, the LBL10 subroutine calculates those things, and leaves a couple things on the stack (like PMT cofactor) for the other subroutines to use. To be honest the code is quite a mess. There's quite a nasty fudge where a safe number is put into N to prevent an error for an uneeded calculated variable, just before calculating N. I don't know why that upsets me so much.

Albert, your links are a whole new level of rabbit hole! I sadly don't understand much of it. What is N-prefix on those variables for?

So far my calculations seem to work fine. My biggest issue is with the UI and trying to simulate the solver. I'm using a regular program menu, but wondering if I should switch to the varmenu, which gives me the advantages of being able to 'peek' at the variables, as well as a persistent menu. It also seems to work more reliably than hardcoding menu/solver behaviour. But I can't change modes easily with a varmenu.

On a more meta-level, is there a proper code editor for this kind of RPN? Does vim support it with syntax highlighting for example? What do people do? I got such a headache from scrolling up and down looking for LBL 'X' on my DM42, and trying to type in stuff using the soft key menu or alpha layer was quite a headache.

[Thomas Klemm]

(11-03-2023 10:03 AM)dm319 Wrote:  On a more meta-level, is there a proper code editor for this kind of RPN?

There is the HP42S-free42 extension for Visual Studio Code.

[bxparks]

(11-03-2023 10:03 AM)dm319 Wrote:  Albert, your links are a whole new level of rabbit hole! I sadly don't understand much of it. What is N-prefix on those variables for?

As promised in another thread (RPN83P: RPN calculator for TI-83+ TI-84+ inspired by HP-42S), I have collected and documented the equations and algorithms used to implement my TVM functions of my RPN83P app here:
https://github.com/bxparks/rpn83p/blob/d...ocs/TVM.md
(I would prefer keeping the TVM-related discussions in this thread, and the more general discussions about the RPN83P in the other thread, but that's just a suggestion.)

I want to thank Albert Chan particularly. It's like drinking out of a fire hydrant, and I have not digested everything he has posted, but the information he has shared was invaluable in my implementation. Some of the highlights from my TVM.md document above:

1) I had to implement my own code for log1p(x)=log(1+x), and expm1(x)=e^x-1, to avoid roundoff errors as x -> 0. The versions that I used are:

Code:


expm1(x) = e^x-1 = 2 sinh(x/2) e^(x/2), for all x
log1p(x) = log(1+x) = asinh((x/2) (1+1/(1+x))), for (1+x)>0

The TI calculators already provide the hyperbolic trigonometric functions in the OS, so it's easy to reuse them. (For completeness Albert Chan provides alternative versions that he likes.)

2) I started with the NFV equation, because I preferred working with positive N, instead of -N. But the NPV version is mathematically identical. Albert Chan points out that the equations and various terms are time symmetric, but the more precisely I looked into it, the more confused I got. The (1+ip) term is needed to represent the extra compounding factor of BEGIN payments compared to END, but that term isn't quite time symmetric, with the p needing to be replaced with (1-p) in various places. And the physical interpretation of a -N term did not make sense to me. So I kept the (1+ip) factor explicitly in my equations below.

From the NFV equation, the 4 closed form solutions are:

Code:


PV = [-FV - (1+ip) PMT CF2(i)] / CF1(i)
PMT = [-PV CF1(i) - FV] / [(1+ip) CF2(i)]
FV = -(1+ip) PMT CF2(i) - PV CF1(i)
N = log(1+i*N0) / log(1+i)
where:
    CF1(i) = (1+i)^N
    CF2(i) = [(1+i)^N-1]/i
    N0 = -(FV+PV)/[(1+ip) PMT + PV i]

3) I re-derived his NPMT(i) equation myself, because I don't actually understand something until I redo the work. Some of the terms and coefficients in my version are slightly different, but the essence is the same. My version looks like:

Code:


NPMT(i) = PV / CFN(i,-N) + (1+ip)N*PMT + FV / CFN(i,N)
where
    CFN(i,N) = CF2(i)/N = [(1+i)^N-1]/Ni

The NPMT(i) formula from Albert Chan is quite brilliant, and largely mitigates the numerical overflow (and underflow) problem of NPV(i) or NFV(i). As noted in my document, the physical interpretation of NPMT(i) is very interesting: "It is the "Net Payment" that has to be made to satisfy the equation, using a nominal currency value that is not adjusted for inflation or deflation." From the math, one can show that each of the 3 terms in the NPMT(i) equation grows no faster than linearly with i (as i -> infinity), or *decreases* to zero with a denominator of i^(N-1) (as i -> infinity). This is contrast to NPV(i) or NFV(i) where one of the terms grows as i^N as i -> infinity.

This makes NPMT(i) highly amenable to numerical root solving.

4) A number of terms and equations (e.g. CF2(i), CFN(i), the equivalents to Albert Chan's C(i,n) term, ,and N(i,PV,PMT,FV)) have removable singularities at i=0. So the code must check for i==0 precisely, and replace those terms with the appropriate values that makes those equations continuous and differentiable at i==0. Otherwise, the code will throw a "Division by Zero" exception.

For example:

Code:


          expm1(N log1p(i)/i, for i!=0
        /
CF2(i) =
        \
          N, for i=0

and

Code:


       log(1+i*N0)/log(1+i), for i!=0,
      /
N(i) =
      \
       -(FV+PV)/PMT, for i=0,

(Sorry for the ASCII art, but I don't remember how to write LaTeX equations anymore, and I don't want to go shave yaks and spend hours relearning it, just to make this post.)

5) I used the Secant method in my RPN83P. Partly because it is "good enough" for now, it was easy to implement. It does not need the close-form derivative of NPMT(i), like the Newton's method, so I did not have to implement such a complex equation using Z80 assembly language (which is quite painful to code and test). The Secant method has a lower rate of convergence, but algorithms with lower rate of convergence often come with the benefit of more robust numerical stability. I currently don't understand the higher order methods (e.g. Halley's), and I don't trust Newton's method to converge for the NPMT(i) equation.

6) The Descartes' rule of signs referenced by Albert Chan in plus42desktop TVM rate guess is exactly what we need to determine whether or not the NPMT(i) equation has no solutions, 1 solution, or (0 or 2) solutions. Again, brilliant. The algorithm that I used to determine if there was "no sign change at all" is given in my TVM.md document.

Anyway, I know my current TVM implementation for the RPN83P app is not optimal. But currently it is "good enough", which allows me to work on and polish all the other features of the app.

[Albert Chan]

(11-27-2023 08:13 PM)bxparks Wrote:  2) I started with the NFV equation, because I preferred working with positive N, instead of -N. But the NPV version is mathematically identical. Albert Chan points out that the equations and various terms are time symmetric, but the more precisely I looked into it, the more confused I got.

Think of this as watching a movie.
Beginning of movie, male lead buy a house, pay mortgage every month, and finally get paid off.

Run the tape backward, he lived in a house that is fully paid for.
He get paid every month, until beginning of the movie, when the house get taken away.

Math is the same, but with sign flipped, future and present swapped.
Machine doesn't care sign of N. This is how I define NPV

Code:

-- NFV = pv*K + pmt*(K-1)/i + fv            , where K = (1+i)^n
function NFV(n,i,pv,pmt,fv) return (pv+fv) + (pv+pmt/i)*expm1(log1p(i)*n) end
function NPV(n,i,pv,pmt,fv) return NFV(-n,i,fv,-pmt,pv) end -- time symmetry

Quote:The (1+ip) term is needed to represent the extra compounding factor of BEGIN payments compared to END,
but that term isn't quite time symmetric.

Of course it is time-symmetric! It is the same tape, whether you play it forward or backward!

Example, let try Plus42 TVM, which uses my implementation for rate search.
XEQ "TVM", setup P/YR=12, BEGIN mode

N=360
I=5
PV=1e5
FV=0      → PMT = -534.59

We can run clock backwards.
Plus42 really is using negative N for calculations (no cheating!)

N=-360
FV=1e5
PV=0      → PMT = 534.59

Code:

NPMT(i) = PV / CFN(i,-N) + (1+ip)N*PMT + FV / CFN(i,N)
where
    CFN(i,N) = CF2(i)/N = [(1+i)^N-1]/Ni

Another way to look at this, we can remove (1+i*p) factor.
All is need is to consider first BEGIN payment as part of PV, then BEGIN mode turned to END.

Just to show this is equivalent, here is the proof, using your NPMT formula

XCas> CFN(I,N) := ((1+I)^N-1) / (N*I)
XCas> NPMT1 := PV/CFN(I,-N) + (1+I*p)*N*PMT + FV/CFN(I,N)
XCas> NPMT2 := (PV+p*PMT)/CFN(I,-N) + N*PMT + (FV-p*PMT)/CFN(I,N)
XCas> simplify(NPMT1 - NPMT2)

0

If we are solving I, NPMT2=0 is simpler, because (PV+p*PMT), (FV-p*PMT) are constants.

Quote:As noted in my document, the physical interpretation of NPMT(i) is very interesting: "It is the "Net Payment" that has to be made to satisfy the equation, using a nominal currency value that is not adjusted for inflation or deflation."

That's the idea! Compounding interest into 0% interest problem.
Here, PV' and FV' have compounding effect removed.

NPMT = 0 = PV' + N*PMT + FV'

Quote:I don't trust Newton's method to converge for the NPMT(i) equation.

NPMT=0 to solve for I, Newton's method is proven robust, implemented in Plus42.
With the right rate guess, iteration is guaranteed an improvement over previously, thus can detect no solution case.

https://github.com/thomasokken/plus42des...9.cc#L1242

[dm319]

I love this. But really puts my TVM contribution into perspective! I want to rewrite it with all these optimisations now. I wonder if we could have a series of 'TVM tests' (i.e. calculate I%YR given PV=10'000, PMT = -2000 etc etc). Like different classes of how difficult it is to calculate accurately and then we can see how our programs are fairing.