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.
-Travis
-Travis