[SciPy-dev] Renaming scipy_core ???

[Ed Schofield]

On 01/01/2006, at 11:58 PM, Fernando Perez wrote:

> Travis Oliphant wrote:
>
>> sci (arrlab, scicore)/
>
> I'm +0.5 on scicore: I think it emphasizes the fact that this  
> constitutes the
> necessary core functionality for scipy, without any of the current  
> confusion
> problems.  The following is a little experiment, to see how a blurb  
> would read
> (remove the weave reference as needed).  Feel free to s/scicore/ 
> your_favorite/
> to see how it would read:
>
> """scicore is a package for array-based numerical computing in Python.
>
> It provides a collection of modules useful for a wide variety of  
> numerical
> tasks, similar in spirit to the basic functionality of systems such  
> as Matlab
> or IDL.  At its center is a flexible array type which can be very  
> useful even
> for non-scientific tasks that interface with arrays in C libraries.
>
> The scicore package consists of:
>
>    - ndarray: a package exposing a flexible datatype to efficiently  
> manipulate
> n-dimensional arrays.  Such objects are implemented as C extensions  
> and
> support array element-wise arithmetic and other mathematical  
> operations.
> While they are conceptually similar to the arrays of languages like  
> Fortran90,
> they are in fact much more capable objects, as their contents can  
> consist of
> arbitrary python objects and they have very rich indexing, data  
> access and
> low-level maninpulation capabilities.
>
>    - f2py: ...
>
>
> The scicore package can be installed on any standard python  
> distribution, and
> it has no other dependencies for installation than Python itself  
> (and a C
> compiler for a source-based install, as there is extension code in  
> it).  At
> runtime, some of its components do require the presence of  
> compilers (f2py
> needs a Fortran compiler, while weave needs a C++ one), but these  
> are not
> needed unless you explicitly import and use f2py or weave.
>
>
> The scipy package builds on top of scicore, to expose a large  
> collection of
> algorithms and libraries for many tasks in scientific computing.   
> scipy wraps
> many well-known and field-tested Fortran and C libraries, as well  
> as providing
>   new routines written both in C and in Python.
> """
>
> Just a little experiment in language :)
>
>> ->numpy (ndarray, narray)/
>
> -1 on 'numpy': if at some point in the future this is considered a  
> candidate
> for the stdlib, I don't think we want anything with a 'py' suffix  
> in the
> package name (not a single module in the stdlib ends in 'py' today,  
> except for
> 'copy').
>
> I also don't want to have to explain to anybody "well, this isn't  
> really the
> old numpy, it's the new numpy, which was written by the guy who was
> maintaining the old numpy, but it's a new code, and it also has  
> features from
> numarray, so it's like the old numpy + numarray + better, but it's  
> called
> numpy again.  Easy, no?"  Really, I don't.
>
> +1 on 'ndarray', because it emphasizes the fact that these are  
> generic,
> very flexible (esp. with all the recent enhancements) N-dimensional  
> data
> structures.  In that sense, 'narray' has a stronger hint of 'n for  
> numbers',
> while Travis has shown that these objects can be much more than  
> traditional
> Fortran-type arrays.
>
> I also think ndarray goes well as an extension to the 'array'  
> module in the
> stdlib.  They are, after all, conceptually close.
>

I'm with Fernando on this, for all the same reasons. So:
+1 on 'ndarray' for the basic array module.
+1 on 'scicore' for the whole package.

And ...
+1 on moving weave to scipy, to keep scicore lean and mean ;)


-- Ed