This is Argyn's blog. I comment on topics of my interests such as software, math, finance, and music. Also, I write about local events in Northern Virginia, USA and all things related to Kazakhstan

Monday, July 24, 2006

On Recurrent computation of NPV (net present value) of a cashflow

I wrote about finding IRR of a cashflow. This time I'm going to write about two ways of recurrent NPV computation, one of which is numerically unstable.

IRR is closely related to a formula for NPV, i.e. net present value, of a cashflow, therefore, I'm going to use the same notation as in my previous post.

See also Wikipedia article about NPV. As you could noticed, they use very similar notation and formula for NPV. The only difference is that their initial investment is on month ZERO, and mine is month ONE. So, their summation formula starts with ZERO, not ONE (like mine).

Suppose we have a set of cashflow amounts: C1, C2, C3,...,Cm,...,Cn. NPV os this set is C1/(1+irr) + C2/(1+irr)^2 +... + Cn/(1+irr)^n. Now, let's define NPVk as the subset of cashflows from month k to the final month, i.e. from Ck to Cn. The NPVk is a sum: Ck/(1+irr) +... + Cn/(1+irr)^(n-k+1). It's easy to see (if you know calculus), that
NPVk-1 = (NPVk + Ck-1)/(1+irr)

This is our first recurrent formula for NPV computation. I call it "backwards" computation formula, because it allows us to compute NPV of any month if we know cashflow amount of that month and NPV of next month. So, we start from NPVn+1 = 0, then compute NPVn = (0+Cn)/(1+irr)= Cn/(1+irr) and so on, all the way to month 1 until we get the NPV of the entire cashflow.

Alternatively, we can compute NPV recurrently in "forward" direction, i.e. knowing that NPV0 = 0, we can compute NPV1 and so on. By definition, at rate equal to IRR (internal rate of return), NPV of entire cashflow (including initial investment) should be zero. The formula for forward computation is:
NPVk = (1+irr)*NPVk-1 - Ck-1

Why do we have to compute NPV recurrently? Why not simply use a standard formula? Ok, there could be several reason. I'll mention only one. Apparently, at least some amortization schedule calculation algorithms are based on NPV concept. In order to compute amortization schedule for month k, you'd have to know NPV of month k. Therefore, you'd have to compute NPVk for every k from 1 to n. In order to speed up the computations, it makes a sense to use NPV computed for another month. Especially, if you have to compute hundreds of thousands such schedules.

Even if the particular amortization method is not directly based on NPV computation, it may employ a very similar recurrent computation algorithm. Now, we are coming to the point where I'm going to say that "forward" formula is numerically unstable, while the "backward" formula is robust. I analyzed the accumulation of abosulte error in both schemes and came to a conclusion that in "forward" scheme, the absolute error of NPVk value grows exponentially when absolute value of 1+irr is greater than 1. The actual formula for absolute error is

Here, A and B are absolute errors of IRR and C1 values; k is a month; irr is internal rate of return. Absolute error of C1, i.e. initial investment, could be as small as machine precision, say, 1e-15 for double precision value. Absolute error of IRR is usually worse than machine precision. When (1+irr) is greater than 1 in absolute numbers, then the absolute error essentially "explodes". For example, for irr equal to 15%, in 200 periods the absolute error will increase by factor of 1e12!

On the other hand, I don't see this exponential behaviour in "backwards" algorithm, which seems to be robust. Why does this happen? It's a long story, but if you are interested to know more about floating-point arithmetic and its accuracy, you may look at Donald Knuth's The art of computer programming book, particluarly, the volume 2 chapter 4.

Interestingly, I see that not many programmers in USA read this Knuth's masterpiece. It was a very popular book among programmers in Soviet Union, as far as I know. I learnt about it in the university from our teacher, who lead physics laboratory practicum. He insisted that we use computers to process the results of our lab work. Obviously, I didn't mind, because I used any chance to do some programming. However, at that time it was sort of unusual, and I've heard that some students and and "old" professors would complain for such computer usage requirements. I don't know what they were thinking about.

1 comment:

Ron Fredericks said...

I like your discussion on NPV and project decision making. I found your post after writing a blog post on a very similar topic. I thought your readers would be interested.

ROI as an Effective Communications Tool for Engineers

Engineers want to build compelling products that meet their project requirements. Corporate executives want to invest in innovative people that build products that, in turn, meet their market’s window; while, both want to stay within budget. Yet both groups may feel overwhelmed with the prospect of expressing the very heart of their inspiration at some critical times during the life of these projects. In today’s post, I try to address this issue from the engineer’s perspective reaching out to the financial decision makers that ultimately control the purse strings of every project.

ROI as an Effective Communications Tool for Engineers