[Numpy-discussion] Tabular data package
Mon Oct 5 17:52:47 CDT 2009
On Mon, Oct 5, 2009 at 6:36 PM, Robert Kern <firstname.lastname@example.org> wrote:
> > the main reason we went with the recarray over the ndarray is because the
> > recarray has a couple of useful construction functions (e.g.
> > np.rec.fromrecords and np.rec.fromarrays). not only are these functions
> > convenient to use, they have nice data type inference properties which
> > have to rebuild ourselves if we wanted to avoid recarrays entirely.
> Try np.rec.fromrecords(...).view(np.ndarray).
Hi Robert, thanks your email. We definitely understand this use of
.view(). However, our question is, should we have implemented tabular
this way, e.g. in the tabarray constructor, first make a recarray and then
view it as an ndarray? (and then of course view it as a tabarray). This
would have the effect of eliminating the extra recarray functionality, and
some if its overhead as well. Is this the desirable design, or should we
stick with recarrays?
(Also, is first casting to recarrays and then viewing as ndarrays more
expensive than if we went through ndarray directly?)
> Most likely, we should have versions of those functions that return
> plain ndarrays. They are quite useful.
> def fromarrays(..., type=None):
> if type is not None:
> _array = _array.view(type)
> return _array
Yes, we definitely agree with you that there should be plain ndarray
versions of the fromarrays and fromrecords constructors. The only reason we
didn't include a function like your "fromarrays" function in tabular is that
we thought it might be a bit hackish for our package, and seemed like
something to be addressed by numpy directly, perhaps at a later time. This
was especially given that it didn't seem like people hated recarrays
In the event that people really think we should switch "tabular" from using
ndarrays to recarrays, we would definitely support a discussion of adding
these kinds of constructors directly to ndarrays.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion