[Numpy-discussion] Tabular data package

Elaine Angelino elaine.angelino@gmail....
Mon Oct 5 18:15:44 CDT 2009


Do the minimum number of .view()s that you can get away with.
>
>
I guess our bottom line is that we're still not 100% clear as to the
recommendation of the NumPy community regarding whether we should use
recarray or ndarray.  It seems like recarray has some advantages (e.g. the
nice inference functions/constructors, and the fact that some people like
the ability to fields as attributes) as well as some disadvantages (e.g. the
overhead).

it definitely wouldn't be much difficulty to convert tabular to using
ndarrays, but is it very desirable?  Of course if we were to do this, having
recarray-style constructors for ndarrays directly in Numpy would be seem to
be a "cleaner" way to do things than either writing our own ndarray versions
or casting from recarray to ndarray, but we're happy to do either if
changing tabular to ndarray is really desirable.



>
>
> Well, what other recarray functionality are you using?


None, in our code.   We also thought that since at least some people like
using the attribute reference property, perhaps users of tabarrays might too
(though we don't personally in our own work)   Recarrays still seemed to be
being supported by NumPy, so it seemed to make sense to use them.   but the
only functional thing in our code are those constructors.



>
> > (Also, is first casting to recarrays and then viewing as ndarrays more
> > expensive than if we went through ndarray directly?)
>
>
But if NumPy decided to include ndarray versions of the from*() constructors
in the distribution, would this be achieved by first using the recarray
constructor and then viewing as ndarray?  Or would something more "direct"
be done?


thanks,
e
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20091005/e9f3bac8/attachment.html 


More information about the NumPy-Discussion mailing list