[Numpy-discussion] Newbie Question, Probability

Christopher Barker Chris.Barker at noaa.gov
Fri Dec 22 11:08:59 CST 2006

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?


Christopher Barker, Ph.D.

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

Chris.Barker at noaa.gov

More information about the Numpy-discussion mailing list