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

Skipper Seabold jsseabold at gmail.com
Tue Jun 9 23:50:40 EDT 2009

```On Tue, Jun 9, 2009 at 12:58 PM, David Goldsmith<d_l_goldsmith at yahoo.com> wrote:
>
> --- On Tue, 6/9/09, Skipper Seabold <jsseabold at gmail.com> wrote:
>
>> 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.
>
> Use case examples aren't the problem; worked out examples combining these two principles aren't the problem; usefulness isn't the problem; the problem is one of meeting a particular reference standard.
>
>> I don't know that these are "formulas" per se, rather than
>
> Except that we do provide a "formula" in our help doc; perhaps the "solution" is to get rid of that and include an explanation of how our function combines the two basic formulae (for which I do have a hard-copy reference: Gitman, L. J., 2003.  "Principals of Managerial Finance (Brief), 3rd Ed."  Pearson Education) to handle the more general case.
>
>> 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.
>
> I don't question that, what I question is the appropriateness of such derivation in numpy's help doc; as I see it, one of the purposes of providing references in our situation is precisely to avoid having to include derivations in our help doc.
>
> But it's all moot, as Robert has furnished me with a reference specifically for the "formula" we do have, and, although it's an electronic reference, it seems "stable" enough to warrant an exception to the "references should be hard-copy AMAP" policy.
>

Just to follow up a bit with this.  I don't want to beat a dead horse,
but I'd just like to share my experience with these documents and
functions so far.

I have implemented the ipmt and ppmt functions that were "not
implemented" in numpy.lib.financial as well as written some tests.
ipmt is one of the functions where there was a discrepancy between
what OO and Excel report for the beginning of period payment
assumptions and what Gnumeric and Kspread report as stated in the
OpenFormula document referenced above (I discovered errors in this
document as well as the openoffice documents referenced btw but they
become obvious when you work these problems out).  OpenFormula lists
the Gnumeric/Kspread as the "result" in the document, but there is
still a question to which is correct.  Well, I was able to derive both
results, and as I suspected the Gnumeric/Kspread was based on an
incorrect assumption (or a mistake in implementation) not a different
formula.  My point with the derivations wasn't to include them in the
documentation, but rather to find out what assumptions are being made
and then deduce which results are correct.  In the cases of these
simple spreadsheet functions I think it should be obvious if it's
right or wrong.

If there is any interest in adding the ipmt and ppmt functions now, I
can apply a patch.  If not, I can keep them separate as I work on the
other functions.

Cheers,

Skipper

```

More information about the NumPy-Discussion mailing list