[yt-dev] Numpy-like ops YTEP

[Matthew Turk]

I've implemented arbitrary_grid pulling from fluid fields with a port
of the pixelizer code; tests are added in current state of PR, too.
Still one more thing to do there, which is to get multiple fields in a
single pass.

On Fri, Sep 25, 2015 at 7:15 PM, Matthew Turk <matthewturk at gmail.com> wrote:
> Hi Cameron,
>
> Yeah, a kwarg for the actual .arbitrary_grid would be great, but that
> can't be expressed in the slicing notation (or rather, it can, but
> it's unnatural).  So getting the default is what I was hoping for; for
> particle quantities, we'll just have it do the standard "deposit"
> machinery which lets you do any type of interpolation you like, so
> it's less of a thing.
>
> -Matt
>
> On Fri, Sep 25, 2015 at 7:13 PM, Cameron Hummels <chummels at gmail.com> wrote:
>> 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
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>