[Numpy-discussion] Definitions of pv, fv, nper, pmt, and rate

[Skipper Seabold]

On Tue, Jun 9, 2009 at 1:14 AM, <josef.pktd at gmail.com> wrote:
> On Tue, Jun 9, 2009 at 12:51 AM, <d_l_goldsmith at yahoo.com> wrote:
>>
>> --- On Mon, 6/8/09, Skipper Seabold <jsseabold at gmail.com> wrote:
>>
>>> I forgot the last payment (which doesn't earn any
>>> interest), so one more 100.
>>
>> So in fact they're not in agreement?
>>
>>> pretty soon.  I don't have a more permanent reference
>>> for fv offhand,
>>> but it should be in any corporate finance text etc.
>>> Most of these
>>> type of "formulas" use basic results of geometric series to
>>> simplify.
>>
>> Let me be more specific about the difference between what we have and what I'm finding in print.  Essentially, it boils down to this: in every source I've found, two "different" present/future values are discussed, that for a single amount, and that for a constant (i.e., not even the first "payment" is allowed to be different) periodic payment.  I have not been able to find a single printed reference that gives a formula for (or even discusses, for that matter) the combination of these two, which is clearly what we have implemented (and which is, just as clearly, actually seen in practice).
>>

These are the two most basic building blocks of time value problems,
discounting one cash flow and an annuity.  There are *plenty* of
examples and use cases for uneven cash flows or for providing a given
pv or fv.  Without even getting into actual financial contracts,
suppose I have an investment account that already has $10,000 and I
plan to add $500 every month and earn 4%.  Then we would need
something like fv to tell me how much this will be worth after 180
months.  I don't necessarily need a reference to tell me this would be
useful to know.

>> Now, my lazy side simply hopes that my stridency will finally cause someone to pipe up and say "look, dummy, it's in Schmoe, Joe, 2005. "Advanced Financial Practice."  Financial Press, NY NY.  There's your reference; find it and look it up if you don't trust me" and then I'll feel like we've at least covered our communal rear-end.  But my more conscientious side worries that, if I've had so much trouble finding our more "advanced" definition (and I have tried, believe me), then I'm concerned that what your typical student (for example) is most likely to encounter is one of those simpler definitions, and thus get confused (at best) if they look at our help doc and find quite a different (at least superficially) definition (or worse, don't look at the help doc, and either can't get the function to work because the required number of inputs doesn't match what they're expecting from their text, or somehow manage to get it to work, but get an answer very
>>  different from that given in other sources, e.g., the answers in the back of their text.)
>>

I don't know that these are "formulas" per se, rather than convenience
functions for typical use cases.  That's why they're in spreadsheets
in the first place.  They also follow the behavior of financial
calculators, where you typically have to input a N, I/Y, PMT, PV and
FV (even if one of these last two values is zero).  If you need a
textbook reference, as I said before you could literally pick up any
corporate finance text and derive these functions from the basics.
Try having a look at some end of chapter questions (or financial
calculator handbook) to get an idea of when and how they'd actually be
used.

>> One obvious answer to this dilemma is to explain this discrepancy in the help doc, but then we have to explain - clearly and lucidly, mind you - how one uses our functions for the two simpler cases, how/why the formula we use is the combination of the other two, etc. (it's rather hard to anticipate, for me at least, all the possible confusions this discrepancy might create) and in any event, somehow I don't really think something so necessarily elaborate is appropriate in this case.  So, again, given that fv and pv (and by extension, nper, pmt, and rate) have multiple definitions floating around out there, I sincerely think we should "punt" (my apologies to those unfamiliar w/ the American "football" metaphor), i.e., rid ourselves of this nightmare, esp. in light of what I feel are compelling, independent arguments against the inclusion of these functions in this library in the first place.
>>
>> Sorry for my stridency, and thank you for your time and patience.
>>

I don't think that there are multiple definitions of these (very
simple) functions floating around, but rather different
assumptions/implementations that lead to ever so slightly different
results.  My plan for the additions and when checking the existing
ones is to derive the result, so that we know what's going on.  Once
you state your assumptions, the result will be clearly one way or
another.  This would be my way of "covering" our functions.  I derived
the result, so here's what's going on, here's a use case to have a
look at as an example.  Then we should be fine.

It's not that I don't appreciate your concern for being correct.  I
guess it's just that I don't share it (the concern that is) in this
case.

Skipper