On Tue, Jun 9, 2009 at 1:14 AM, <[email protected]> wrote: > On Tue, Jun 9, 2009 at 12:51 AM, <[email protected]> wrote: >> >> --- On Mon, 6/8/09, Skipper Seabold <[email protected]> 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 _______________________________________________ Numpy-discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
