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