Converting from NUMARRAY to NUMPY

Christopher Hanley - chanley@stsci.edu 6th April 2007

Contents

1 Introduction 2 What is NUMPY?

2.1 Why Should I Convert to NUMPY? . . . . . . . . . . . . . . .

3 4
5

3 How Do I Convert My Code?

3.1 Writing Native NUMPY Code . . . . . . . . . . . . . . . . . . 3.1.1 3.1.2 3.1.3 3.1.4 3.2 3.3 3.4 3.5 Syntax Dierences Behavior Dierences The "dtype" Object Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6
6 6 9 14 16 17 19 19 19

. . . . . . . . . . . . . . . . . . . . . . . .

NUMPY's NUMARRAY Python-API . . . . . . . . . . . . . . NUMPY's NUMARRAY C-API . . . . . . . . . . . . . . . . . NUMPY's C-API . . . . . . . . . . . . . . . . . . . . . . . . . Conversion Tools . . . . . . . . . . . . . . . . . . . . . . . . .

4 What Happened To NUMARRAY's External Packages nd_image, image, and convolve? 21 5 Bug or Feature?
5.1 The recarry Module and the Zero Repeat Count . . . . . . . .

22
22

6 The Future 7 References

24 25

Introduction

This document is an attempt to explain to Python developers using the NUMARRAY array package ways to replace it with the NUMPY array package. This document is being targeted at experienced Python developers whose NUMARRAY experience ranges from a supercial usage to heavy duty sub-classing of NUMARRAY internals. Much of this material it taken from my experience porting the PyFITS module, participating in the numpydiscussion@scipy.org mailing list, and Travis Oliphant's Guide to Numpy. My goal in writing this text is that other developers will be able to avoid many of the pitfalls that I have encountered in making the transition. What this document is not is an exhaustive discussion of either NUMARRAY or NUMPY. There are far better resources for learning how to write code with those packages available elsewhere. NUMARRAY resources are available at http://www.stsci.edu/resources/software_hardware/numarray. The best place to start learning more about NUMPY is at http://www.scipy.org. All comparisons in this document are between NUMARRAY version 1.5.2 and version 1.0.2 of NUMPY.

What is NUMPY?

