[Numpy-discussion] Rec array: numpy.rec vs numpy.array with complex dtype

[Dan Yamins]

Pierre, thanks for your response.  I have some follow up questions.


Short answer:
> a np.recarray is a subclass of ndarray with structured dtype, where
> fields can be accessed has attributes (as in 'yourarray.yourfield')
> instead of as items (as in yourarray['yourfield']).


Is this the only substantial thing added in the recarray class?  The fact
that you can access some fields via attribute notation?  We haven't been
using this feature anyhow ... (what happens with the field names have
spaces?)

Is the recarray class still being developed actively?

My favorite way to get a np.recarray is to define a standard ndarray
> w/ complex dtype, and then take a view as a recarray
> Example:
>  >>>  np.array([(1,10),(2,20)],dtype=[('a',int),
> ('b',int)]).view(np.recarray)


Is the purpose of this basically to use the property of recarrays of
accessing fields as attributes?   Or do you have other reasons why you like
this view?


> Mmh:
>  >>>  x = np.array([(1,10),(2,20)],dtype=[('a',int),('b',int)])
>  >>> rx = x.view(np.recarray)
>  >>> type(x[0])
>  <type 'numpy.void'>
>  >>> type(rx[0])
> <type 'numpy.void'>
>


In [18]: x = np.rec.fromrecords([(0,1,'a'),(2,0,'b')],names = ['A','B'])

In [19]: x[0]
Out[19]: (0, 1, 'a')

In [20]: type(x[0])
Out[20]: <class 'numpy.core.records.record'>

In [21]: np.version.version
Out[21]: '1.3.0'






> 3) We've heard talk about "complex data types" in numpy in general.
> Is there some good place we can read about this more extensively?

I think the proper term is 'structured data type', or 'structured
> array'.
>


Do you recommend a place we can learn about the interesting things one can
do with structured data types?  Or is the on-line documentation on the scipy
site the best as of now?



>
> >
> You have to construct your dtype explicitly, as in "dtype=[('A',
> '<i4'), ('B', '<i4'), ('C', '|S1')]".
> np.rec.fromrecords processes the array and try to guess the best type
> for each field, but it's slow and not always correct


Evidently.  But sometimes (in fact, a lot of times, in our particular
applications),  the type inference works fine and the slowdown is not large
enough to be noticeable.   And of course in the recarray constructors one
can override the type inference by including a 'dtype' or 'formats' argument
as well.   Obviously we can write constructor functions that include type
inference algorithms of our own, ... but having a "standard" way to do this,
with best practices maintained in the numpy core would be quite useful
nonetheless.


thanks,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090626/514224e0/attachment.html>