
On Mon, May 25, 2009 at 11:29 PM, Robert Ferrell <ferrell@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