I'd say nearest neighbor. Then it's also a generalization of what the FixedResolutionBuffer does.<span></span><br><br>On Friday, September 25, 2015, Matthew Turk <<a href="mailto:matthewturk@gmail.com">matthewturk@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
Thanks for the feedback -- I've made a bunch of changes and additions.<br>
One thing I wanted to ask was about 3D slicing that includes steps.<br>
For instance, in numpy style:<br>
<br>
ds = yt.load(...)<br>
ds.d[ (-5, 'km') : (5, 'km') : 128j, (-10, 'km') : (10, 'km') : 256j,<br>
(-2.5, 'km') : (2.5, 'km'): 64j]<br>
<br>
this should return a 128x256x64 3D array.  But, how do we generate that?<br>
<br>
The obvious thing would be to do either covering grid or arbitrary<br>
grids.  The former requires alignment with cell boundaries, and the<br>
latter currently only supports particles.  I think "arbitrary_grid"<br>
maps a lot more naturally to the situation, though.  So it would<br>
require implementing mesh fields in the arbitrary_grid object, which<br>
is fine, but it's not clear to me the right *way* to do that.  I think<br>
the choice might be between nearest neighbor and trilinear<br>
interpolation.  So, for the *default* behavior, should we do:<br>
<br>
 * Trilinear interpolation (maybe nicer, but also subject to<br>
crazytimes with stuff that isn't a volume quantity, like mass)<br>
 * Nearest neighbor (way, way faster, but also lower quality values in<br>
many cases)?<br>
<br>
My inclination is #2, but I wanted a sanity check...<br>
<br>
-Matt<br>
<br>
On Mon, Sep 21, 2015 at 3:17 PM, Matthew Turk <<a href="javascript:;" onclick="_e(event, 'cvml', 'matthewturk@gmail.com')">matthewturk@gmail.com</a>> wrote:<br>
> Hi all,<br>
><br>
> I'd very much appreciate feedback on this YTEP:<br>
><br>
> <a href="https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like-operations/diff" target="_blank">https://bitbucket.org/yt_analysis/ytep/pull-requests/55/ytep-0026-numpy-like-operations/diff</a><br>
><br>
> The related PR that starts implementing them is here:<br>
><br>
> <a href="https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-new-numpy-like-ops/diff" target="_blank">https://bitbucket.org/yt_analysis/yt/pull-requests/1763/wip-proposed-set-of-new-numpy-like-ops/diff</a><br>
><br>
> Two things that I think need some bikeshedding -- histogram and the<br>
> step argument to slicing.<br>
><br>
> -Matt<br>
_______________________________________________<br>
yt-dev mailing list<br>
<a href="javascript:;" onclick="_e(event, 'cvml', 'yt-dev@lists.spacepope.org')">yt-dev@lists.spacepope.org</a><br>
<a href="http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org" target="_blank">http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org</a><br>
</blockquote>