[Numpy-discussion] Trying out Numeric3
Michiel Jan Laurens de Hoon
mdehoon at ims.u-tokyo.ac.jp
Thu Mar 24 18:51:10 EST 2005
While I basically agree with your setup, I think that there is no need to call
it scipylite. Sticking to the Numeric structure and names is to the advantage of
both current SciPy and current Numerical Python users. The advantage to current
Numerical Python users is obvious -- and there are many more of them than of
SciPy users. For SciPy users, it is in their best interest that as many people
as possible go over to Numeric3, in order to avoid another split in the Numerics
community. Now, if I talk with the other pygist or biopython developers and tell
them there is a new Numerical Python package which solves some of the issues
with the older versions, I have a good chance to convince them to update
pygist/biopython to the Numeric3 API. If I tell them that there is a scipylite
package that intends to replace Numerical Python: Forget it. It will be ignored.
You may not care about pygist or biopython in particular, but developers of
other packages will make the same consideration, so you may end up with some
numerical / graphics packages working with scipylite and others with Numerical
Python 23.8. It's better to get everybody on board.
Secondly, we have confused users more than enough with the Numerical Python /
numarray / Numeric3 split. We should not add one more new name to the equation.
Third, there is lots of code out there that imports LinearAlgebra or RandomArray
etcetera. Why force our users to go through the trouble of changing those
imports? I don't see the benefit to the users.
Finally, the word scipylite has no meaning. As SciPy evolves into a website
where scientific software for Python can be downloaded, there will not be a
scipy-full nor a scipy-lite.
--Michiel.
Travis Oliphant wrote:
> Putting the parts of scipy_base together is a good idea. Exactly how
> to structure this is going to require some thought and need to be
> coordinated with current scipy.
>
> I want a package that is as easy to install as current Numeric (so the
> default will have something like lapack_lite).
> But, this should not handicap nor ignore a speed-conscious user who
> wants to install ATLAS or take advantage of vendor-supplied libraries.
>
> There should be a way to replace functionality that is clean and does
> not require editing setup.py files.
>
> Anybody with good ideas about how to do this well is welcome to speak up.
> Perhaps, the easiest thing to do is to keep the basic Numeric structure
> (with C-based easy-to-install additions) and call it scipylite (with
> backwards compatibility provided for Numeric, LinearAlgebra,
> RandomArray, and MLab names). This also installs the namespace scipy
> which has a little intelligence in it to determine if you have altas and
> fortran capabilities installed or not.
>
> Then, provide a scipyatlas package that can be installed to take
> advantage of atlas and vendor-supplied lapack/blas.
>
> Then, a scipyfortran package that can be installed if you have a fortran
> compiler which provides the functionality provided by fortran libraries.
> So, there are three divisions here.
> Feedback and criticisms encouraged and welcomed.....
--
Michiel de Hoon, Assistant Professor
University of Tokyo, Institute of Medical Science
Human Genome Center
4-6-1 Shirokane-dai, Minato-ku
Tokyo 108-8639
Japan
http://bonsai.ims.u-tokyo.ac.jp/~mdehoon
More information about the NumPy-Discussion
mailing list