<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 10:58 PM, Nathan Goldbaum <span dir="ltr"><<a href="mailto:nathan12343@gmail.com" target="_blank">nathan12343@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>I spent some time tonight thinking of a way to supply a cut_region as a data_source for a SlicePlot.</div><div><br></div><div>Right now this will raise a NotImplementedError, since cut_regions don't work using selectors. Instead, they override data selection at the level of the chunking system.  This is a problem for a SlicePlot, since a slice is really a 2D selection object and makes use of a selector object to decide whether or not data should be included in the slice. Cut regions technically could be implemented using selectors, but they don't lend themselves to the geometrically focused selector API. </div><div><br></div><div>One way around this is to eat some memory and pass the positions of cells that pass the cut_region selection criteria down to the cython selector. Lo and behold, it actually works!   Kind of.</div><div><br></div><div>I've pasted the necessary diff here: <a href="http://paste.yt-project.org/show/5210/" target="_blank">http://paste.yt-project.org/show/5210/</a></div><div><br></div><div>Here's an example script: <a href="http://paste.yt-project.org/show/5211/" target="_blank">http://paste.yt-project.org/show/5211/</a></div><div><br></div><div>After much gnashing of teeth (about 20 minutes worth on my laptop), this should produce the following image: <a href="http://imgur.com/DlHruOi" target="_blank">http://imgur.com/DlHruOi</a></div><div><br></div><div>The way I've done this is really bad: not only am I re-aquiring the GIL and messing with python objects inside a tight cython function, but I'm also using the python objects to do an O(N^2) search algorithm!<br></div><div><br></div><div>I think it's possible to speed this up significantly by using a smarter search algorithm implemented in C.  Before I spend effort on that, I wanted to send this e-mail out to summarize my thoughts and check to see if this is a crazy approach.</div><div><br></div><div>If this is a worthy approach, does anyone know of an O(logN) search algorithm I could use to find a 3D position in a list of 3D positions?</div></div></blockquote><div><br></div><div>Woah, it's *a lot* faster if I use a python dict as a hashmap.  It seems checking if a key is in a dict is O(1), and that helps a lot.  I think I'm going to PR this!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Thanks for taking a look :)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nathan</div><div><br></div><div><br></div><div><br></div><div><br></div></font></span></div>
</blockquote></div><br></div></div>