[Numpy-discussion] [ANN] NumPy 1.0b4 now available

Travis Oliphant oliphant.travis at ieee.org
Sun Aug 27 01:37:17 CDT 2006

Les Schaffer wrote:
> Travis E. Oliphant wrote:
>> Porting is not difficult especially using the compatibility layers 
>> numpy.oldnumeric and numpy.numarray and the alter_code1.py modules in 
>> those packages.  The full C-API of Numeric is supported as is the C-API 
>> of Numarray.
> this is not true of numpy.core.records  (nee numarray.records):
> 1. numarray's records.py does not show up in numpy.numarray.
Your right.  It's an oversight that needs to be corrected.    NumPy has 
a very capable records facility and the great people at STSCI have been 
very helpful in pointing out issues to help make it work reasonably like 
the numarray version.  In addition, the records.py module started as a 
direct grab of the numarray code-base, so I think I may have mistakenly 
believed it was equivalent.  But, it really should also be in the 
numarray compatibility module.

The same is true of the chararrays defined in numpy with respect to the 
numarray.strings module.
> 2. my code that uses recarrays is now broken if i use
> numpy.core.records; for one thing, you have no .info attribute. 
All the attributes are not supported.  The purpose of 
numpy.numarray.alter_code1 is to fix those attributes for you to numpy 
equivalents.  In the case of info, for example, there is the function 
numpy.numarray.info(self) instead of self.info().

> another
> example: strings pushed into the arrays *apparently* were stripped
> automagically in the old recarray (so we coded appropriately), but now
> are not.  
We could try and address this in the compatibility module (there is the 
raw ability available to deal with this exactly as numarray did).   
Someone with more experience with numarray would really be able to help 
here as I'm not as aware of these kinds of issues, until they are 
pointed out. 
> 3. near zero docstrings for this module, hard to see how the new
> records  works.
The records.py code has a lot of code taken and adapted from numarray 
nearly directly.   The docstrings present there were also copied over, 
but nothing more was added.  There is plenty of work to do on the 
docstrings in general.  This is an area, that even newcomers can 
contribute to greatly.  Contributions are greatly welcome.
> 4. last year i made a case for the old records to return a list of the
> column names. 
I prefer the word "field" names now so as to avoid over-use of the word 
"column", but one thing to understand about the record array is that it 
is a pretty "simple" sub-class.  And the basic ndarray, by itself 
contains the essential functionality of record arrays.   The whole 
purpose of the record sub-class is to come up with an interface that is 
"easier-to use," (right now that just means allowing attribute access to 
the field names).   Many may find that using the ndarray directly may be 
just what they are wanting and don't need the attribute-access allowed 
by the record-array sub-class.

> it looks like the column names are now attributes of the
> record object, any chance of getting a list of them
> recarrayObj.get_colNames() or some such? 
Right now, the column names are properties of the data-type object 
associated with the array, so that  recarrayObj.dtype.names will give 
you a list

The data-type object also has other properties which are useful. 

Thanks for your review.   We really need the help of as many numarray 
people as possible to make sure that the transition for them is easier.  
I've tried very hard to make sure that the numarray users have the tools 
they need to make the transition easier, but I know that more could be 
done.   Unfortunately, my availability to help with this is rapidly 
waning, however, as I have to move focus back to my teaching and research.



More information about the Numpy-discussion mailing list