[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?
-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
Chris.Barker at noaa.gov
More information about the Numpy-discussion
mailing list