This page is created for developers to share their experiences in transitioning their projects from Numeric/NumArray to !NumPy.


= !SciPy =
[http://www.scipy.org/ SciPy] is a '''large''' collection of toolboxes to give more number-crunching capability to Python with !NumPy.  Converting it to use !NumPy intead of Numeric was accomplished in a relatively short time.   Part of this was due to the fact that !SciPy relies heavily on f2py and so once f2py was working for !NumPy, then !SciPy could work.  But, this was not the whole story.  There are still many hand-written C-modules and a large number of Python modules that were using Numeric-specific ideas that had to be converted.   

The convertcode script was used for all of the Python modules and that proved its worth.  There was some hand-editing that still had to be done because the typecode-character conversions also tried to convert legitimate uses of the 'c' string (used in determining which Fortran data-type to select) to 'S1'.  This experience led to disabling of that conversion in convert code.   

There were several C modules that used the function pointers in the old Numeric PyArray_Descr structure.  These all had to be changed by hand.   The numpyio module and the signaltoolsmodule where the most difficult to change as they had made the most use of the old C-structures in Numeric.  

= RPy =

[http://rpy.sourceforge.net/ RPy] is a very simple, yet robust,
Python interface to the [http://www.r-project.org/ R Programming Language].

Before transition to !NumPy, RPy was designed to interoperate with Numeric. 

Transition was fairly straighforward.  The only trick worth mentioning is that the transition required to define PY_ARRAY_TYPES_PREFIX to avoid conflict between R and !NumPy headers.

A patch implementing !NumPy support for RPy release 0.4.6 is available from  [http://sourceforge.net/tracker/download.php?group_id=48422&atid=453023&file_id=165339&aid=1417834 sourceforge] or [attachment:"rpy-0.4.6-both-patch.txt" here].
Patched RPy will try to use !NumPy first and will fall back to Numeric in !NumPy is not installed. 

R.py - an alternative approach to R<->Python interface is available in the from the [https://svn.sourceforge.net/svnroot/rpy/trunk/sandbox/ RPy sandbox].  In r.py R objects are first class Python objects that support {{{__array_struct__}}} interface.  This allows creation of ndarrays that share data with R.

= Numeric =

Rather than converting all at once, I lived for a while with a mixed Numeric/Numpy/Numarray environment.
The attached module (NumNumericNumpy) makes that much easier:  it gives you something close to backwards
compatibility for old Numeric applications, with minimal modifications.

If you replace references to {{{LinearAlgebra}}} with {{{Num.LA}}}, {{{RandomArray}}} with {{{Num.RA}}}, {{{FFT}}} with {{{Num.FFT}}},
and import the Num module instead of {{{Numeric}}}, {{{LinearAlgebra}}}, {{{RandomArray}}} and {{{FFT}}},
then many simple applications will run on both {{{Numpy}}} and {{{Numeric}}}.

There are several traps, though.  The default arguments for {{{Num.sum}}}, {{{Num.prod}}}, differ,
so you need to explicity specify {{{axis=0}}}, instead of relying on the default.   {{{numpy.nonzero}}}
has a different return value, which needs to be dealt with by hand, or by enhancing {{{Num.py}}}.
Note that this is merely a compatibility/porting aid, not a complete solution.