Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 10 Apr 2008, at 05:21, Travis E. Oliphant wrote: 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 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] packaging scipy (was Re: Simple financial functions for NumPy)
Sorry to be late on this thread, but I was out of town, and I do feel strongly about this issue. Gael Varoquaux wrote: For the beginner, from numpy.all import * is more confusing than from numpy import * (which is already confusing). except that the beginner, nor anyone else, should ever use import * anyway! I know namespace are good things, but the beginner struggles with them. This is why I used the import * in my above examples. You're better off with a good foundation -- really. And particularly for a beginner, knowing what comes from numpy, and what from python (or other packages) is a good thing. It's a mixed bag, but I like namespaces a lot -- there's a lot to be said for thinking: I need some stats, an doing something like: from numpy.stats import stats That being said, having a numpy.all namespace has its uses, particularly for interactive use, but let's not make it the default. Look at history here: Everyone used to do from Numeric import *, now many (most?) folks use the numpy namespace, with something like import numpy as N. Matplotlib started out with a Matlab like: from pylab import *, now there is a separate namespace for plotting, etc, and a movement towards using separate namespaces. Namespaces are one honking great idea -- let's do more of those! That's more, not fewer Gael Varoquaux wrote: Convention are important, especially in coding. This is really, really important. What if we all used a different name for self? -- just as correct, but it would be a lot harder to understand other's code. I really don't get the reluctance -- EVERY major package I've worked with has moved AWAY from import * (numpy, wxPython, matplotlib, ...). We should never, never, recommend it to beginners. Period. And it would be very nice to use a standard. I use import numpy as N, but would be quite happy to use np or nx, or anything else short that becomes a standard. IMHO the pylab option is quite nice: matplotlib is nice and modular, but pylab has it all. Use whichever you want. I disagree -- with pylab and numpy, there is constant confusion from folks as they move past the beginner stage -- where did that function come from?, What do I have to change now that I'm embedding my MPL code in a GUI? There should be one-- and preferably only one --obvious way to do it. Maybe there is a large population of folks that never do move past the beginner stage -- but I say -- let then use Octave! I use Python specifically because it's a more sophisticated language than Matlab. The only thing namespaces solve is name collisions imho. The other one is readability -- I like knowing where things come from, and what that have to do with. This is really an augment against import *, but it applied to hierarchical namespaces too -- you can see the structure in the code, -- I like that. I don't believe that the current numpy has too many names in its basic namespace, It's a little too big, rather than a lot too small though -- remember this thread started from where do we put financial functions. and it already has split out some things into subpackages (fft, random, linear algebra) that have such a potential. exactly -- so numpy.finance fits right in... 3) Some don't like the bloat (in disk space or download sizes) of adding things to numpy. In my case, as long as the addition doesn't make installations any more difficult I don't care. +1 Easy of installation is far more important than download size. Brian Granger wrote: Simply putting things into numpy because of convenience (numpy is easier to install) only encourages people to never install or use scipy. Actually it's worse -- it discourages us from making scipy easier to install. I still don't use it. But we can save most of this for 1.1 (or 2.0, or...) -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Wed, Apr 09, 2008 at 11:27:04AM -0700, Christopher Barker wrote: Gael Varoquaux wrote: For the beginner, from numpy.all import * is more confusing than from numpy import * (which is already confusing). except that the beginner, nor anyone else, should ever use import * anyway! Right! Sure. Tell this to a medical doctor who just wants to learn as little things as possible about a computer in order to process his MRI data and finish his PhD to never have to worry anymore with stupid things like programming language. from foo import * does have a usecase. It is suited only for small scripts, but for people who want to learn as little as possible, it is nice. As you design something, ask “is this relevant to what people are trying to do?” rather than “is this confusing?” […] It doesn’t matter whether people could figure something out. It matters whether they’re interested in figuring it out - is it part of what they’re trying to do, or an annoying sidetrack? (taken from http://log.ometer.com/2008-03.html#5) Some people do not want their scripts to scale or to last more than a day. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
2008/4/9, Gael Varoquaux [EMAIL PROTECTED]: [snip] Some people do not want their scripts to scale or to last more than a day. And that's what Matlab is especially good at ! ; ) And I'll say the thing I'm dying to say since this started: If anybody other than Travis had suggested we put financial functions in numpy the response would have been: make it a scikit, let the functions mature and evolve, get some feedback from users and then we'll see where they fit in. The fact that we are still discussing this shows the huge amount of respect Travis has in this community, but also the lack of guidelines for NumPy's growth. Maybe it's time for us to decide on a procedure for NEPs (Numpy Enhancement Proposals) ! Regards, David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Wed, Apr 09, 2008 at 04:18:41PM -0400, David Huard wrote: And that's what Matlab is especially good at ! ; ) Exactly. I would like to have the same ease of use for beginners than Matlab. The reason being that _I_ would be able develop my own module using the powerful feature of Python, but I could then give it to non technical users. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Gael Varoquaux wrote: the beginner, nor anyone else, should ever use import * Right! Sure. Tell this to a medical doctor who just wants to learn as little things as possible about a computer in order to process his MRI data and finish his PhD to never have to worry anymore with stupid things like programming language. from foo import * does have a usecase. I still think that if someone is writing more than ten lines of code, import * is a bad idea. It is suited only for small scripts, There is a difference between scripting and programming, and you can do either with Python. Indeed, that is one of its strengths. Some people do not want their scripts to scale or to last more than a day. True, but is Python the best tool for that? I don't know. I I know I use it, rather than Matlab, or bash, because I do want that scalability. I also think it's better to be able to scale with it feeling like you're learning a new language when you do so. The reason being that _I_ would be able develop my own module using the powerful feature of Python, but I could then give it to non technical users. Then I suppose you can give them a ready to use environment, with the relevant stuff to their problem already imported for them -- that could be very useful. Anyway, yes, there are use cases, but I think we should generally advocate a more scalable style. I have yet to advocate that the Matlab users in my group (The Scientists that happen to need a bit of programming, but have no interest in it) start using Python, but, frankly, import *, and minor syntax like that has nothing to do with it. Aside from the fact that they are already familiar with Matlab, the big issues are the fact that there is no one thing they can install to get an IDE, complete and well integrated plotting, and extensive library of assorted functions. Numpy+Scipy+MPL+Who-knows-what-editor are close, but the ease of use is not there yet, and it's NOT because of too many namespaces. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Wed, Apr 9, 2008 at 3:57 PM, Jarrod Millman [EMAIL PROTECTED] wrote: Absolutely. Let's please standardize on: import numpy as np import scipy as sp See: http://projects.scipy.org/scipy/numpy/wiki/CodingStyleGuidelines http://svn.scipy.org/svn/numpy/trunk/numpy/doc/example.py It is slowly becoming a standard and I would strongly encourage everyone to follow it. Thanks for bringing this up! If I recall correctly, at the December sprint there was an IRC/gchat discussion on this and the above was agreed upon, so I've been trying to retrain my finger memory already since then. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Wed, Apr 9, 2008 at 4:57 PM, Jarrod Millman [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 11:27 AM, Christopher Barker [EMAIL PROTECTED] wrote: except that the beginner, nor anyone else, should ever use import * anyway! +1 Namespaces are one honking great idea -- let's do more of those! That's more, not fewer Agreed. I really don't get the reluctance -- EVERY major package I've worked with has moved AWAY from import * (numpy, wxPython, matplotlib, ...). We should never, never, recommend it to beginners. Period. And it would be very nice to use a standard. I use import numpy as N, but would be quite happy to use np or nx, or anything else short that becomes a standard. Absolutely. Let's please standardize on: import numpy as np import scipy as sp import numpy.linalg as la ? Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mittwoch 09 April 2008, Charles R Harris wrote: import numpy.linalg as la ? Yes! :) Andreas signature.asc Description: This is a digitally signed message part. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
And I'll say the thing I'm dying to say since this started: If anybody other than Travis had suggested we put financial functions in numpy the response would have been: make it a scikit, let the functions mature and evolve, get some feedback from users and then we'll see where they fit in. The fact that we are still discussing this shows the huge amount of respect Travis has in this community, but also the lack of guidelines for NumPy's growth. Maybe it's time for us to decide on a procedure for NEPs (Numpy Enhancement Proposals) ! I appreciate that. It is rewarding to have time invested be regarded usefully by others. But, I've always seen the growth of NumPy as a community effort and there have been many voices with more wisdom than mine who have guided it. So, I'm not sure if it is accurate that some are not expressing their true attitudes toward the addition of these functions, but if it is then please don't hold back. I really do want accurate and sincere feedback. NumPy owes a great intellectual debt to all the mailing list discussions over the years. 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. The discussion does demonstrate that there are a lot of opinions. This to me is the sign of a healthy community.Fantastic! Only by hearing all the points of view can NumPy continue to improve. -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Hi Chris On 09/04/2008, Christopher Barker [EMAIL PROTECTED] wrote: I have yet to advocate that the Matlab users in my group (The Scientists that happen to need a bit of programming, but have no interest in it) start using Python, but, frankly, import *, and minor syntax like that has nothing to do with it. Aside from the fact that they are already familiar with Matlab, the big issues are the fact that there is no one thing they can install to get an IDE, complete and well integrated plotting, and extensive library of assorted functions. Numpy+Scipy+MPL+Who-knows-what-editor are close, but the ease of use is not there yet, and it's NOT because of too many namespaces. I'm toying with the idea of having our students install SAGE this year. This would give them a great framework for interactive experimentation. I am worried, however, that it would keep them from learning how to write standalone Python code, with proper structure in terms of classes etc. -- SAGE is not an IDE after all. On the other hand it does address the packaging issue. I'm placing my hope in IPython (IPython1), with its (in-development) notebook interface. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Perry Greenfield wrote: ... Some random comments: 1) It seems to me that the primary problem people have with a big flat namespace is that it makes the output of dir() long and unusable, and by implication, that a nice hierarchical organization would make it easier for people to find stuff. As to the latter, less so than you might think. From what I've seen, there is no generally agreed upon organization that all will agree to or find intuitive. There will always be functions that logically belong to more than one category. Ultimately, this is why flatter is better as far as that goes. If one wants to find things by category, we would be much better off tagging functions with categories and then building some dir-like tool that helps display things in that category. Some have already alluded to that (Joe Harrington I believe). The only thing namespaces solve is name collisions imho. I don't believe that the current numpy has too many names in its basic namespace, and it already has split out some things into subpackages (fft, random, linear algebra) that have such a potential. At the IPython Sprint in Boulder last year Fernando suggested that someone look at this issue. I've given it some thought and started a wiki page for it. Inputs would be welcome and might motivate me to find the time to implement something. http://ipython.scipy.org/moin/Developer_Zone/SearchDocs # Steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Tue, Apr 08, 2008 at 06:15:25AM -0600, Steven H. Rogers wrote: At the IPython Sprint in Boulder last year Fernando suggested that someone look at this issue. I've given it some thought and started a wiki page for it. Inputs would be welcome and might motivate me to find the time to implement something. http://ipython.scipy.org/moin/Developer_Zone/SearchDocs A huge progress has been made in the direction of solving this problem with the release of sphinx (http://sphinx.pocoo.org/). This is a documentation-generation tool that creates html docs from restructured text. The docs are really nice, but a very interesting feature is that they have a search page, which works with javascript code on the client: no need for a server. For documenting Mayavi, I generated a function reference from the docstrings. It is very easy using the inspect module. Then I used my homebrewed rst comiler to build the docs. I plan to replace this with sphinx very soon. This will give us ability to search the docstrings and the full docs (dostrings cannot replace a user manual). Ipython and sympy have also decided to go the sphinx way. In fact Ondrej has already converted the ipython1 docs to sphinx, you can check them out on: http://ipython.scipy.org/doc/ipython1/html/ http://ipython.scipy.org/doc/ipython1/ipython1.pdf Sphinx seems a very promising to the everlasting problem of documentation. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Tue, April 8, 2008 07:28, Gael Varoquaux wrote: ... http://ipython.scipy.org/doc/ipython1/html/ http://ipython.scipy.org/doc/ipython1/ipython1.pdf Sphinx seems a very promising to the everlasting problem of documentation. Thanks for bringing this up. I need to look at Sphinx. Regards, Steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Tue, Apr 8, 2008 at 2:23 PM, Steven H. Rogers [EMAIL PROTECTED] wrote: On Tue, April 8, 2008 07:28, Gael Varoquaux wrote: ... http://ipython.scipy.org/doc/ipython1/html/ http://ipython.scipy.org/doc/ipython1/ipython1.pdf Sphinx seems a very promising to the everlasting problem of documentation. Thanks for bringing this up. I need to look at Sphinx. Just to mention that this doesn't necessarily override the need for a faster/more roubst database-backed doc index, but it certainly provides a lot of funcitonality out of the box for end users, which is one of the reasons I'm so excited (and grateful) about it. If more of our combined/related projects use sphinx, users will have a reasonably uniform doc-searching experience with high-quality (at least visually :) docs, and PDF to boot. Cheers, f ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Fernando Perez wrote: On Tue, Apr 8, 2008 at 2:23 PM, Steven H. Rogers [EMAIL PROTECTED] wrote: On Tue, April 8, 2008 07:28, Gael Varoquaux wrote: ... http://ipython.scipy.org/doc/ipython1/html/ http://ipython.scipy.org/doc/ipython1/ipython1.pdf Sphinx seems a very promising to the everlasting problem of documentation. Thanks for bringing this up. I need to look at Sphinx. Just to mention that this doesn't necessarily override the need for a faster/more roubst database-backed doc index, but it certainly provides a lot of funcitonality out of the box for end users, which is one of the reasons I'm so excited (and grateful) about it. If more of our combined/related projects use sphinx, users will have a reasonably uniform doc-searching experience with high-quality (at least visually :) docs, and PDF to boot. Cheers, f There's definitely a place for docsearch from the shell. There's opportunity for context sensitive search that Sphinx generated docs couldn't easily duplicate. # Steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
2008/4/4, Joe Harrington [EMAIL PROTECTED]: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S I don't think the issue is whether to put everything in the base namespace // everything in individual namespace, but rather to find an optimal and intuitive mix between the two. For instance, the io functions would be easier to find by typing np.io.loadtxt than by sifting through the 500+ items of the base namespace. The stats functions could equally well be in a separate namespace, given that the most used are implemented as array methods. I think this would allow numpy to grow more gracefully. As for the financial functions, being specific to a discipline, I think they rather belongs with scipy. The numpy namespace will quickly become a mess if we add np.geology, np.biology, np.material, etc. Of course, this raises the problem of distributing scipy, and here is a suggestion: Change the structure of scipy so that it looks like the scikits: scipy/ sparse/ cluster/ financial/ ... fftpack/ setup.py scipy/ __init__.py fftpack/ The advantage is that each subpackage can be installed independently of the others. For distribution, we could lump all the pure python or easy to compile packages into scipy.common, and distribute the other packages such as sparse and fftpack independently. My feeling is that such a lighter structure would encourage projects with large code base to join the scipy community. It would also allow folks with 56k modems to download only what they need. David ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 07/04/2008, David Huard [EMAIL PROTECTED] wrote: 2008/4/4, Joe Harrington [EMAIL PROTECTED]: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S I don't think the issue is whether to put everything in the base namespace // everything in individual namespace, but rather to find an optimal and intuitive mix between the two. For instance, the io functions would be easier to find by typing np.io.loadtxt than by sifting through the 500+ items of the base namespace. The stats functions could equally well be in a separate namespace, given that the most used are implemented as array methods. I think this would allow numpy to grow more gracefully. I agree, and I think we can come to some compromise -- maybe a numpy.all namespace, that simply imports all the other subpackages. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote: I agree, and I think we can come to some compromise -- maybe a numpy.all namespace, that simply imports all the other subpackages. For the beginner, from numpy.all import * is more confusing than from numpy import * (which is already confusing). I know namespace are good things, but the beginner struggles with them. This is why I used the import * in my above examples. My 2 cents, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 07/04/2008, Gael Varoquaux [EMAIL PROTECTED] wrote: On Mon, Apr 07, 2008 at 05:20:47PM +0200, Stéfan van der Walt wrote: I agree, and I think we can come to some compromise -- maybe a numpy.all namespace, that simply imports all the other subpackages. For the beginner, from numpy.all import * is more confusing than from numpy import * (which is already confusing). I know namespace are good things, but the beginner struggles with them. This is why I used the import * in my above examples. You're only a beginner for a short while, and after that the lack of namespaces really start to bite. I am all in favour of catering for those who are busy learning numpy, but should we do that at the cost of our advanced users? There must be a way to make both groups happy -- any suggestions? Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote: You're only a beginner for a short while, and after that the lack of namespaces really start to bite. I am all in favour of catering for those who are busy learning numpy, but should we do that at the cost of our advanced users? I agree with you. However lowering the bar is a good thing. There must be a way to make both groups happy -- any suggestions? Hum, I am still trying to find ideas. If only from foo.bar import baz didn't import all what is in foo.__init__ !!! By the way, the standard solution to this problem is to use a module called api and not all. That's what people have been doing to solve the problem we are faced with. If we are going to go this way, I suggest we stick to the api convention (eventhought it sucks). Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 9:57 AM, Gael Varoquaux [EMAIL PROTECTED] wrote: On Mon, Apr 07, 2008 at 06:22:28PM +0200, Stéfan van der Walt wrote: You're only a beginner for a short while, and after that the lack of namespaces really start to bite. I am all in favour of catering for those who are busy learning numpy, but should we do that at the cost of our advanced users? I agree with you. However lowering the bar is a good thing. There must be a way to make both groups happy -- any suggestions? Hum, I am still trying to find ideas. If only from foo.bar import baz didn't import all what is in foo.__init__ !!! By the way, the standard solution to this problem is to use a module called api and not all. That's what people have been doing to solve the problem we are faced with. If we are going to go this way, I suggest we stick to the api convention (eventhought it sucks). I prefer 'all' for this since it has the correct meaning. 'api' assuming that one can remember what it means doesn't fit. The 'all' module would not contain the api, at least not the preferred api (in my book at least), but it would contain everything. If from numpy.all import * is really too complicated, which although possible, seems a little disheartening, I suspect it would be easy enough to have a separate module that pulled everything in so that you could use from big_numpy import *. Or, to preserve backward compatibility, make numpy the unsplit namespace and expose the split namespace under a different name, let's say 'np' because that's what I already use as a numpy abbreviation. Then import np would get you just the core np functions (which I imagine we could argue about endlessly) and the various subpackages would be imported separately. 'np' is 'numpy' with some stuff removed: get it? OK, so that's a weak joke, sorry. -- . __ . |-\ . . [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, April 7, 2008 11:16, Timothy Hochberg wrote: If from numpy.all import * is really too complicated, which although possible, seems a little disheartening, I suspect it would be easy enough to have a separate module that pulled everything in so that you could use from big_numpy import *. Or, to preserve backward compatibility, make numpy the unsplit namespace and expose the split namespace under a different name, let's say 'np' because that's what I already use as a numpy abbreviation. Then import np would get you just the core np functions (which I imagine we could argue about endlessly) and the various subpackages would be imported separately. 'np' is 'numpy' with some stuff removed: get it? OK, so that's a weak joke, sorry. May not be the epitome of wit, but not bad. +1 for np package being a minimalist numpy and numpy being bigger. # Steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 10:16:22AM -0700, Timothy Hochberg wrote: I prefer 'all' for this since it has the correct meaning. 'api' assuming that one can remember what it means doesn't fit. The 'all' module would not contain the api, at least not the preferred api (in my book at least), but it would contain everything. Sure, but everybody does it different. Convention are important, especially in coding. See http://ivory.idyll.org/blog/sep-07/not-sucking for a good argumentation about the point. I agree 100% with the author. Especially the conclusion. If from numpy.all import * is really too complicated, which although possible, seems a little disheartening, How much have you tried forcing Python on people who don't care at all about computers. In my work we spend maybe 2% of our time dealing with computers, and the rest struggling with electronics, optics, lasers, mechanical design... People don't want to have to learn _anything_ about computers. I am not saying they are right, I am however saying that we need to provide easy entry point, from where they can evolve and learn. I suspect it would be easy enough to have a separate module that pulled everything in so that you could use from big_numpy import *. Or, to preserve backward compatibility, make numpy the unsplit namespace and expose the split namespace under a different name, let's say 'np' because that's what I already use as a numpy abbreviation. That's the only solution I see wich would make everybody happy. IMHO the pylab option is quite nice: matplotlib is nice and modular, but pylab has it all. Use whichever you want. Now the difficulty is to find a good name for the latter module/namespace. Cheers, Ga�l ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 10:30 AM, Gael Varoquaux [EMAIL PROTECTED] wrote: On Mon, Apr 07, 2008 at 10:16:22AM -0700, Timothy Hochberg wrote: I prefer 'all' for this since it has the correct meaning. 'api' assuming that one can remember what it means doesn't fit. The 'all' module would not contain the api, at least not the preferred api (in my book at least), but it would contain everything. Sure, but everybody does it different. Convention are important, especially in coding. See http://ivory.idyll.org/blog/sep-07/not-sucking for a good argumentation about the point. I agree 100% with the author. Especially the conclusion. This is all moot since we agree below, but I don't see that the page your reference, which seem uncontroversial on a casual reading, is all that relevant. It's not that I disagree, that following convention is important where reasonable, I just don't see that this is a case where there is a convention to follow. I'm at a bit of a disadvantage since the convention in question hasn't penetrated the parts of of Python land that I inhabit (which could either imply something about my experience or about the universality of the 'api' convention, take your pick). However, I think that I vaguely recall it from back in my C-programming days, and as I recall/infer/guess the 'api' namespace is how you are supposed to use the functions in question, while the actual modules are split out for implementation purposes only. However, in numpy, that is not the case. Any splitting of the namespace would be to support a better, more organized interface, not as an implementation details. So. referring to the collected, flat namespace as 'api' would be confusing at best since it would imply that was the official approved way to access the python functions rather than one of two equivalent apis, where the flat namespace is provided primarily for beginners. If from numpy.all import * is really too complicated, which although possible, seems a little disheartening, How much have you tried forcing Python on people who don't care at all about computers. Almost none, thankfully. In my work we spend maybe 2% of our time dealing with computers, and the rest struggling with electronics, optics, lasers, mechanical design... People don't want to have to learn _anything_ about computers. I am not saying they are right, I am however saying that we need to provide easy entry point, from where they can evolve and learn. I suspect it would be easy enough to have a separate module that pulled everything in so that you could use from big_numpy import *. Or, to preserve backward compatibility, make numpy the unsplit namespace and expose the split namespace under a different name, let's say 'np' because that's what I already use as a numpy abbreviation. That's the only solution I see wich would make everybody happy. IMHO the pylab option is quite nice: matplotlib is nice and modular, but pylab has it all. Use whichever you want. Now the difficulty is to find a good name for the latter module/namespace. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion -- . __ . |-\ . . [EMAIL PROTECTED] ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Steven H. Rogers wrote: On Mon, April 7, 2008 11:16, Timothy Hochberg wrote: If from numpy.all import * is really too complicated, which although possible, seems a little disheartening, I suspect it would be easy enough to have a separate module that pulled everything in so that you could use from big_numpy import *. Or, to preserve backward compatibility, make numpy the unsplit namespace and expose the split namespace under a different name, let's say 'np' because that's what I already use as a numpy abbreviation. Then import np would get you just the core np functions (which I imagine we could argue about endlessly) and the various subpackages would be imported separately. 'np' is 'numpy' with some stuff removed: get it? OK, so that's a weak joke, sorry. May not be the epitome of wit, but not bad. +1 for np package being a minimalist numpy and numpy being bigger. # Steve ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion Hi, I think that splitting the NumPy namespace should not happen within a major release series because it would cause too many breakages. Rather it should be in a forthcoming release like the 2.0 series where it may be very feasible to have a true core functionality (NumPy), extended functionality (SciPy) and specific applications (Scikits). At the same time, Python 3K would be fully supported because it will break lots of code. It is really nice to think about having NumPy Core, NumPy Full, NumPyKits, SciPy Core, SciPy Full and SciPyKits. But splitting namespaces like core and complete brings into the problem of conflicts and how to resolve them. Regardless of the content of each, I have the suspicion that most people would just take the full versions of each eventhough most of them only use a very small fraction of NumPy (just probably different amongst users). In the past, the real distinction between Numpy and SciPy for me was the requirement of having a full Lapack installation and a Fortran compiler for SciPy. This made the current scheme very usable especially the frustrations of getting SciPy to install. Fortunately Linux and GCC Fortran has really developed over the years that these are not as big as they were although these still cause issues (especially if packages are broken). However, it remains a big concern if everything has to be built from scratch (perhaps with different compilers) or if developers continue to tell users to get the latest version from svn (problem if you used a precompiled version). Regards Bruce ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey [EMAIL PROTECTED] wrote: Hi, I think that splitting the NumPy namespace should not happen within a major release series because it would cause too many breakages. Rather it should be in a forthcoming release like the 2.0 series where it may be very feasible to have a true core functionality (NumPy), extended functionality (SciPy) and specific applications (Scikits). At the same time, Python 3K would be fully supported because it will break lots of code. I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. It is really nice to think about having NumPy Core, NumPy Full, NumPyKits, SciPy Core, SciPy Full and SciPyKits. Really? It gives me the shivers, frankly. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote: I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. +1. Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 11:29 AM, Gael Varoquaux [EMAIL PROTECTED] wrote: On Mon, Apr 07, 2008 at 11:29:41AM -0700, Robert Kern wrote: I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. +1 I also think we have a big enough proliferation of namespaces (with numpy, scipy, and scikits). -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Montag 07 April 2008, Robert Kern wrote: I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. +1. IMO, numpy has arrived at a state where there's just enough namespace clutter to allow most use cases to get by without importing much sub-namespace junk, and I think that's a good place to be (and to stay). For now, I'd be very careful about adding more. It is really nice to think about having NumPy Core, NumPy Full, NumPyKits, SciPy Core, SciPy Full and SciPyKits. Really? It gives me the shivers, frankly. Couldn't agree more. Andreas signature.asc Description: This is a digitally signed message part. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 11:02 AM, Timothy Hochberg [EMAIL PROTECTED] wrote: I'm at a bit of a disadvantage since the convention in question hasn't penetrated the parts of of Python land that I inhabit (which could either imply something about my experience or about the universality of the 'api' convention, take your pick). However, I think that I vaguely recall it from back in my C-programming days, and as I recall/infer/guess the 'api' namespace is how you are supposed to use the functions in question, while the actual modules are split out for implementation purposes only. I haven't been following how many projects have been using the api.py convention, but when I last looked about a year ago there was enthought, peak, zope, trac, etc. See this note for a bit more information: http://neuroimaging.scipy.org/neuroimaging/ni/ticket/86 Hope this helps, -- Jarrod Millman Computational Infrastructure for Research Labs 10 Giannini Hall, UC Berkeley phone: 510.643.4014 http://cirl.berkeley.edu/ ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote: On Montag 07 April 2008, Robert Kern wrote: I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. +1. IMO, numpy has arrived at a state where there's just enough namespace clutter to allow most use cases to get by without importing much sub-namespace junk, and I think that's a good place to be (and to stay). I wouldn't exactly call 494 functions just enough namespace clutter; I'd much prefer to have a clean api to work with. I certainly don't propose forcing such an api upon all users, but it should be available as an option, at least. Tim's suggestion for a separate package that pulls in a structured numpy would suit my needs. As Gael mentioned, __init__'s are cursed, otherwise we'd be able to provide numpy.* for the flat earth society (all in friendly jest ;) and numpy.api to expose a somewhat organised underlying structure. As it is, importing numpy.api would trigger the __init__ of the flat namespace as well; but I'd still be amenable to this solution since the import doesn't take long, and the organisation of the api is more important to me. Would it therefore make sense to a) Reorganise numpy to expose functionality as numpy.api.* b) Do a series of imports in numpy.__init__ which pulls in from numpy.api. This way, numpy.* would look exactly as it does now, bar the added member 'api'. Regards Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 10:16:57PM +0200, Stéfan van der Walt wrote: Would it therefore make sense to a) Reorganise numpy to expose functionality as numpy.api.* b) Do a series of imports in numpy.__init__ which pulls in from numpy.api. This way, numpy.* would look exactly as it does now, bar the added member 'api'. +1. That way you don't break compatibility, but you provide nested namespace for people interested in them. You still get the import overhead. That's too bad. With some very good engineering, you might even make it possible to ship only part of numpy for custom installations. Cheers, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
I wouldn't exactly call 494 functions just enough namespace clutter; I'd much prefer to have a clean api to work with I don't know. The 494 functions do not seem like many to me. Apparently, I tend to come down in the flat earth society although I do like some structure (after all that's why numpy has numpy.linalg and numpy.fft). I don't think this is the most pressing issue we are facing. Would it therefore make sense to a) Reorganise numpy to expose functionality as numpy.api.* b) Do a series of imports in numpy.__init__ which pulls in from numpy.api. This way, numpy.* would look exactly as it does now, bar the added member 'api'. This discussion is interesting, but it is really better suited for 1.1, isn't it? -0 on adding the .api name in 1.0.5 -Travis ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Montag 07 April 2008, Stéfan van der Walt wrote: I wouldn't exactly call 494 functions just enough namespace clutter; I'd much prefer to have a clean api to work with. Not to bicker, but... import numpy len(dir(numpy)) 494 numpy.__version__ '1.0.4' funcs = [s for s in dir(numpy) if type(getattr(numpy, s)) in [type(numpy.array), type(numpy.who)]] len(funcs) 251 classes = [s for s in dir(numpy) if type(getattr(numpy, s)) == type(numpy.ndarray)] len(classes) 88 ufuncs = [s for s in dir(numpy) if type(getattr(numpy, s)) == type(numpy.sin)] len(ufuncs) 69 (and, therefore, another 69 names of fluff) I honestly don't see much of a problem. The only things that maybe should not have been added to numpy.* are the polynomial functions and the convolution windows, conceptually. But in my book that's not big enough to even think of breaking people's code for. Andreas Proud Member of the Flat Earth Society signature.asc Description: This is a digitally signed message part. ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 07/04/2008, Travis E. Oliphant [EMAIL PROTECTED] wrote: Would it therefore make sense to a) Reorganise numpy to expose functionality as numpy.api.* b) Do a series of imports in numpy.__init__ which pulls in from numpy.api. This way, numpy.* would look exactly as it does now, bar the added member 'api'. This discussion is interesting, but it is really better suited for 1.1, isn't it? Certainly -- this suggestion is aimed at 1.1 (along with the discussion we had with Anne on API refactoring). -0 on adding the .api name in 1.0.5 Aargh, the +- zeros again! I thought we closed that ticket :) Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote: On Montag 07 April 2008, Stéfan van der Walt wrote: I wouldn't exactly call 494 functions just enough namespace clutter; I'd much prefer to have a clean api to work with. Not to bicker, but... import numpy len(dir(numpy)) 494 You'd be glad to know that that your investment increased as of r4964: 494 - 504 251 - 258 88 - 89 69 - 71 I honestly don't see much of a problem. I see at least two: a) These numbers are growing (albeit slowly) and b) numpy.TAB under IPython shows 516 completions It doesn't matter *what* these completions are -- they're still there. Sifting through 500 options isn't fun -- not for a newbie, nor a salty old sailor. I agree with Joe that the problem can be ameliorated by documentation, but I do think that an (optional) fundamental restructuring is ultimately useful. Proud Member of the Flat Earth Society :) Cheers Stéfan ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 07, 2008 at 11:21:41PM +0200, Stéfan van der Walt wrote: It doesn't matter *what* these completions are -- they're still there. Sifting through 500 options isn't fun I get more than that when I tab in an empty shell on my box. :-} Why do you expect to be able to inspect a module of the size of numpy with tab-completion. I agree that for this usecase (which is more a question of discovering/exploring the API than using it) a nested namespace is better. And as I think this usecase is valid, this is why I like the proposition of having an api submodule, with a nested namespace. My two cents, Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 3:21 PM, Stéfan van der Walt [EMAIL PROTECTED] wrote: On 07/04/2008, Andreas Klöckner [EMAIL PROTECTED] wrote: On Montag 07 April 2008, Stéfan van der Walt wrote: I wouldn't exactly call 494 functions just enough namespace clutter; I'd much prefer to have a clean api to work with. Not to bicker, but... import numpy len(dir(numpy)) 494 You'd be glad to know that that your investment increased as of r4964: 494 - 504 251 - 258 88 - 89 69 - 71 I honestly don't see much of a problem. I see at least two: a) These numbers are growing (albeit slowly) and b) numpy.TAB under IPython shows 516 completions It doesn't matter *what* these completions are -- they're still there. Sifting through 500 options isn't fun -- not for a newbie, nor a salty old sailor. I agree with Joe that the problem can be ameliorated by documentation, but I do think that an (optional) fundamental restructuring is ultimately useful. Yeah, dir needs to print in two columns ;) I think we could use an apropos sort of function that indexes the documentation, making it easier to find relevant functions. Apart from that, I think we should stop adding to the numpy namespace. Polynomials, financial functions, image processing, all that is nice to have around, but I don't think it belongs in the top level. Chuck ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Apr 7, 2008, at 2:29 PM, Robert Kern wrote: On Mon, Apr 7, 2008 at 11:19 AM, Bruce Southey [EMAIL PROTECTED] wrote: Hi, I think that splitting the NumPy namespace should not happen within a major release series because it would cause too many breakages. Rather it should be in a forthcoming release like the 2.0 series where it may be very feasible to have a true core functionality (NumPy), extended functionality (SciPy) and specific applications (Scikits). At the same time, Python 3K would be fully supported because it will break lots of code. I would prefer not to do it at all. We've just gotten people moved over from Numeric; I'd hate to break their trust again. Amen. It is really nice to think about having NumPy Core, NumPy Full, NumPyKits, SciPy Core, SciPy Full and SciPyKits. Really? It gives me the shivers, frankly. Me too. Some random comments: 1) It seems to me that the primary problem people have with a big flat namespace is that it makes the output of dir() long and unusable, and by implication, that a nice hierarchical organization would make it easier for people to find stuff. As to the latter, less so than you might think. From what I've seen, there is no generally agreed upon organization that all will agree to or find intuitive. There will always be functions that logically belong to more than one category. Ultimately, this is why flatter is better as far as that goes. If one wants to find things by category, we would be much better off tagging functions with categories and then building some dir-like tool that helps display things in that category. Some have already alluded to that (Joe Harrington I believe). The only thing namespaces solve is name collisions imho. I don't believe that the current numpy has too many names in its basic namespace, and it already has split out some things into subpackages (fft, random, linear algebra) that have such a potential. 2) Some may feel that the combination of from numpy import * with a lot of names makes it hard to see other things in your namespace. True enough. But no amount of winnowing is going to keep the namespace at a point that isn't going to overwhelm everything else. The answer is simple in that case. If that's a problem for you, don't use from numpy import *. Or perhaps another dir-like tool that filters out all numpy/scipy/pylab... items. 3) Some don't like the bloat (in disk space or download sizes) of adding things to numpy. In my case, as long as the addition doesn't make installations any more difficult I don't care. For the great majority, the current size or anything within an order of magnitude is not an important issue. For the 56Kb modem people, perhaps we can construct a numpy-lite, but it shouldn't be the standard distribution. I don't mind the financial functions going into numpy. I think it's a good idea since a lot of people may find that very handy to be part of the core distribution, probably many more than worry about more exotic packages, and likely many more than care about fft, random and linear algebra. 4) The api interface is perhaps a good idea, but as Travis mentions can be deferred. But I don't think I would need it. (see 1) Perry ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
3) Some don't like the bloat (in disk space or download sizes) of adding things to numpy. In my case, as long as the addition doesn't make installations any more difficult I don't care. For the great majority, the current size or anything within an order of magnitude is not an important issue. For the 56Kb modem people, perhaps we can construct a numpy-lite, but it shouldn't be the standard distribution. I don't mind the financial functions going into numpy. I think it's a good idea since a lot of people may find that very handy to be part of the core distribution, probably many more than worry about more exotic packages, and likely many more than care about fft, random and linear algebra. The only problem is that if we keep adding things to numpy that could be in scipy, it will _never_ be clear to users where they can expect to find things. It is already bad enough. How do I explain to a user/student/scientist that ffts and linear algebra are in numpy, but that integration and interpolation are in scipy. That doesn't make any sense to them. Oh but wait, linear algebra and ffts are also in scipy! Random numbers - take a guess - wrong, they are in numpy. As far as I am concerned, financial fucntions are completely outside the conceptual scope that numpy has established = arrays, fft, linalg, random. In fact, they are far outside it. Simply putting things into numpy because of convenience (numpy is easier to install) only encourages people to never install or use scipy. If scipy that much of a pain to install and use - we should spend our time improving scipy. Cheers, Brian ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Apr 7, 2008, at 5:54 PM, Brian Granger wrote: The only problem is that if we keep adding things to numpy that could be in scipy, it will _never_ be clear to users where they can expect to find things. It is already bad enough. How do I explain to a user/student/scientist that ffts and linear algebra are in numpy, but that integration and interpolation are in scipy. That doesn't make any sense to them. Oh but wait, linear algebra and ffts are also in scipy! Random numbers - take a guess - wrong, they are in numpy. As far as I am concerned, financial fucntions are completely outside the conceptual scope that numpy has established = arrays, fft, linalg, random. In fact, they are far outside it. Simply putting things into numpy because of convenience (numpy is easier to install) only encourages people to never install or use scipy. If scipy that much of a pain to install and use - we should spend our time improving scipy. Cheers, Brian To me, the biggest characteristic difference between the two is the ease of installation. If installation weren't an issue, I would tell everyone to use scipy and then the confusion would be ended. But the installation issue is not trivial one to solve (if it were, we'd already be there). But a nice ideal is that the numpy namespace should map directly into scipy's so that if I expected numpy.xxx to work, the scipy.xxx should also work. That would lessen the confusion of finding things. If it isn't in numpy, it's in scipy. But otherwise one is a subset of the other. (I say this from complete ignorance, I'm not sure what prevents this, and there may be very good reasons why this can't be done). Perry ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Mon, Apr 7, 2008 at 4:03 PM, Perry Greenfield [EMAIL PROTECTED] wrote: On Apr 7, 2008, at 5:54 PM, Brian Granger wrote: The only problem is that if we keep adding things to numpy that could be in scipy, it will _never_ be clear to users where they can expect to find things. It is already bad enough. How do I explain to a user/student/scientist that ffts and linear algebra are in numpy, but that integration and interpolation are in scipy. That doesn't make any sense to them. Oh but wait, linear algebra and ffts are also in scipy! Random numbers - take a guess - wrong, they are in numpy. As far as I am concerned, financial fucntions are completely outside the conceptual scope that numpy has established = arrays, fft, linalg, random. In fact, they are far outside it. Simply putting things into numpy because of convenience (numpy is easier to install) only encourages people to never install or use scipy. If scipy that much of a pain to install and use - we should spend our time improving scipy. Cheers, Brian To me, the biggest characteristic difference between the two is the ease of installation. If installation weren't an issue, I would tell everyone to use scipy and then the confusion would be ended. But the installation issue is not trivial one to solve (if it were, we'd already be there). I definitely understand the installation issue. Is the main thing people run into the fortran compiler, BLAS and LAPACK? To me it seems like the scipy install is pretty simple these days. Do we need better installation documentation? Deep down I so wish we could ditch fortran! In almost all cases I know of projects that have fortran involved are the worse for it. But a nice ideal is that the numpy namespace should map directly into scipy's so that if I expected numpy.xxx to work, the scipy.xxx should also work. That would lessen the confusion of finding things. If it isn't in numpy, it's in scipy. But otherwise one is a subset of the other. (I say this from complete ignorance, I'm not sure what prevents this, and there may be very good reasons why this can't be done). I think this is a very good idea to follow, at least for things that do happen to in both places. But, I still don't think it we should have many things that are in both places. Brian Perry ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
+1 (and s/students/colleagues).
Surely you mean:
s.replace('students', colleagues')
!
Matthew
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
Every once in a while the issue of how to split things into packages comes up. In '04, I think, we had such a discussion regarding scipy (with Numeric as its base at the time). One idea was a core-plus-many-modules approach. We could then have metapackages that just consisted of dependencies and would draw in the packages that were needed for a given application. A user would install just one metapackage (one of which would install every package), or could roll their own. Then Travis took as much of scipy as was reasonable to maintain at once, took a chunk of numarray, and made numpy. Numpy is now a bit more than what I would have thought of as core functionality. One might consider trimming Travis's collection and moving many of the functions out to add-ons in scipy. The question is where to draw the line in the sand with regard to where a given function belongs, and the problem is that the line is very hard to draw in a way that pleases many people and mortally offends very few. Certainly lots of content areas would straddle the divide and require both a package in scipy and representation in the core. I would think of core functionality as what is now the ndarray class (including all slicing and broadcasting); things to make and index arrays like array, zeros, ones, where and some truth tests; the most elementary math functions, such as add, subtract, multiply, divide, power, sin, cos, tan, asin, acos, atan, log, log10; sum, mean, median, standard deviaton; the constants pi, e, NaN, Inf, -Inf; a few simple file I/O functions including loadtxt, and not a whole lot else. This is an incomplete list but you get the idea. Everything else would be in optional packages, possiby broken down by topic. Now ask yourself, what would you add to this to make your core? Would you take anything out? And the kicker: do you really think much of the community would agree with any one of our lists, including mine? Almost all such very-light collections would require users to load additional packages. For example, complex things like FFTs and random numbers would not belong in the core outlined above, nor would linear algebra, masked arrays, fitting, random numbers, most stats, or financial functions. There is one division that does make sense, and that would be to distribute ONLY ndarray as the core, and have NO basic math functions, etc., in the core. Then you have to load something, a lot of things, to make it useful, but you don't have the question of what should be in which package. But ndarray is already a stand-alone item. At that point you have to ask, if the core is so small that *everyone* has to load an add-on, what's the point of making the division? You can argue that it's easier maintenance-wise, but I'm not certain that having many packages to build, test, and distribute is easier. Travis already made a decision based on maintenance, and it seems to be working. That brings us to the motivation for dividing in the first place. I think people like the idea because we're all scientists and we like to categorize things. We like neat little packages. But we're not thinking about the implications for the code we'd actually write. Wouldn't you rather do: import numpy as N ... c = (N.sin(b) + N.exp(d)) / N.mean(g) rather than: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S ... c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g) ? In the latter example, you start N.whatevering yourself to death, and it is harder to learn because you have to remember what little container each function is in and what you happened to name the container when you loaded it. Code is also harder to read as the N.whatevers distract from the sense of the equation. Lines start to lengthen. Sure, you can do: from whatever import functionlist to pull the functions into your top-level namespace, but do you really want to, in effect, declare every function you ever call? The whole point of array languages is to get rid of mechanics like function declarations so you can focus on programming, not housekeeping. As I've emphasized before, finding the function you want is a documentation problem, not a packaging problem. We're working on that. Anne's function index on the web site is an excellent start, and there will be much more done this summer. Though I didn't initially agree with it, I now think Travis's line in the sand is a pretty good one. Numpy is enough so many people don't have to go to scipy most of the time. It's being maintained well and released reasonably often. The problems of the rest of scipy are not holding back the core anymore. Installing today at a tiny 10 MB, numpy could easily stand to grow by adding small functions that are broadly used, without making it unwieldy for even the constrained space of OLPC. Let's think good and hard before we introduce more divisions into the namespace. --jh--
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Fri, 04 Apr 2008, Joe Harrington wrote: Wouldn't you rather do: import numpy as N ... c = (N.sin(b) + N.exp(d)) / N.mean(g) rather than: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S ... c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g) I try to think of my students in such an environment. Frightening. Alan Isaac ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] packaging scipy (was Re: Simple financial functions for NumPy)
On Fri, Apr 04, 2008 at 04:29:03PM -0400, Alan Isaac wrote: import numpy as N import numpy.math as N.M import numpy.trig as N.T import numpy.stat as N.S ... c = (N.T.sin(b) + N.M.exp(d)) / N.S.mean(g) I try to think of my students in such an environment. Frightening. +1 (and s/students/colleagues). Gaël ___ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
