Re: [Numpy-discussion] Simple financial functions for NumPy
Right now it looks like there is a mix of attitudes, about the financial functions. They are a small enough addition, that I don't think it matters terribly much what we do with them. So, it seems to me that keeping them in numpy.lib and following the rule for that namespace for 1.0.5 will be viewed as anywhere from tolerable to a good idea depending on your point of view. Just to be sure, you are talking about functions to compute interest rates, cumulative interests, asset depreciation, annuity periodic payments, security yields, and stuff like this? Joris Actually, I was wondering about this, I wasn't sure if you might mean option pricing, stochastic calculus and black-scholes analytic formulae. I use these things fairly heavily, calling NumPy and SciPy functions. My instinct is that these are probably more appropriate for SciPy since they are quite niche (in comparison to something like fourier transforms). Peter ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
I'm just a numpy user, but for what it's worth, I would much prefer to have a single numpy namespace with a small as possible number of objects inside that namespace. To me, 'as small as possible' means that it only includes the array and associated array manipulation functions (searchsorted, where, and the record array functions), and the various functions that operate on arrays (exp, log, sin, cos, abs, any, etc). Having a small number of objects in a single namespace means that numpy is much easier to learn for beginners, as it's easier to find the appropriate thing for what you want to do (this is also helped by reducing duplication *shakes fist at .compress* and good documentation). It's also much easier to explore with dir() to jog your memory as to what function you need for a task. If I felt I contributed enough to this list to have a '1', I would be -1 on adding financial functions to numpy. On Fri, Apr 4, 2008 at 3:31 PM, Anne Archibald [EMAIL PROTECTED] wrote: On 04/04/2008, Alan G Isaac [EMAIL PROTECTED] wrote: 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
[Numpy-discussion] 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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 [EMAIL PROTECTED] 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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 - ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
+1 for simple financial functions in numpy, and congrats that it's on OLPC! If we have an FFT in numpy, we should have an internal rate of return. Anyone with investments needs that, and that's more people than those needing an FFT. I agree that Excel will bring in the most familiarity, but their names are not always rational. Please don't propagate irrational names. Consider looking at what they're called in Matlab and IDL, as code conversion/familiarity from those communities counts as well. Maybe for each function take the most rational name and arg order from those three sources, with strong preference for Excel unless there is a clear better way to do it. --jh-- ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
-1 for any functions added to numpy. As only an end-user, I realize I have little right to a say in these sorts of issues, but for whatever it may be worth, I strongly agree with Gael's viewpoint. We should be aiming towards modular systems for function distribution, and now that it seems that these are being gradually worked out (scikits?), I think we should avoid adding anything to numpy, which should rather be kept to a bare minimum: just the necessaries for array creation and manipulation. Everything else should go in the add-on modules which can be installed as required. This have the benefit that the numpy package stays well-defined and contained, meaning that end-users know exactly what to expect as available on a given system. Instead of wondering Where do I find functions for x. I know numpy has some things. Maybe it's in there or maybe somewhere else. I would always know that in order to get functions for x I would install the correct, usefully named, module. This seems like the path of least surprise, and a cleanest interface. I agree it's great that numpy is on the OLPC, and would like to see it accompanied there by a Basic Functions module containing, for example, these financial functions, which certainly sound useful... but not for everyone. On 04/04/2008, Joe Harrington [EMAIL PROTECTED] wrote: +1 for simple financial functions in numpy, and congrats that it's on OLPC! If we have an FFT in numpy, we should have an internal rate of return. Anyone with investments needs that, and that's more people than those needing an FFT. I agree that Excel will bring in the most familiarity, but their names are not always rational. Please don't propagate irrational names. Consider looking at what they're called in Matlab and IDL, as code conversion/familiarity from those communities counts as well. Maybe for each function take the most rational name and arg order from those three sources, with strong preference for Excel unless there is a clear better way to do it. --jh-- ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- AJC McMorland, PhD candidate Physiology, University of Auckland Post-doctoral research fellow Neurobiology, University of Pittsburgh ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
On Fri, Apr 4, 2008 at 10:17 AM, Joris De Ridder [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
On Fri, Apr 4, 2008 at 9:49 AM, Travis E. Oliphant [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
On 04/04/2008, Alan G Isaac [EMAIL PROTECTED] 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 ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Simple financial functions for NumPy
On Fri, Apr 4, 2008 at 3:31 PM, Anne Archibald [EMAIL PROTECTED] wrote: On 04/04/2008, Alan G Isaac [EMAIL PROTECTED] 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
