Sven Schreiber wrote: > So, to put it "pointedly" (if that's the right word...?): > Numpy should not get small functions from scipy -> because the size of > scipy doesn't matter -> because scipy's modules will be installable as > add-ons separately (and because there will be ready-to-use installers); > however, nobody knows how to actually do that in practice ?
> I just want to make the point (as usual) > that this way numpy is going to be a good library for other software > projects, but not super-attractive for direct users (aka "matlab > converts" No one is denying that there is still work to do. I also think there are a lot of us (from "just users" to the major contributers), that WOULD like to see an easy to install package that can do everything (and more, and better) that MATLAB can. The only questions are: A) How best to accomplish this (or work toward it anyway)? B) Who's going to do the work? As for (A), I think the consensus is pretty clear -- keep numpy focused on the basic array package, with some extras for backwards compatibility, and work towards a SciPy that has all the bells and whistles, preferably installable as separate packages (like Matlab "toolboxes" I suppose). As for the above comments, if we are looking at the "Matlab converts", or more to the point, people looking for a comprehensive scientific/engineering computation package: -- "The size of SciPy doesn't matter" -- True, after all, how big is MATLAB? -- "Scipy's modules will be installable as add-ons separately" -- this is a good goal, and I think there has been progress there. -- "Nobody knows how to actually do that in practice" -- well, it's not so much that nobody knows how to do it, as that nobody has done it -- it's going to take work, but adding extra stuff to numpy takes work too, it's a matter of where you're going to focus the work. Given the size of disk drives and the speed of Internet connections these days, I'm not sure it's that important to have the "core" part of SciPy very small -- but it does need to have easy installers. That approach provides opportunity though -- breaking SciPy down into smaller packages requires expertise and consensus among the developers. However, building an installer requires only one person to take the time to do it. Yes, SciPy is too hard to build and install for an average newbie -- but it's gotten better, and it's not too hard for a savvy user that is willing to put some time it. The kind of person who is willing to put the time in to post to discussions on this group, for instance. Please, rather than complaining that core developers aren't putting your personally desired "small function" into numpy , just take the time to build the installer you need -- we need one for OS-X, build it and put it up on pythonmac -- it's not that hard, and there are a lot of people here and on the scipy and python-mac lists that will help. Now my rant: Please, please, please, could at least a few of the people that build packages take the time to make a simple installer for them and put them up on the web somewhere? Now a question: One of the key difficulties to building SciPy is that parts of it depend on Fortran and LAPACK. We'd all like LAPACK to be built to support our particular hardware for best performance. However, would it be that hard to have Scipy build by default with generic LAPACK (kind of like numpy), and put installers built that way up on the web, along with instructions for those that want to re-build and optimize? For that matter, is it possible (let's say on Windows) to deliver SciPy with a set of multiple dlls for LAPACK/BLAS, and have the appropriate ones chosen at install or run time? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (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
