[yt-dev] Numpy-like ops YTEP

Matthew Turk matthewturk at gmail.com
Fri Sep 25 17:15:55 PDT 2015


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
>



More information about the yt-dev mailing list