oliphant at ee.byu.edu
Fri Feb 4 11:20:44 CST 2005
konrad.hinsen at laposte.net wrote:
> On 04.02.2005, at 05:14, Michiel Jan Laurens de Hoon wrote:
>> give you an example from my own field (computational biology). I am
>> one of the maintainers of Biopython, which uses LinearAlgebra and
>> RandomArray. Many of our users are not very familiar with Python.
>> Even installing Numerical Python sometimes causes problems, and I'm
>> sure we have lost users in the past because of that. SciPy, in my
> My experience with users of MMTK, nMOLDYN, and DomainFinder is
> exactly the same. Installationproblems are the #1 source for support
> questions, in particular under Windows and Irix.
O.K. I can see that there are several out there who belive that SciPy
is sufficiently hard to install that they are concerned about requiring
it for their math-using packages (despite the provided binary
distributions, and the work that continues on making it easier to
install). I'm very glad to hear these comments, as I constantly wonder
why people seem to be duplicating SciPy's efforts instead of helping
SciPy. I really would like to help make SciPy into something that many
people can use. We have done a lot of work in trying to make SciPy
modular, just for this reason.
While I can appreciate that installation issues are a major headache
(one reason I support the idea of selling binary-only copies to
customers), I think that this is an issue no matter what packages you
decide to deliver, so I don't think it negates my comments that we
should package numeric routines under the same framework (right now,
since SciPy already exists, why not there?)
I'm glad to hear at least one specific regarding installation, and that
is the use of FORTRAN code in SciPy. I would be very interested to
know which platforms people have installation difficulties caused by the
use of FORTRAN. The biggest problem, I see, is not using FORTRAN, but
trying to support all the different FORTRAN compilers that might get
used. Pearu has done a magnificient job in this difficult area,
I very much want to get at the root of why people are staying aloof from
SciPy, and fix the problems if we can. SciPy is very much an open
project. It is what it is because of the people involved. Those of us
developing it so far are pretty easy going and are willing to make
changes to make others more satisfied with the result.
>> So I would suggest the following demarcation line between Numerical
>> Python and SciPy:
>> Stuff that is needed by lots of users (linear algebra, FFT, random
>> numbers, special functions) and is available in ANSI-C (so its
>> installation is straightforward and won't cause problems to users
>> who don't need it) should go into Numerical Python.
If this is an important distinction, why not just place this division in
SciPy itself? SciPy's goal is not to be "hard to install", or "only
for power users." If these installation issues are real and cannot be
fixed with better installers, then those of us at SciPy would be very
glad to see an "easy-to-install" scipy sub-package, that fits into a
In other words, why aren't you helping make SciPy better, instead of
just re-creating what it is doing. Are you really saying that "scipy is
beyond hope for me to help?" Even if you can't get in and change
SciPy, offering concrete suggestions such as the one just offered
"FORTRAN code is too hard to install and so there should be subset of
SciPy in ANSI-C only" is great. Then, we can discuss this issue,
really get to the root of it, and fix the problem.
It would appear that so few actually want to do that. I actually
understand, because it sometimes means giving up a treasured notion that
doesn't fit into the picture, and this happens to me over and over
again. Perhaps it is unavoidable.
In sum, I would prefer to see people rally behind SciPy and fix it to be
a package (or collection of packages) that all can use. If that doesn't
happen, I certainly won't fight people who want to make Numeric Packages
instead. It just will not be a high priority for me and so won't
appear in my workflow.
More information about the Numpy-discussion