Simple financial functions for NumPy
Hi all, Last night I put together some simple financial functions based on the basic ones available in Excel (and on a financial calculator). It seems to me that NumPy ought to have these basic functions. There may be some disagreement about what to call them and what the interface should be. I've stuck with the Excel standard names and functionality because most of the people that will use these in the future, I expect will have seen them from Excel and it minimizes the impedance mismatch to have them be similarly named. The interface is also similar to the IMSL libraries. However, if clearly better interfaces can be discovered, then we could change it. For now, the functions are not imported into the numpy namespace but live in numpy.lib.financial I could see a future scipy module containing much, much more. Comments and improvement suggestions welcome. We are a week away from release of NumPy 1.0.5, and hopefully we can agree before then. Best regards, -Travis O.
Hi Travis, This sounds of course very interesting, but could you elaborate on the reasoning why this should not rather be "only" in SciPy !? I thought many people think that numpy was already too crowded and should concentrate mostly on being a basic array handling facility. I'm sure you have a good reason for putting these into numpy. Do you have a list of the new functions ? Wiki page ? And once more, thanks for all your great work on numpy. I'm now even trying to make a career out of using numpy for microscopy image analysis. - Sebastian Haase On Fri, Apr 4, 2008 at 3:49 PM, Travis E. Oliphant <oliphant@enthought.com> wrote:
Hi all,
Last night I put together some simple financial functions based on the basic ones available in Excel (and on a financial calculator). It seems to me that NumPy ought to have these basic functions.
There may be some disagreement about what to call them and what the interface should be. I've stuck with the Excel standard names and functionality because most of the people that will use these in the future, I expect will have seen them from Excel and it minimizes the impedance mismatch to have them be similarly named. The interface is also similar to the IMSL libraries.
However, if clearly better interfaces can be discovered, then we could change it. For now, the functions are not imported into the numpy namespace but live in
numpy.lib.financial
I could see a future scipy module containing much, much more.
Comments and improvement suggestions welcome. We are a week away from release of NumPy 1.0.5, and hopefully we can agree before then.
Best regards,
-Travis O.
On Fri, Apr 04, 2008 at 03:58:39PM +0200, Sebastian Haase wrote:
This sounds of course very interesting, but could you elaborate on the reasoning why this should not rather be "only" in SciPy !? I thought many people think that numpy was already too crowded and should concentrate mostly on being a basic array handling facility.
+1. Or in a separate package if you don't want to enforce a heavy C/fortran dependency like with scipy. Cheers, Gaël
Sebastian Haase wrote:
Hi Travis, This sounds of course very interesting, but could you elaborate on the reasoning why this should not rather be "only" in SciPy !? I thought many people think that numpy was already too crowded and should concentrate mostly on being a basic array handling facility.
This is a valid concern and I'm interested in hearing feedback. There are only two reasons that I can think of right now to keep them in NumPy instead of moving them to SciPy. 1) These are "basic" functions and a scipy toolkit would contain much more. 2) These are widely used and would make NumPy attractive to a wider audience who don't want to install all of SciPy just to get these functions. NumPy already contains functions that make it equivalent to a basic scientific calculator, should it not also contain the functions that make it equivalent to the same calculator when placed in "financial" mode? On the other hand, package distribution is getting better, and having a more modular approach is useful. I could go both ways on this one. -Travis O.
On Fri, Apr 04, 2008 at 09:11:37AM -0500, Travis E. Oliphant wrote:
There are only two reasons that I can think of right now to keep them in NumPy instead of moving them to SciPy.
1) These are "basic" functions and a scipy toolkit would contain much more. 2) These are widely used and would make NumPy attractive to a wider audience who don't want to install all of SciPy just to get these functions.
NumPy already contains functions that make it equivalent to a basic scientific calculator, should it not also contain the functions that make it equivalent to the same calculator when placed in "financial" mode?
My concern is consistency. It is already pretty hard to define what goes in scipy and what goes in numpy, and I am not even mentioning code lying around in pylab. I really thing numpy should be as thin as possible, so that you can really say that it is only an array manipulation package. This will also make it easier to sell as a core package for developpers who do not care about "calculator" features. My 2 cents, Gaël
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
I really thing numpy should be as thin as possible, so that you can really say that it is only an array manipulation package. This will also make it easier to sell as a core package for developpers who do not care about "calculator" features.
I'm a user rather than a developer, but I wonder: is this true? 1. Even as a user, I agree that what I really want from NumPy is a core array manipulation package (including matrices). BUT as long as this is the core of NumPy, will a developer care if other features are available? 2. Even if the answer to 1. is yes, could the build/installation process include an option not to build/install anything but the core array functionality? 3. It seems to me that pushing things out into SciPy remains a problem: a basic NumPy is easy to build on any platform, but SciPy still seems to generate many questions. 4. One reason this keeps coming up is that he NumPy/SciPy split is rather too crude. If the split were instead something like NumPy/SciPyBasic/SciPyFull/SciPyFull+Kits where SciPyBasic contained only pure Python code (no extensions), perhaps the desired location would be more obvious and some of this recurrent discussion would go away. fwiw, Alan Isaac
On 04/04/2008, Alan G Isaac <aisaac@american.edu> wrote:
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
I really thing numpy should be as thin as possible, so that you can really say that it is only an array manipulation package. This will also make it easier to sell as a core package for developpers who do not care about "calculator" features.
I'm a user rather than a developer, but I wonder: is this true?
1. Even as a user, I agree that what I really want from NumPy is a core array manipulation package (including matrices). BUT as long as this is the core of NumPy, will a developer care if other features are available?
2. Even if the answer to 1. is yes, could the build/installation process include an option not to build/install anything but the core array functionality?
3. It seems to me that pushing things out into SciPy remains a problem: a basic NumPy is easy to build on any platform, but SciPy still seems to generate many questions.
4. One reason this keeps coming up is that he NumPy/SciPy split is rather too crude. If the split were instead something like NumPy/SciPyBasic/SciPyFull/SciPyFull+Kits where SciPyBasic contained only pure Python code (no extensions), perhaps the desired location would be more obvious and some of this recurrent discussion would go away.
It seems to me that there are two separate issues people are talking about when they talk about packaging: * How should functions be arranged in the namespaces? numpy.foo(), scipy.foo(), numpy.lib.financial.foo(), scikits.foo(), numkitfull.foo()? * Which code should be distributed together? Should scipy require separate downloading and compilation from numpy? The two questions are not completely independent - it would be horribly confusing to have the set of functions available in a given namespace depend on which packages you had installed - but for the most part it's not a problem to have several toplevel namespaces in one package (python's library is the biggest example of this I know of). For the first question, there's definitely a question about how much should be done with namespaces and how much with documentation. The second is a different story. Personally, I would prefer if numpy and scipy were distributed together, preferably with matplotlib. Then anybody who used numpy would have available all the scpy tools and all the plotting tools; I think it would cut down on wheel reinvention and make application development easier. Teachers would not need to restrict themselves to using only functions built into numpy for fear that their students might not have scipy installed - how many students have learned to save their arrays in unportable binary formats because their teacher didn't want them to have to install scipy? I realize that this poses technical problems. For me installing scipy is just a matter of clicking on a checkbox and installing a 30 MB package, but I realize that some platforms make this much more difficult. If we can't just bundle the two, fine. But I think it is mad to consider subdividing further if we don't have to. I think python's success is due in part to its "batteries included" library. The fact that you can just write a short python script with no extra dependencies that can download files from the Web, parse XML, manage subprocesses, and save persistent objects makes development much faster than if you had to forever decide between adding dependencies and reinventing the wheel. I think numpy and scipy should follow the same principle, of coming "batteries included". So in this specific case, yes, I think the financial functions should absolutely be included; whether they should be included in scipy or numpy is less important to me because I think everyone should install both packages. Anne
On Fri, Apr 4, 2008 at 3:31 PM, Anne Archibald <peridot.faceted@gmail.com> wrote:
On 04/04/2008, Alan G Isaac <aisaac@american.edu> wrote:
On Fri, 4 Apr 2008, Gael Varoquaux apparently wrote:
I really thing numpy should be as thin as possible, so that you can really say that it is only an array manipulation package. This will also make it easier to sell as a core package for developpers who do not care about "calculator" features.
I'm a user rather than a developer, but I wonder: is this true?
1. Even as a user, I agree that what I really want from NumPy is a core array manipulation package (including matrices). BUT as long as this is the core of NumPy, will a developer care if other features are available?
2. Even if the answer to 1. is yes, could the build/installation process include an option not to build/install anything but the core array functionality?
3. It seems to me that pushing things out into SciPy remains a problem: a basic NumPy is easy to build on any platform, but SciPy still seems to generate many questions.
4. One reason this keeps coming up is that he NumPy/SciPy split is rather too crude. If the split were instead something like NumPy/SciPyBasic/SciPyFull/SciPyFull+Kits where SciPyBasic contained only pure Python code (no extensions), perhaps the desired location would be more obvious and some of this recurrent discussion would go away.
It seems to me that there are two separate issues people are talking about when they talk about packaging:
* How should functions be arranged in the namespaces? numpy.foo(), scipy.foo(), numpy.lib.financial.foo(), scikits.foo(), numkitfull.foo()?
* Which code should be distributed together? Should scipy require separate downloading and compilation from numpy?
The two questions are not completely independent - it would be horribly confusing to have the set of functions available in a given namespace depend on which packages you had installed - but for the most part it's not a problem to have several toplevel namespaces in one package (python's library is the biggest example of this I know of).
For the first question, there's definitely a question about how much should be done with namespaces and how much with documentation. The second is a different story.
Personally, I would prefer if numpy and scipy were distributed together, preferably with matplotlib. Then anybody who used numpy would have available all the scpy tools and all the plotting tools; I think it would cut down on wheel reinvention and make application development easier. Teachers would not need to restrict themselves to using only functions built into numpy for fear that their students might not have scipy installed - how many students have learned to save their arrays in unportable binary formats because their teacher didn't want them to have to install scipy?
I realize that this poses technical problems. For me installing scipy is just a matter of clicking on a checkbox and installing a 30 MB package, but I realize that some platforms make this much more difficult. If we can't just bundle the two, fine. But I think it is mad to consider subdividing further if we don't have to.
If these were tightly tied together, for instance in one big dll , this would be unpleasant for me. I still have people downloading stuff over 56k modems and adding an extra 30 MB to the already somewhat bloated numpy distribution would make there lives more tedious than they already are. I think python's success is due in part to its "batteries included"
library. The fact that you can just write a short python script with no extra dependencies that can download files from the Web, parse XML, manage subprocesses, and save persistent objects makes development much faster than if you had to forever decide between adding dependencies and reinventing the wheel. I think numpy and scipy should follow the same principle, of coming "batteries included".
One thing they try to do in Python proper is think a lot more before adding stuff to the standard library. Generally packages need to exist separately for some period of time to prove there general utility and to stabilize before they get accepted. Particularly in the core, but in the library as well, they make an effort to chose a compact set of primitive operations without a lot of duplication (the old "There should be one-- and preferably only one --obvious way to do it."). The numpy community has, particularly of late, been rather quick to add things that seem like they *might *be useful. One of the advantages of having multiple namespaces would have been to enforce a certain amount of discipline on what went into numpy, since it would've been easier to look at and evaluate a few dozen functions that might have comprised some subpackage rather than, let's say, five hundred or so. I suspect it's too late now; numpy has chosen the path of matlab and the other array packages and is slowly accumulating nearly everything in one big flat namespace. I don't like it, but it seems pointless to fight it at this point. So in this specific case, yes, I think the financial functions should
absolutely be included; whether they should be included in scipy or numpy is less important to me because I think everyone should install both packages.
Personally I think it's a bad idea to add stuff that, as far as I can tell, no has even asked for yet. Put them in the sandbox. Advertise them. If people use them, figure out what needs to be changed. Then add them to SciPy once they've stabilized, if they actually get used. -- . __ . |-\ . . tim.hochberg@ieee.org
On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
<snip> There are only two reasons that I can think of right now to keep them in NumPy instead of moving them to SciPy.
1) These are "basic" functions and a scipy toolkit would contain much more.
Isn't this something you want to avoid? Functionality in two different packages: a small kit of functions in NumPy, and (eventually) another large toolkit in scipy. One package only, would be more convenient I think. I agree with Gaël that it's not really consistent with the NumPy/SciPy philosophy either. :-). So, I would prefer to see this nice functionality in SciPy rather than in NumPy. Joris Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
On Fri, Apr 4, 2008 at 10:17 AM, Joris De Ridder < Joris.DeRidder@ster.kuleuven.be> wrote:
On 04 Apr 2008, at 16:11, Travis E. Oliphant wrote:
<snip> There are only two reasons that I can think of right now to keep them in NumPy instead of moving them to SciPy.
1) These are "basic" functions and a scipy toolkit would contain much more.
Isn't this something you want to avoid? Functionality in two different packages: a small kit of functions in NumPy, and (eventually) another large toolkit in scipy. One package only, would be more convenient I think.
I agree with Gaël that it's not really consistent with the NumPy/SciPy philosophy either. :-). So, I would prefer to see this nice functionality in SciPy rather than in NumPy.
Agree. I also think that the idea of basic, pure python extensions is a good one. There is a lot of useful functionality that can be made available without adding Fortran packages to the mix. These packages could even be included as part of numpy but they should remain in a separate namespace. Chuck
Sebastian Haase wrote:
Hi Travis, This sounds of course very interesting, but could you elaborate on the reasoning why this should not rather be "only" in SciPy !? I thought many people think that numpy was already too crowded and should concentrate mostly on being a basic array handling facility.
I just thought of one more thing that is probably swaying that mysterious "gut feel" : NumPy is on the laptop in the OLPC project. I want to give those kids access to simple financial calculations for learning about time-preference for money and the value of saving. -Travis O.
A Friday 04 April 2008, Travis E. Oliphant escrigué:
Sebastian Haase wrote:
Hi Travis, This sounds of course very interesting, but could you elaborate on the reasoning why this should not rather be "only" in SciPy !? I thought many people think that numpy was already too crowded and should concentrate mostly on being a basic array handling facility.
I just thought of one more thing that is probably swaying that mysterious "gut feel" :
NumPy is on the laptop in the OLPC project. I want to give those kids access to simple financial calculations for learning about time-preference for money and the value of saving.
Yeah :) +1 for including these in NumPy. --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
On Fri, Apr 4, 2008 at 9:49 AM, Travis E. Oliphant <oliphant@enthought.com> wrote:
However, if clearly better interfaces can be discovered, then we could change it. For now, the functions are not imported into the numpy namespace but live in
numpy.lib.financial
I could see a future scipy module containing much, much more.
Comments and improvement suggestions welcome. We are a week away from release of NumPy 1.0.5, and hopefully we can agree before then.
I'm generally in agreement with other opinions about keeping numpy lightweight even though I think these functions are useful and should be widely distributed with numpy. I've struggled with the various masked array implementations being worlds unto their own, falling down unexpectedly when mixed with other numpy functions, so keeping a narrow focus seems beneficial (as in its clear that I shouldn't expect A and B to work necessarily together). Nevertheless, I like getting a lot of utility from each package as it seems cognitive load is proportional to the number of packages required-- especially when the packages are compiled. Perhaps, as others have suggested, there should be some sort of pure-python numpy library package (a NumPyLib, if you will) that sits between numpy and scipy? I'm a numpy user but not a scipy user (I guess from an attempt to decrease the cognitive load of yet another compiled python package), so I'm speaking from that perspective. I also wouldn't be opposed to (for NumPy 4 :) breaking out the core ndarray class and basic linalg (solve, svg, eig, etc.) as NDArray and putting everything else into logically separated but independent NumKits. A blessed collection of which are together taken and distributed as "NumPy". Anything depending on one ore more NumKits would go into a SciKit, with a blessed collection distributed together as "SciPy". Has this basic distribution architecture already been proposed? I've heard hints of something along these lines. If so, then the new new financial functions should go into numpy.lib, where everything will later be broken out into a NumKit. Hmm. I've just argued myself in a circle... :O Regards, Alex
participants (10)
-
Alan G Isaac -
Alexander Michael -
Anne Archibald -
Charles R Harris -
Francesc Altet -
Gael Varoquaux -
Joris De Ridder -
Sebastian Haase -
Timothy Hochberg -
Travis E. Oliphant