[yt-dev] Numpy-like ops YTEP

Cameron Hummels chummels at gmail.com
Fri Sep 25 17:13:07 PDT 2015


How about default to one of the options, but have a kwarg to decide which
method to choose?  I sort of like trilinear interp but I'm just thinking of
grid-based data.  Maybe default to trilinear interp for grid-based
quantities and nearest neighbor for particle based quantities?

On Fri, Sep 25, 2015 at 4:46 PM, Nathan Goldbaum <nathan12343 at gmail.com>
wrote:

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


-- 
Cameron Hummels
NSF Postdoctoral Fellow
Department of Astronomy
California Institute of Technology
http://chummels.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20150925/e2404389/attachment.html>


More information about the yt-dev mailing list