From: Erik T. <eri...@gm...> - 2010-08-24 18:39:57
|
I just realized the patch I sent before includes some other changes... the attached version should only be the fix for this particular bug. On Mon, Aug 23, 2010 at 7:23 PM, Erik Tollerud <eri...@gm...> wrote: > This is definitely a bug, but I thought I'd clarify and add in a little more... > > The distinction between 'step' and 'stepfilled' is that 'step' is > supposed to show only the outline of the histogram with no lines in > between bins (standard practice in some fields), while 'stepfilled' is > supposed to do the same, but have a different-colored fill between the > steps and the x-axis. This is different from 'bar' because the bars > always have either an outline bounding each bar, or no outline at all. > An alternative approach, presumably, would be to eliminate > 'stepfilled' and instead just pass in some keyword that tells whether > or not to draw the filled color region or not, but that was judged > confusing because it would have no meaning for the bar types. > > As for the log=True errors, I think what this was supposed to do was > have the minimum number of bin *counts* be the replacement for 0s, > rather the minimum *value*, so that's just a pure bug. This is might > have been my fault - the code has changed quite a bit from the > original patch, so I'm not sure at this point. The logic was that > this makes more sense than arbitrarily choosing 1 - if you have a > histogram where the bins are all within, say, 1000 and 10000, but one > of them is 0, it perhaps looks better to set the bottom to the 1000 > rather than 1... It was really just an arbitrary choice that no one > objected to at the time. > > As I think about it, it might make sense to change it so that the log > keyword can be used to set the assumed minimum value for empty bins if > it is greater than 0 (and stick with the default you suggested of 1 if > log=True). The attached patch includes this change, adopted from > Ben's original patch, as well as clarifying all of this in teh > docstring. > > > On Wed, Aug 11, 2010 at 1:56 PM, Benjamin Root <ben...@ou...> wrote: >> On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root <ben...@ou...> wrote: >>> >>> I am tracing down a bug in hist() and I am trying to figure out what is it >>> about the 'stepfilled' mode that is different from the regular 'bar' mode. >>> Currently, the hist() code has a separate if branch for dealing with 'step' >>> and 'stepfilled', and that branch has a bunch of bugs. The best that I can >>> figure is that it prevents lines from being drawn in between the bins. If >>> that is the only difference, maybe we could somehow use the bar functions? >>> >>> At the very least, I think this needs to be documented better to make it >>> clear why this oddball approach is happening. >>> >>> Thanks, >>> Ben Root >> >> By the way, the bugs I was referring to both have to do with log=True and >> the two stepped modes. >> >> First, the smallest of values to histogram (the minimum bin value) is, for >> some reason, used to clip the lower bounds of the histogram count. In some >> situations, this can result in most if not all the graph not being shown. >> >> Second, related to the first is a problem with the 'stepfilled' mode in log >> space. The stepfilled mode uses the minimum bin value to anchor the >> patches. However, this can cause the polygon to not close correctly and can >> get some unsightly artifacts. I have attached an image demonstrating this >> bug. This has been reported before: >> >> http://old.nabble.com/hist%28%29-with-log-and-step-tp28888742p28888742.html >> http://old.nabble.com/Bug-in-stepfilled-hist-with-log-y-tp28538074p28538074.html >> >> In one of the comments, the reporter concluded that it appeared fixed, but >> either he was experiencing a slightly different problem, or he was mistaken. >> >> I have also included a possible patch for addressing these issues. The >> approach simply sets the minimum value to be zero when not doing log, and >> use 1.0 when log=True. This differs slightly from how the normal bar graphs >> are done where a value of 1e-100 is used when log=True, but then the axes >> limits are adjusted to use 1.0 as a lower limit. >> >> Cheers, >> Ben Root >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by >> >> Make an app they can't live without >> Enter the BlackBerry Developer Challenge >> http://p.sf.net/sfu/RIM-dev2dev >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> >> > > > > -- > Erik Tollerud > -- Erik Tollerud |