+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@gmail.com> wrote:
On Mon, Feb 3, 2014 at 2:57 PM, Matthew Turk <matthewturk@gmail.com> wrote:
>
> On Feb 3, 2014 5:45 PM, "Nathan Goldbaum" <nathan12343@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@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@lists.spacepope.org
>> > http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev@lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev@lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org