<div class="gmail_quote">On Mon, Aug 30, 2010 at 10:50 AM, <span dir="ltr"><<a href="mailto:josef.pktd@gmail.com">josef.pktd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div><div></div><div class="h5">On Mon, Aug 30, 2010 at 11:39 AM, Bruce Southey <<a href="mailto:bsouthey@gmail.com">bsouthey@gmail.com</a>> wrote:<br>
> On 08/30/2010 09:19 AM, Benjamin Root wrote:<br>
><br>
> On Mon, Aug 30, 2010 at 8:29 AM, David Huard <<a href="mailto:david.huard@gmail.com">david.huard@gmail.com</a>> wrote:<br>
>><br>
>> Thanks for the feedback,<br>
>> As far as I understand it, the proposition is to keep histogram as it is<br>
>> for 1.5, then in 2.0, deprecate normed=True but keep the buggy behavior,<br>
>> while adding a density keyword that fixes the bug. In a later release, we<br>
>> could then get rid of normed. While the bug won't be present in histogramdd<br>
>> and histogram2d, the keyword change should be mirrored in those functions as<br>
>> well.<br>
>> I personally am not too keen on changing the keyword normed for density. I<br>
>> feel we are trading clarity for a few new users against additional trouble<br>
>> for many existing users. We could mitigate this by first documenting the<br>
>> change in the docstring and live with both keywords for a few years before<br>
>> raising a DeprecationWarning.<br>
>> Since this has a direct impact on matloblib's hist, I'd be keen to hears<br>
>> the devs on this.<br>
>> David<br>
><br>
> I am not a dev, but I would like to give a word of warning from matplotlib.<br>
><br>
> In matplotlib, the bar/hist family of functions grew organically as the devs<br>
> took on various requests to add keywords and such to modify the style and<br>
> behavior of those graphing functions. It has now become an unmaintainable<br>
> mess, prompting discussions on how to rip it out and replace it with a<br>
> cleaner implementation. While everyone agrees that it needs to be done, we<br>
> all don't want to break backwards compatibility.<br>
><br>
> My personal feeling is that a function should do one thing, and do that one<br>
> thing well. So, to me, that means that histogram() should return an array<br>
> of counts and the bins for those counts. Anything more is merely window<br>
> dressing to me. With this information, one can easily compute a cumulative<br>
> distribution function, and/or normalize the result. The idea is that if<br>
> there is nothing special that needs to be done within the histogram<br>
> algorithm to accommodate these extra features, then they belong outside the<br>
> function.<br>
><br>
> My 2 cents,<br>
> Ben Root<br>
><br>
> _______________________________________________<br>
> NumPy-Discussion mailing list<br>
> <a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
> <a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
><br>
> +1 for Ben's approach.<br>
> This is very similar to my view regarding to the contingency table class<br>
> proposed for scipy ( <a href="http://projects.scipy.org/scipy/ticket/1258" target="_blank">http://projects.scipy.org/scipy/ticket/1258</a>). We need<br>
> to provide the core functionality that other approaches such as density<br>
> estimation can use but not be limited to specific details.<br>
<br>
</div></div>I think (a corrected) density histogram is core functionality for<br>
unequal bin lengths.<br>
<br>
The graph with raw count in the case of unequal bin sizes would be<br>
quite misleading when plotted and interpreted on the real line and not<br>
on discrete points (shaded areas instead of vertical lines). And as<br>
the origin of this thread showed, it's not trivial to figure out what<br>
the correct normalization is.<br>
So, I think, if we drop the density normalization, we just need a new<br>
function that does it.<br>
<br>
My 2c,<br>
<br>
Josef<br>
<br>
<br></blockquote><div><br>Why not a function that takes the output of a core histogram and produces a correct density normalization? Such a function would be useful elsewhere, I imagine.<br><br>Of course there is a lot of legacy issues to consider, but if we introduce such a function first with documentation in histogram() showing how to produce a normalized density, we can then keep some of the bad code for now for backwards compatibility with notes saying that some of the stuff will be deprecated. Especially point out in the docs where the current code fails to produce the correct results.<br>
<br>Ben Root<br></div></div>