TVM formula error in programming manual?

[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.