<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 28, 2014 at 1:24 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class=""><p dir="ltr">> Memory efficiency -- somethign like my growable array is not all that hard to implement and pretty darn quick -- you just do the usual trick_ over allocate a bit of memory, and when it gets full re-allocate a larger chunk.</p>
</span><p dir="ltr">Can't you just do this with regular numpy using .resize()? What does your special class add? (Just curious.)</p></blockquote><div>it used resize under the hood -- it just adds the bookeeping for the over allocation, etc, and lets you access teh data as though it wasn't over-allocated</div><div><br></div><div>like I said, not that difficult.</div><div><br></div><div>I haven't touched it for a while, but it you are curious I just threw it up on gitHub:</div><div><br></div><div><a href="https://github.com/PythonCHB/NumpyExtras">https://github.com/PythonCHB/NumpyExtras</a><br></div><div><br></div><div>you want accumulator.py -- there is also a cython version that I didn't quite finish...it theory, it should be a be faster in some cases by reducing the need to round-trip between numpy and python data types...</div><div><br></div><div>in practice, I don't think I got it to a point where I could do real-world profiling.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<p dir="ltr">It's fun to sit around and brainstorm clever implementation strategies, but Wes already went ahead and implemented all the tricky bits, and optimized them too. No point in reinventing the wheel.<br></p></span>
<p dir="ltr">(Plus as I pointed out upthread, it's entirely likely that this "2x overhead" is based on a misunderstanding/oversimplification of how virtual memory works, and the actual practical overhead is much lower.)</p></blockquote><div>good point.</div><div><br></div><div>-CHB</div><div><br></div><div><br></div></div>-- <br><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a>
</div></div>