[Numpy-discussion] add xirr to numpy financial functions?

[josef.pktd at gmail.com]

On Mon, May 25, 2009 at 11:29 PM, Robert Ferrell <ferrell at diablotech.com> wrote:
> I haven't read all the messages in detail, and I'm a consumer not a
> producer, but I'll comment anyways.
>
> I'd love to see additional "financial" functionality, but I'd like to
> see them in a scikit, not in numpy.  I think to be useful they are too
> complicated to go into numpy.  A couple of my many reasons:
>
> 1. Doing a precise, bang-up job with dates is paramount to any
> interesting implementation of many financial functions.  I've found
> timeseries to be a great package - there are some things I'd like to
> see, but overall it is at the foundation of all of my financial
> analysis.  Any moderately interesting extension of the current
> capabilities would rapidly end up trying to duplicate much of the
> timeseries functionality, IMO.  Rather than partially re-implement the
> wheel in numpy, as a consumer I'd like to see financial stuff built on
> a common basis, and timeseries would be a great start.
>
> 2. I've read enough of this discussion to hear a requirement for both
> good date handling and capable solvers - just for xirr.  To do a
> really interesting job on an interesting amount of capability requires
> even more dependencies, I think.
>
> Although it might be tempting to include a few more "lightweight"
> financial functions in numpy, I doubt they will be that useful.  Most
> of the lightweight ones are easy enough to whip up when you need
> them.  Also, an approximation that's good today isn't the right one
> tomorrow - only the really robust stuff seems to survive the test of
> time, in my limited experience.  A start on a really solid scikits
> financial package would be awesome, though.
>
> A few months ago, when the open source software for pricing CDS's was
> released (http://www.cdsmodel.com/information/cds-model) I took a look
> and noticed that it had a ton of code for dealing with dates.  (I also
> didn't see any tests in the code.  I wonder what that means.  Scary
> for anybody that might want to modify it.)  I thought if I had an
> extra 100 hours in every day it would be fun to re-write that code in
> numpy/scipy and release it.
>

I was looking at mortgage backed securities before the current crisis
hit, and I realized that when I use real dates and real payment
schedules then taking actual accounting rules into account, my work
and code size would strongly increase. Since it was a semi-theoretic
application, sticking to months and ignoring actual calender dates was
a useful simplification.

As Matt argued it is not possible (or maybe just unrealistic) to write
a full finance package in python from scratch. As far as I understand,
for example the time series scikits cannot handle business holidays.
So some simplification will be necessary. But, I agree, that even for
an "approximate" finance package, handling dates and timeseries
without a corresponding array type will soon get very tedious or
duplicative.

One additional advantage of a scikits, besides more freedom for
dependencies, would be that models can be incrementally added as
contributers find time and interest, and gain more experience with the
API and the appropriate abstraction, and to collect hacked up scripts
before they get a common structure and implementation. If the only
crucial dependency is the time series package, it could go possibly
into scipy together with the time series scikits. Also targeting
scipy, makes a lot of code available, e.g. the problem with the solver
and including statistics.

"A sparrow in the hand is better than a pigeon on the roof." (German Proverb)
On the other hand, I have seen many plans on the mailing list for
great new packages or extensions to existing packages without many
results. So maybe an incremental inclusion of the functions and API of
open office, excel or similar, now, instead of hoping for a "real"
finance package is the more realistic approach, especially, because I
haven't found any source where we could "steal" wholesale. (for
example http://www.cdsmodel.com/information/cds-model doesn't look
compatible with BSD)

Josef