[Numpy-discussion] Trying out Numeric3
Colin J. Williams
cjw at sympatico.ca
Thu Mar 24 19:20:46 CST 2005
Michiel Jan Laurens de Hoon wrote:
> 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.
It looks to me as though getting numarray/Numeric sorted out, and
getting it right, will be sufficient work for now. It's far better to
concentrate the limited resources on that and to leave the complexities
of SciPy for another day.
I wonder about introducing another distribution system (SVN?) when some
of us have barely mastered CVS.
> 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
>> So, there are three divisions here.
>> Feedback and criticisms encouraged and welcomed.....
More information about the Numpy-discussion