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

[Skipper Seabold]

On Tue, May 26, 2009 at 1:12 AM, Robert Kern <robert.kern at gmail.com> wrote:
> On Mon, May 25, 2009 at 23:59, Joe Harrington <jh at physics.ucf.edu> wrote:
>> Let's keep this thread focussed on the original issue:
>>
>> just add a floating array of times to irr or a new xirr
>> continuous interest
>> no more
>>
>> Anyone can use the timeseries package to produce a floating array of
>> times from normal dates, if those are the dates they want.  If they
>> want some specialized financial date, they may want a different
>> conversion, however.  All we should provide in NumPy would be the
>> simplest tool.  Specialized dates and date-time conversion belong
>> elsewhere.
>>
>> If we're *not* skipping dates, there is no need for xirr, just use
>> irr, which exists.
>>
>> scikits.financial seems like a great idea, and then knock yourselves
>> out for date conversions and definitions of compounding.  Just think
>> big and design it first.  But let's keep this thread on the simple
>> question for NumPy.
>
> Then let's just say "No" and move on. I see no compelling reason to
> extend numpy's financial capabilities (of course, I spoke against
> their original addition in the first place, so take that as you will).
> Handling this by asking, "here are the constraints for numpy; what can
> we shoehorn in there?" is the wrong approach. Figure out what you want
> to achieve, then figure out what you need to solve the problem best. I
> don't think that including xirr in numpy, with its constraints, serves
> the problem best.
>

My only question then would be why have numpy.financials in the first
place?  I was pretty surprised to find it.  Maybe it should be in
scipy.financials, so it can take advantage of the solvers?  There's
already the three line Newton method implementation that can only be
used for rates(), which did seem "shoehorned" to me already.  I
changed mine to rely on a few lines of the Newton secant method (that
could be general enough for rates() ) and to work without any internal
date dependencies, but I too get the sense that it shouldn't be there,
but these type of "expected" spreadsheet-like functions (with a set
API and accepted usage behavior) seem to be of interest to some.

Not trying to beat a dead horse.  Just a thought, because I do have
some interest in expanding these kinds of functions wherever they
could end up.

-Skipper