[Numpy-discussion] Trying out Numeric3

[Michiel Jan Laurens de Hoon]

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