[yt-dev] ProfileND: soliciting opinions

Sam Skillman samskillman at gmail.com
Mon Feb 3 15:29:51 PST 2014


+1 on having .x be the bin centers, and .x_bins being edges.  That said,
what is the protocol for calculating the center of logarithmically spaced
bins? Is it
.x = (.x_bins[:1] + .x_bins[1:])/2
or
.x = 10**( (np.log10(.x_bins[:1]) + np.log10(.x_bins[1:]))/2 )


On Mon, Feb 3, 2014 at 3:05 PM, Nathan Goldbaum <nathan12343 at gmail.com>wrote:

> On Mon, Feb 3, 2014 at 2:57 PM, Matthew Turk <matthewturk at gmail.com>
> wrote:
> >
> > On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343 at gmail.com> wrote:
> >>
> >> +1.
> >>
> >> While we're talking about profiles, it would be nice if I could
> >> specify the bin limits in the create_profile function - right now they
> >> are hard coded to come from the Extrema derived quantity.  This would
> >> make it a bit more straightforward to make a ProfilePlot or PhasePlot
> >> with custom axes limits.
> >>
> >
> > I think the idea of create profiles was to stay super minimalist, and
> > encourage using the actual objects for more complex operations. I'm not
> sure
> > I want to bolt more arguments on rather than making ProfileND easier.
> >
>
> Agreed, to a point.  The issue is that it's not straightforward to
> create a custom PhasePlot or ProfilePlot.  The docstrings mention
> being able to construct a custom profile with create_profile, but
> create_profile doesn't really offer much customization.
>
> ProfileND offers plenty of customization, but there are no docstrings
> in ProfileND or any subclasses so it's not exactly a user-friendly
> operation right now.  ProfileND is also not in the yt.mods namespace.
>
> Adding docstrings to ProfileND and adding it to yt.mods would satisfy
> my concerns, I think.
>
> > Specifying bin edges manually could be neat, though, especially for
> > non-uniform bins...
> >
> >> It would also be nice if ProfileND returned YTArrays, that's something
> >> I was planning to add soonish, but if you guys handle it that would be
> >> great.
> >
> > Optimistically, no more than 36 hours for that. :) I also hope to have a
> > wrapper for a array_like_field type thing too, to make it easier to copy
> and
> > duplicate units. Thoughts on that?
>
> Not totally sure what you mean, can you expand with a little bit more
> detail?
>
> >
> > Matt
> >
> >>
> >> -Nathan
> >>
> >> On Mon, Feb 3, 2014 at 1:53 PM, John ZuHone <jzuhone at gmail.com> wrote:
> >> >> I am +1 on this provided that prof.x_bins, etc. remains with the
> values
> >> >> of the fields at bin edges.
> >> >
> >> >
> >> > Yes, that would remain the same.
> >> > _______________________________________________
> >> > 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
> >
> >
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140203/fbfd97c3/attachment.html>


More information about the yt-dev mailing list