On Fri, Aug 15, 2008 at 3:12 PM, Travis E. Oliphant <[EMAIL PROTECTED]>wrote:
> Robert Kern wrote: > > > >>>> 3) Are the additional 4-8 bytes too expensive > >>>> > >>> One of the problems with numarray was the time taken to allocate small > >>> arrays. Would adding a dictionary slow down the allocation of numpy > arrays? > >>> > No, I don't think so, not if we did nothing by default but set the dict > to NULL (i.e. no propagation of meta-information to new arrays). > >> That said, I think we should keep things as simple and orthogonal as > >> possible. If we go this way, I think a subclass with a dictionary would > be > >> the best approach to avoid the heartbreak of creeping featuritis. > >> > > > > The point of the feature is to avoid subclasses. There are a number of > > use cases for annotating arrays with metadata. Currently, they are > > forced to use subclasses. Every time you use ndarray subclasses, you > > are essentially forcing yourself into your subclass's ghetto of > > functions that only work on your subclass. > > > This would be one-step better in the sense that there would be a single > sub-class to handle all cases of just needing meta information. But, > I tend to agree that adding the dictionary to all arrays is preferable. > > I think you could make the dictionary created lazily on the first > getattr(). > > > Yes, that could easily be done. It would just be set to NULL on > creation and the penalty/overhead would be the extra pointer in the > array structure. > That doesn't sound bad, and the convenience is probably worth it. Can this be done in a way that doesn't require a new compile? That is, can it look like a subclass in C? I'm opposed to adding anything until 1.2 is out. Chuck
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
