Re: [matplotlib-devel] OK to delete methods?
I think you're right about this. Mike On 08/21/2010 03:08 PM, Eric Firing wrote: > Mike, John, or anyone else who works directly with Ticks: > > I think you are the only ones who have worked with the code I suggest > changing as in the attached diff. It looks to me like the three *Tick > methods, set_view_interval(), get_minpos(), get_data_interval(), are > unused and unlikely ever to have been or to be used. I particularly > object to the first of these because I don't think a Tick has any > business changing the view interval. The other two look like clutter, > harmless except insofar as they make it harder to understand the code. > If some projection actually does end up needing the functionality in > any of these methods, it is still available via *Tick.axes.xaxis.* etc. > > Am I missing something? If not, I will commit this to the trunk. > This is a case where I think immediate surgery is better than a > deprecation process. > > Thanks. > > Eric -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OK to delete methods?
On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing wrote: > Mike, John, or anyone else who works directly with Ticks: > > I think you are the only ones who have worked with the code I suggest > changing as in the attached diff. It looks to me like the three *Tick > methods, set_view_interval(), get_minpos(), get_data_interval(), are unused > and unlikely ever to have been or to be used. I particularly object to the > first of these because I don't think a Tick has any business changing the > view interval. The other two look like clutter, harmless except insofar as > they make it harder to understand the code. If some projection actually does > end up needing the functionality in any of these methods, it is still > available via *Tick.axes.xaxis.* etc. > > Am I missing something? If not, I will commit this to the trunk. This is a > case where I think immediate surgery is better than a deprecation process. I'm OK with removing them, and I don't feel strongly about deprecation with a helpful suggestion or radical mastectomy, though the former seems a little gentler. This should go into the trunk only since it is API breaking. JDH -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OK to delete methods?
On 08/23/2010 05:17 AM, John Hunter wrote: > On Sat, Aug 21, 2010 at 2:08 PM, Eric Firing wrote: >> Mike, John, or anyone else who works directly with Ticks: >> >> I think you are the only ones who have worked with the code I suggest >> changing as in the attached diff. It looks to me like the three *Tick >> methods, set_view_interval(), get_minpos(), get_data_interval(), are unused >> and unlikely ever to have been or to be used. I particularly object to the >> first of these because I don't think a Tick has any business changing the >> view interval. The other two look like clutter, harmless except insofar as >> they make it harder to understand the code. If some projection actually does >> end up needing the functionality in any of these methods, it is still >> available via *Tick.axes.xaxis.* etc. >> >> Am I missing something? If not, I will commit this to the trunk. This is a >> case where I think immediate surgery is better than a deprecation process. > > I'm OK with removing them, and I don't feel strongly about deprecation > with a helpful suggestion or radical mastectomy, though the former > seems a little gentler. This should go into the trunk only since it > is API breaking. > > JDH Committed to the trunk in r8655. I agree that deprecation is gentler, and that is the route I usually take; but given the obscurity of the Tick classes and the oddness of these methods in that class, I'm taking a chance on just getting it over with now. Time will tell whether it is a mistake. If it is, it won't be the first or the last. Eric > > -- > 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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] purpose of 'stepfilled' in hist()?
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 1, 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 wrote: > On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root 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-tp2742p2742.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 > Matplotlib-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > -- Erik Tollerud Index: lib/matplotlib/legend.py === --- lib/matplotlib/legend.py (revision 8655) +++ lib/matplotlib/legend.py (working copy) @@ -253,6 +253,15 @@ # introduce y-offset for handles of the scatter plot if scatteryoffsets is None: +if scatterpoints<2: +self._scatteryoffsets = np.array([.5]) +elif scatterpoints==2: +self._scatteryoffsets = np.array([.5,.5]) +elif scatterpoints==3: +self._scatteryoffsets = np.array([3./8., 4./8., 2.5/8.]) +else: +self._scatteryoffsets = np.ones(scatterpoint
