[Numpy-discussion] finding close together points.

Charles R Harris charlesr.harris at gmail.com
Thu Nov 12 12:39:04 EST 2009

On Thu, Nov 12, 2009 at 10:32 AM, Christopher Barker
<Chris.Barker at noaa.gov>wrote:

> David Cournapeau wrote:
> > I would love having a core C library of containers -
> I'm all for that. However, I think that a very, very common need is
> simply for a growable numpy array.
> It seems this would actually be pretty darn easy (again, for someone
> familiar with the code!).
> IIUC, it would be exactly like a regular old ndarray, except:
>  1) The data block could be larger than the current size of the array:
>     - this would require an additional attribute to carry that size
>  2) There would be an "append" method, or some other name:
>     - this would increase the size of the array, manipulating
> .dimensions, and, if needed, doing a reallocation of the data pointer.
>     - This is not very complex code, really, you simply allocate more
> than required, choosing some (user-resettable?) scale: 25% more than
> before, or whatever. re-allocating memory is actually pretty cheap these
> days, so it's not all that critical how you do it.
>  3) we'd probably want a .fit() method that would resize the data block
> to fit the current size of the array.
> In fact, as I write this, I wonder if these features could simply be
> added to the regular old ndarray -- if not used, they wouldn't be much
> overhead.
I'm rapidly losing interest here. Perhaps you could supply some code
implementing this new array? Why not just a class using an array that
doubles the array size when an index is out of bounds and copies over the
old data. That is pretty much what realloc does. As to python lists, do you
have any benchmarks showing how bad python lists are compared to arrays?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20091112/e8ab076a/attachment.html>

More information about the NumPy-Discussion mailing list