[Numpy-discussion] add xirr to numpy financial functions?
Sun May 24 17:14:42 CDT 2009
On Sun, May 24, 2009 at 4:33 PM, Joe Harrington <email@example.com> wrote:
> I hate to ask for another function in numpy, but there's an obvious
> one missing in the financial group: xirr. It could be done as a new
> function or as an extension to the existing np.irr.
> The internal rate of return (np.irr) is defined as the growth rate
> that would give you a zero balance at the end of a period of
> investment given a series of cash flows into or out of the investment
> at regular intervals (the first and last cash flows are usually an
> initial deposit and a withdrawal of the current balance).
> This is useful in academics, but if you're tracking a real investment,
> you don't just withdraw or add money on a perfectly annual basis, nor
> do you want a calc with thousands of days of zero entries just so you
> can handle the uneven intervals by evening them out. Both excel and
> openoffice define a "xirr" function that pairs each cash flow with a
> date. Would there be an objection to either a xirr or adding an
> optional second arg (or a keyword arg) to np.irr in numpy? Who writes
> the code is a different question, but that part isn't hard.
* open office has also the other function in an x??? version, so it
might be good to add it consistently to all functions
* date type: scikits.timeseries and the gsoc for implementing a date
type would be useful to have a clear date type, or would you want to
base it only on python standard library
* real life accuracy: given that there are large differences in the
definition of a year for financial calculations, any simple
implementation would be only approximately accurate. for example in
the open office help, oddlyield list the following option
Basis is chosen from a list of options and indicates how the year is
to be calculated.
0 or missing US method (NASD), 12 months of 30 days each
1 Exact number of days in months, exact number of days in year
2 Exact number of days in month, year has 360 days
3 Exact number of days in month, year has 365 days
4 European method, 12 months of 30 days each
So, my question: what's the purpose of the financial function in numpy?
Currently it provides convenient functions for (approximate) interest
If they get expanded to a "serious" implementation of, for example,
the main financial functions listed in the open office help (just for
reference) then maybe numpy is not the right location for it.
I started to do something similar in matlab, and once I tried to use
real dates instead of just counting months, the accounting rules get
quickly very messy.
Using dates as you propose would be very convenient, but the users
shouldn't be surprised that their actual payments at the end of the
year don't fully match up with what numpy told them.
More information about the Numpy-discussion