<br><br><div class="gmail_quote">On Thu, Nov 12, 2009 at 3:30 PM, Charles R Harris <span dir="ltr"><<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">On Thu, Nov 12, 2009 at 12:52 PM, Christopher Barker <span dir="ltr"><<a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>Robert Kern wrote:<br>
<br>
> Didn't we already do this?<br>
><br>
> <a href="http://www.mail-archive.com/numpy-discussion@scipy.org/msg21010.html" target="_blank">http://www.mail-archive.com/numpy-discussion@scipy.org/msg21010.html</a><br>
<br>
</div>Indeed we did. What I posted then ( and have improved a bit now). Is a<br>
Python version. Written in Python, it has an advantage of using less<br>
memory for a big array, but is slower in other respects than a Python<br>
list. This is probably why we all use lists for this when we need it!<br>
<br></blockquote></div><div><br>IIRC, python lists *are* expanding arrays of contiguous memory, not linked lists. They are efficient for appending and indexing, less so for deletion and insertion. It's one of those tradeoffs. So what you buy with an array implementation is the space/time efficiency of not having to allocate python types to put on the list. But you probably need to go through a python type at some point anyway, so...<br>

<br></div></div></blockquote><div><br>And here is a <a href="http://www.python.org/dev/peps/pep-3128/%20">pep</a> for a Blist with a table of some of the performance tradeoffs. I think you could use small ndarrays in the leaf nodes and get around having to handle all the type stuff.<br>
<br>Chuck<br> </div></div>