"The fundamental package needed for scientic computing with Python is called NumPy"(http://www.scipy.org/numpy). C-based Python module which contains: The NUMPY package is a

An N-dimensional array object. A collection of fast math functions. Basic linear algebra support. Basic Fourier Transform support. Random number capabilities. Tools for integrating C/C++ and FORTRAN code. A data-type object used to interpret memory blocks that make up array elements. Array scalars. A Matrix object. A character array object for string manipulation. This is equivalent to NUMARRAY's "strings" module. A record array object. A memory-mapped object. Compatibility layers for Numeric and NUMARRAY code. cludes full C-API support. Tools for converting Numeric and NUMARRAY code to NUMPY. This in-

NUMPY is an attempt by Travis Oliphant and the NUMPY developers to bring together the Numeric and NUMARRAY communities. NUMPY was created by rewriting Numeric to include the features of NUMARRAY.

2.1

Why Should I Convert to NUMPY?

The simplest reason to convert your code from NUMARRAY to NUMPY is because some time in 2007 the Space Telescope Science Institute will cease all support of NUMARRAY as a package. xes or enhancements will be made. There are a number of advantages to NUMPY that must not be overlooked. These advantages include: 1. Performance. Most of NUMPY is written in pure C instead of Python. This leads to faster execution times than NUMARRAY for most operations. 2. Broad community support. Since NUMPY is the unication of Numeric and NUMARRAY these two communities have joined forces to make NUMPY a success. Active discussions of NUMPY occur hourly on the "numpy-discussion.sourceforge.net" mailing list. 3. Object arrays. NUMPY provides native support for objects arrays. This means no additional bug

This allows the developer to create recarray-like arrays without requiring the recarray class interface. 4. 64-bit addressing. NUMPY provides support for 64-bit addressing

when used with Python 2.5 on a 64-bit processor using 64-bit libraries. This allows arrays to be created the exceed the 2 gigabyte memory limit that is imposed on arrays on a 32-bit platform. does not and will not support 64-bit addressing. NUMARRAY

How Do I Convert My Code?

There are a variety of methods available for converting your existing NUMARRAY code to NUMPY. The method you choose and the diculty of the conversion depend upon how closely tied your existing code is to the internal structures of NUMARRAY. The possible modes of code conversion range from manually changing your code to NUMPY syntax to using automated conversion tools. We will review your options in this section.

3.1

Writing Native NUMPY Code

If you have very complicated code that you wish to be maintainable far into the future the best thing you can do is re-write your code using NUMPY syntax. Re-writing your code manually is required if your code is tied to NUMARRAY private methods and attributes or other internal structures. Although for the most part NUMARRAY and NUMPY syntax and behavior are very similar, the dierences need to be emphasized. Let us examine some of the major dierences in more detail.

3.1.1 Syntax Dierences

We will begin our discussion on converting your code to NUMPY by starting with a the most common syntax conversions from NUMARRAY to NUMPY. The rst type of changes we will look at are import changes, class name, and module name dierences.

NUMARRAY
import numarray from numarray import records records.RecArray records.Record from numarray import strings strings.CharArray from numarray.memmap import Memmap from numarray import linear_algebra import numarray.ieeespecial

NUMPY
import numpy from numpy import rec rec.recarray rec.record from numpy import char char.chararray

from numpy import memmap; memmap.memmap from numpy import linalg import numpy

You will notice that the records module is known as rec and the strings module is know as char. These modules were added to NUMPY for the express purpose of allowing NUMARRAY users an easier time transitioning their code. Aside from the class names now being all lower case all of the NUMARRAY helper functions and class methods are replicated in the NUMPY versions of the modules. Another feature of note is the fact that the functions that previously were part of the ieeespecial module in numarray are now part of the NUMPY namespace by default. The next change we will look at are the data type descriptors.

NUMARRAY
numarray.Bool numarray.UInt8 numarray.UInt16 numarray.UInt32 numarray.UIntXX numarray.int8 numarray.int16 numarray.intXX numarray.oat32 numarray.oatXX numarray.Complex64 numarray.ComplexXXX

NUMPY
numpy.bool_ numpy.uint8 numpy.uint16 numpy.uint32 numpy.uintX numpy.int8 numpy.int16 numpy.intXX numpy.oat32 numpy.oatXX numpy.complex128 numpy.complexXXX

You will notice in this partial list of NUMPY data types that the primary dierences are that the data type names are all lowercase in NUMPY. However, there are a few other items of note. First, in NUMPY data type names that end in an  _ represent enhances-scalars and are very similar to the standard Python types. In fact, these enhanced-scalars inherit from the standard Python types. These types can be used in place of the Python types in your code. The complex types appear to dier by a factor of two in bit size between NUMARRAY and NUMPY. This dierence is due to the naming convention used. In NUMARRAY, the bit width given represents the size of either the real or imaginary parts. So for numarray.Complex64 the real part has a size of 64 bits and the imaginary part has a size of 64 bits for a total of 128 bits.

In NUMPY, the size given represents the size of the real and imaginary parts. So, in NUMPY an array of data type numpy.complex128 will also have a real part of 64 bits in size and and imaginary part of 64 bits in size. The NUMPY data type name represents the total size of an element of the array. One critical dierence is between the numarray.Bool and the numpy.bool_. In NUMARRAY there is not a true boolean data type. A boolean array in NUMARRAY is represented by eight bit unsigned integers. The NUMPY This boolean is an enhanced version of the Python boolean data dtype.

means that you cannot assume that the same data coercion rules apply with NUMPY boolean arrays as apply for NUMARRAY boolean arrays. We will next provide a listing of ufunc and object method and attribute name changes.

NUMARRAY .imaginary .at .byteswaped() .byteswap() .isaligned() .isbyteswaped() .iscontiguous() .is_c_array() .is_fortran_contiguous() .is_f_array() .itemsize() .nelements() .repeat( r ) .size() .type() .typecode() .stddev() .getshape() .setshape( obj ) .getat()

NUMPY .imag .ravel .byteswap( False ) .byteswap( True ) - Reutrns self instead of None .ags.aligned not .dtype.isnative .ags.c_contiguous .ags.carray .ags.f_contiguous .ags.farray .itemsize .size .repat( r, axis=0 ) .size .dtype.name .dtype.char .std() .shape .shape = obj .ravel

.getreal() .setreal( obj ) .getimag() .setimag( obj ) .getimaginary() .setimaginary( obj )

.real .real = obj .imag .imag = obj .imag .imag = obj

The biggest dierences are in how some NUMARRAY object methods have become object attributes in NUMPY. One special item of note; although there is a .at in NUMPY its behavior is not equivalent to NUMARRAY's. The NUMPY .at method is an iterator object. One nal item of note. Users of the 't' module will discover that For example, the numarall of the function names have been shortened.

ray.t.inverse_real_t function in NUMARRAY corresponds to the numpy.t.iret function in NUMPY. Despite the name changes the underline C code is identical. Even the help is identical for t functions in each array package. Although these lists of syntax changes are not exhaustive, they give you an idea of the style of the changes being made. The hope is that this will allow you to more easily nd the mapping between the NUMARRAY functions, methods, and attributes you use and those in NUMPY.

3.1.2 Behavior Dierences

Probably more import than the syntax dierences are the behavior dierences between NUMARRAY and NUMPY. The rst behavior dierence we will examine is the extraction of a elements from an array. In NUMARRAY extracted elements are converted to Python scalar types. For NUMPY, the elements are actually scalar arrays that retain the NUMPY data type. The normal array coercion rules still apply. This means that overow can occur.

> > > import numarray > > > a = numarray.array([1,2],dtype=numarray.UInt16) > > > b = a[0] - a[1] > > > print b -1 > > > import numpy > > > a = numpy.array([1,2],dtype=numpy.uint16) > > > b = a[0] - a[1] Warning: overow encountered in ushort_scalars > > > print b 65535 >>> Another notable dierence is the fact that the functions array, fromle, arange, and fromstring do not have a shape parameter. A user will need to create an array and then use the reshape method to get the desired shape. > > > import numarray > > > a = numarray.array([1,2,3,4],dtype=numarray.Int32,shape=(2,2)) > > > print a [[1 2] [3 4]] >>> > > > import numpy > > > a = numpy.array([1,2,3,4],dtype=numpy.int32,shape=(2,2)) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: 'shape' is an invalid keyword argument for this function > > > a = numpy.array([1,2,3,4],dtype=numpy.int32) > > > print a [1 2 3 4] > > > a = a.reshape((2,2)) > > > print a [[1 2] [3 4]] Many interactive Python users may be surprised that they are unable to add attributes to existing ndarray objects. This occurs because NUMPY ndarrays lack the  __dict__ that NUMARRAY arrays contain. We can

10

illustrate this dierence with the following example: > > > import numarray as na > > > a = na.array([1,2,3,4]) > > > a.joe = 4 > > > a.joe 4 > > > import numpy as np > > > a = np.array([1,2,3,4]) > > > a.joe=4 Traceback (most recent call last): File "<stdin>", line 1, in ? AttributeError: 'numpy.ndarray' object has no attribute 'joe' >>> NUMPY users will nd that the only way to add attributes to an ndarray is through sub-classing. We will discuss sub-classing the ndarray in the section on inheritance. Also, for those who routinely created empty arrays using the array factory function will encounter the following cryptic error message: > > > a = numpy.array(dtype=n.oat64) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: function takes at least 1 argument (0 given) You can no longer create an empty array in this way. Now you must use the empty() factory function is the same way one use zeros() or ones(). The following example illustrates this usage: > > > a = numpy.empty((100,100),dtype=numpy.oat64) >>> a array([[ 0., 0., 0., ..., 0., 0., 0.], [ 0., 0., 0., ..., 0., 0., 0.], [ 0., 0., 0., ..., 0., 0., 0.], ..., [ 0., 0., 0., ..., 0., 0., 0.], [ 0., 0., 0., ..., 0., 0., 0.], [ 0., 0., 0., ..., 0., 0., 0.]]) As mentioned earlier, the .at attribute in NUMPY is not equivalent

11

to the .at in NUMARRAY. In NUMPY, the .at attribute of the ndarray object returns an iterator that allows you to step through an array in Cstyle contiguous order. object. Users of NUMARRAY, when taking the mean of a oat32 array, expect to receive a reasonably accurate result. > > > import numarray > > > a = numarray.ones((1000,1000),dtype=numarray.Float32)*132.00005 >>> a array([[ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], ..., [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578]], type=Float32) > > > a.min() 132.00004577636719 > > > a.max() 132.00004577636719 > > > a.mean() 132.00004577636719 >>> However, in NUMPY you would receive the following result. To achieve the array behavior of .at as seen in NUMARRAY you will need to use the .ravel() method on NUMPY's ndarray

12

> > > import numpy > > > a = numpy.ones((1000,1000),dtype=numpy.oat32)*132.00005 >>> a array([[ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], ..., [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578], [ 132.00004578, 132.00004578, 132.00004578, ..., 132.00004578, 132.00004578, 132.00004578]], dtype=oat32) > > > a.min() 132.000045776 > > > a.max() 132.000045776 > > > a.mean() 133.96639999999999 >>> What's the dierence? In NUMARRAY, the computation is done in

double precision while in NUMPY is was done in single precision. Why does NUMPY do the computation in single precision? The accumulator variable used in the mean algorithm is of the the same data type as the array. Since the array is numpy.oat32 the accumulator was only 32-bit. NUMPY makes no assumptions about the intentions of the user. If you want more precision in the computation of the mean of the array it must be specied explicitly.

13

> > > import numpy > > > a = numpy.ones((1000,1000),dtype=numpy.oat32)*132.00005 > > > a.min() 132.000045776 > > > a.max() 132.000045776 > > > a.mean(dtype=numpy.oat64) 132.00004577636719

3.1.3 The "dtype" Object

One of the new features of NUMPY is that data type is not a property of the array. It is a property of an array attribute known as the dtype object. The dtype object is an attribute of the ndarray. This dtype object is used in all of the array construction methods. In fact, one of the notable dierences between NUMARRAY and NUMPY is that it is necessary for you to use dtype= anywhere you would have used type= or typecode= in NUMARRAY. The dtype object does not only contain the data type of the array. The dtype object associated with an ndarray completely denes the data in the array. This denition includes the data type, the byte-order, and any named elds of the array. The most commonly used attributes of the dtype object are the following:

type  the type object used to instantiate a scalar of the ndarray datatype. char  a character code representing one of the numpy built-in types. str  the array protocol type string. A common type string would look like '<i4'. The rst character in the string gives us the byte-order. The second character in the string gives us a character code indicating the data type. the nal character gives us the size of an ndarray element in bytes. So '<i4' tells us that this data has little-endian byte-order, is integer data, of 4 bytes (32 bits).

name  the bit-width name.

14

byteorder  a character representing the byte-order. = is the native byte order for the platform. < represents little-endian byte-order. > represents big-endian byte-order. | indicates that this attribute is not applicable for this particular dtype object.

itemsize  the element size for this ndarray object in bytes. names  an ordered list of eld names. isnative  a boolean value indicating if this dtype object has a byteorder that is native to the current operating system.

Let us take a look at these attributes in some examples. The rst example is of a simple int32 array: > > > import numpy > > > a = numpy.array([1,2,3,4]) > > > a.dtype.type <type 'numpy.int32'> > > > a.dtype.char 'l' > > > a.dtype.str '<i4' > > > a.dtype.name 'int32' > > > a.dtype.byteorder '=' > > > a.dtype.itemsize 4 > > > a.dtype.names > > > a.dtype.isnative True >>> Notice that since there are no named elds nothing is printed for a.dtype.names. In NUMPY every array is a form of ndarray. the dtype of a recarray object as well. This is also true for the recarray class which inherits from ndarray. This means that we can examine

15

> > > import numpy > > > from numpy import rec > > > r = rec.fromrecords([[456,'dbe',1.2],[2,'de',1.3]],names='col1,col2,col3') > > > r.dtype.type <class 'numpy.core.records.record'> > > > r.dtype.char 'V' > > > r.dtype.str '|V15' > > > r.dtype.name '120' > > > r.dtype.byteorder '|' > > > r.dtype.itemsize 15 > > > r.dtype.names ('col1', 'col2', 'col3') > > > r.dtype.isnative True >>>

3.1.4 Inheritance
As mentioned earlier the only way to add attributes to an object is through sub-classing the ndarray class. The rst thing to know is that the ndarray is a  __new__ style Python class. For NUMPY, this means that the Let us create a  __init__ is ignored if you are inheriting from the ndarray. The best way to illustrate inheritance in NUMPY is with an example. have the following form: simple subclass of a recarray and add two new attributes. Your code would

16

class FITS_rec(rec.recarray): def __new__(subtype, input): """ Construct a FITS record array from a recarray. """ # input should be a record array if input.dtype.subdtype is None: self = rec.recarray.__new__(subtype, input.shape, input.dtype, buf=input.data, heapoffset=input._heapoffset, file=input._file ) else: self = rec.recarray.__new__(subtype, input.shape, input.dtype, buf=input.data, strides=input.strides, heapoffset=input._heapoffset, file=input._file ) self._coldefs = None self._gap = 0 return self def __array_finalize__(self,obj): if obj is None: return self._coldefs = obj._coldefs self._gap = obj._gap
The key to adding the new attributes is the __array_nalize__() method. All new attributes must be initialized there.

3.2

NUMPY's NUMARRAY Python-API

Although it is best for the future maintainability of your code that it be converted to NUMPY syntax, it is possible to convert you code with very few

17

changes. You '.py' les can be converted to NUMPY using the NUMARRAY Python-API. This allows your application or library to create and manipulate NUMPY's ndarrays while still using NUMARRAY syntax. You can access this API with the following calls: NUMARRAY import numarray import numarray.PACKAGE import numarray as X import numarray.PACKAGE as X from numarray import X from numarray.PACKAGE import X NUMPY import numpy.numarray import numpy.numarray.PACKAGE import numpy.numarray as X import numpy.numarray.PACKAGE as X from numpy.numarray import X from numpy.numarray.PACKAGE import X

This module creates aliases for many of the function names used in NUMARRAY as well as dening many NUMARRAY ufuncs. Although this is quite useful, this API does not guarantee that all of your NUMARRAY code will work. When using the NUMARRAY Python-API you are still creating a numpy.ndarray. This means that if you are depending on internal NUMARRAY attributes or methods that are not replicated by NUMPY your application will fail. The following example illustrates this point: > > > import numpy.numarray as numarray > > > a = numarray.array([1,2,3,4],type=numarray.Float32) > > > print a [ 1. 2. 3. 4.] > > > type(a) <type 'numpy.ndarray'> > > > a.type() Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'numpy.ndarray' object has no attribute 'type'

One word or warning, we have found that passing arrays created with the NUMARRAY compatibility layer to other modules that do not use the compatibility layers can lead to problems. These problems usually occur when NUMPY and NUMARRAY have similar names for methods and attributes where a method in one array package has the same name as an attribute in another (i.e. obj.itemsize vs. obj.itemsize()).

18

3.3

NUMPY's NUMARRAY C-API

To facilitate the porting of NUMARRAY base C code, NUMPY provides a complete NUMARRAY C-API interface. This allows you to use your existing NUMARRAY C extensions with NUMPY to create and manipulate NUMPY ndarrays. Only minimal changes are required to allow your code to use the NUMPY NUMARRAY C-API. In your C extension you will replace the #include libnumarray.h with #include numpy/libnumarray.h. In your setup le all that is required is are the following:

import numpy import numpy.numarray as nn numpyincludedirs = numpy.get_include() numarrayincludedirs = nn.get_numarray_include_dirs()

Just make certain that the numpyincludedirs and numarrayincludedirs are included in the list of directories used for compilation. When writing new extensions, do not use the NUMPY NUMARRAY CAPI. This layer is only for backward compatibility with existing code and will not be supported for the development of new code. For the maintainability of your code you are advised to write all new code using NUMPY's native C-API.

3.4

NUMPY's C-API

NUMPY includes a complete C-API for writing extensions to working with ndarrays. This API is fully discussed in Travis Oliphant's Guide to Numpy and on the http://www.scipy.org web pages. It is recommended that all new C extensions be written using this C-API.

3.5

Conversion Tools

There exists within NUMPY tools for converting your existing NUMARRAY code. These programs are called alter_code1.py and alter_code2.py. They can be found in the "numpy/numpy/numarray/" directory. The alter_code1.py program is used to change your import statements to use the NUMARRAY Python compatibility layer.

19

The alter_code2.py program is used to attempt to change your code to NUMPY syntax. The program removes the NUMARRAY compatibility layer from your import statements and attempts to modify the code to use NUMPY syntax. Neither program is guaranteed to take working NUMARRAY based Python programs and create working NUMPY versions. Because most users are assumed to be satised with using the NUMARRAY compatibility module the alter_code2.py program is advertised as being incomplete. We cannot recommend using either of these programs to convert your applications. code. We have found it more instructive to manually change our Also, we rarely received a working application directly from the al-

ter_code1.py script. It was often necessary to manually change the code to NUMPY syntax in the end.

20

What Happened To NUMARRAY's External Packages nd_image, image, and convolve?

Within the NUMARRAY distribution there are a number of extension modules. These modules are most often imported into the application namesMany of the NUMPY pace with the following syntax, "from numarray import PACKAGE", where PACKAGE would be "nd_image", as an example. distribution. developers feel that these packages do not belong as part of the NUMPY To that end, these packages have been moved into a project known as SCIPY. SCIPY is a Python module used to support many algorithms used in scientic computing. You can learn more about this package at http://www.scipy.org. Within the scipy package, nd_image has been renamed ndimage. The convolve and image modules are now part of the stsci module within scipy. Since many of our own applications depend on these modules we will be distributing them with our STSCI_PYTHON applications. To access these modules using a STSCI_PYTHON distribution you only need to use the following commands:

> > > import convolve > > > import image > > > import ndimage

21

Bug or Feature?

This section of the document is intended to bring your attention to features that may appear as bugs to NUMARRAY users but may actually be features in NUMPY. However, these NUMPY behaviors may also be bugs and could change with future releases.

5.1

The recarry Module and the Zero Repeat Count

The format_parser in the records module in numpy.core cannot handle a repeat count of zero. This feature is actually important in pyts so that The dierence between the a user can dene a eld that has zero length.

numpy and numarray behavior is illustrated below:

22

In [10]: import numarray.records as r In [11]: x = r.array(None,formats="a8,3f8,0f8,i4,f4,a1,f4,3f4,a1,f4,3f4", shape=28) In [12]: from numpy import rec In [13]: y = rec.array(None,formats="a8,3f8,0f8,i4,f4,a1,f4,3f4,a1,f4,3f4", shape=28)  <type 'exceptions.TypeError'> Traceback (most recent call last) /data/sparty1/dev/devCode/<ipython console> in <module>() /data/sparty1/dev/site-packages/lib/python/numpy/core/records.py in array(obj, dtype, shape, oset, strides, formats, names, titles, aligned, byteorder, copy) 516 elif formats is not None: 517 dtype = format_parser(formats, names, titles, > 518 aligned, byteorder)._descr 519 else: 520 kwds = {'formats': formats, /data/sparty1/dev/site-packages/lib/python/numpy/core/records.py in __init__(self, formats, names, titles, aligned, byteorder) 46 self._parseFormats(formats, aligned) 47 self._seteldnames(names, titles) > 48 self._createdescr(byteorder) 49 50 def _parseFormats(self, formats, aligned=0): /data/sparty1/dev/site-packages/lib/python/numpy/core/records.py in _createdescr(self, byteorder) 107 'formats':self._f_formats, 108 'osets':self._osets, > 109 'titles':self._titles}) 110 if (byteorder is not None): 111 byteorder = _byteorderconv[byteorder[0]] <type 'exceptions.TypeError'>: data type not understood

23

The Future

It has been decided that the records' module inability to parse a format string specifying a zero repeat count will not be xed. This functionality is of limited general use and is really only applicable to PyFITS support. PyFITS uses this ability in the creation of zero length elds. Because of this, this functionality will be incorporated directly into the FITS_rec class of PyFITS.

24

References

Texts: 1. Oliphant, Travis. Guide to NUMPY, Tregol, Utah, February 2007. Web Sites: 1. Numpy, Primary Page  http://www.scipy.org/NumPy 2. Numpy, Trac Page  http://projects.scipy.org/scipy/numpy 3. SciPy, Primary Page  http://www.scipy.org 4. SciPy, Trac Page  http://projects.scipy.org/scipy/scipy

25