Re: [matplotlib-devel] Patchs for changing ticks messing up mplot3d and tick-get/setters
Oh, excellent, then I don't have to do the test case, because I believe this solves my original problem :) Thanks! On Wed, Aug 25, 2010 at 12:15 AM, Reinier Heeres rein...@heeres.eu wrote: Hi all, Sorry for not finishing this nicely. I was looking at this last weekend, and concluded that this approach was not the way to fix the problem. The real problem was that we still had the old X/Y axes around and had to use new functions for the 3d axes (e.g. set_xticks*3d*, set_xlim*3d* etc). I just extracted these fixes from my working directory and committed them to svn (r8656). There are a few more things to polish; for example it would be good to check whether we have to change the view limits if we change the ticks. Next on my list is cleaning up some of the alpha handling in mplot3d. Cheers, Reinier On Tue, Aug 24, 2010 at 9:04 PM, Benjamin Root ben.r...@ou.edu wrote: On Tue, Aug 24, 2010 at 1:48 PM, Erik Tollerud erik.tolle...@gmail.com wrote: Sorry for the re-ping if it was taken care of in some way I didn't undertand, but this doesn't seem to have been changed on the trunk svn... should it have been, or is there some other branch that this stuff is being worked on? On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Great - if anything's unclear, I can fairly easily make a test case as Benjamin suggested, so just let me know if that's necessary - thank! On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres rein...@heeres.eu wrote: Hi Erik, Sorry for the delay. From just looking at the diff I would say it's a great addition. I'll test tomorrow and push it if it works (which I assume it does). Cheers, Reinier On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Just a quick ping about this - did it get applied, or was there something wrong with it? (Or am I just too impatient?) On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud -- Erik Tollerud -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Reinier Heeres Tel: +31 6 10852639 -- Erik Tollerud -- Erik Tollerud I don't believe so, and I think this was shortly before Reinier went on vacation. Erik, my question still applies. If you can make a nice short example that demonstrates the problem, we can then include it as a test to make sure it will always work properly. If the patch passes the test, I can apply it myself now. Ben Root -- Reinier Heeres Tel: +31 6 10852639 -- Erik Tollerud -- 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()?
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 erik.tolle...@gmail.com 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 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 ben.r...@ou.edu wrote: On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root ben.r...@ou.edu 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 -- Erik Tollerud Index: lib/matplotlib/axes.py === --- lib/matplotlib/axes.py (revision 8655) +++ lib/matplotlib/axes.py (working copy) @@ -7492,11 +7492,14 @@ - 'barstacked' is a bar-type histogram where multiple data are stacked on top of each other. - - 'step' generates a lineplot that is by default -unfilled. + - 'step
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
Did this fix ever get applied? I was looking at some other svn changes and it still says none of this part of legend.py has been altered... On Thu, Jun 10, 2010 at 8:50 AM, Jae-Joon Lee lee.j.j...@gmail.com wrote: On Wed, Jun 9, 2010 at 7:15 PM, Erik Tollerud erik.tolle...@gmail.com wrote: Jae-Joon, your patch looks to be effectively the same except for slightly different behavior when more than 3 points are present... but that was what was originally intended - the numpoints- scatterpoints was a good catch! I'm not sure if I put those numbers in the first places (maybe not), yes, that was what was originally intended. And I'm inclined to leave it as is. I'll commit the change soon. Thanks again. -JJ -- Erik Tollerud -- 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] Patchs for changing ticks messing up mplot3d and tick-get/setters
Sorry for the re-ping if it was taken care of in some way I didn't undertand, but this doesn't seem to have been changed on the trunk svn... should it have been, or is there some other branch that this stuff is being worked on? On Tue, Jul 27, 2010 at 10:14 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Great - if anything's unclear, I can fairly easily make a test case as Benjamin suggested, so just let me know if that's necessary - thank! On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres rein...@heeres.eu wrote: Hi Erik, Sorry for the delay. From just looking at the diff I would say it's a great addition. I'll test tomorrow and push it if it works (which I assume it does). Cheers, Reinier On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Just a quick ping about this - did it get applied, or was there something wrong with it? (Or am I just too impatient?) On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud -- Erik Tollerud -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Reinier Heeres Tel: +31 6 10852639 -- Erik Tollerud -- Erik Tollerud -- 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()?
Whoops, yes, that should be True... Also realized a slight error in the description of how the mimum is set - both of those are fixed in the attached diff. On Tue, Aug 24, 2010 at 1:53 PM, Eric Firing efir...@hawaii.edu wrote: On 08/24/2010 08:39 AM, Erik Tollerud wrote: I just realized the patch I sent before includes some other changes... the attached version should only be the fix for this particular bug. + if log is true: + minimum = 1.0 Don't you mean True, not true? Eric -- 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 -- Erik Tollerud Index: axes.py === --- axes.py (revision 8655) +++ axes.py (working copy) @@ -7492,11 +7492,14 @@ - 'barstacked' is a bar-type histogram where multiple data are stacked on top of each other. - - 'step' generates a lineplot that is by default -unfilled. + - 'step' is a histogram outlined by a lineplot with unfilled +patches. Toutlines only follow the top of the histogram, and +hence *rwidth* has no effect. - - 'stepfilled' generates a lineplot that is by default -filled. + - 'stepfilled' is a histogram bounded by a lineplot with filled +patches underneath. This is distinct from 'bar' in that the +outlines only follow the top of the histogram, and hence +*rwidth* has no effect. *align*: ['left' | 'mid' | 'right' ] Controls how the histogram is plotted. @@ -7521,7 +7524,10 @@ If *True*, the histogram axis will be set to a log scale. If *log* is *True* and *x* is a 1D array, empty bins will be filtered out and only the non-empty (*n*, *bins*, -*patches*) will be returned. +*patches*) will be returned. If *histtype* is 'step' or +'stepfilled', this can also be a float0 specifying the +minimum value for the bins (typically used to set the value +for empty bins). *color*: Color spec or sequence of color specs, one per @@ -7720,9 +7726,14 @@ y = np.zeros( 2*len(bins), np.float ) x[0::2], x[1::2] = bins, bins + +if log is True: +minimum = 1.0 +elif log: +minimum = float(log) +else: +minimum = 0.0 -minimum = min(bins) - if align == 'left' or align == 'center': x -= 0.5*(bins[1]-bins[0]) elif align == 'right': -- 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 ben.r...@ou.edu wrote: On Wed, Aug 11, 2010 at 3:11 PM, Benjamin Root ben.r...@ou.edu 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 scatterpoints2: +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(scatterpoints)*(3./8.) +self
Re: [matplotlib-devel] Patchs for changing ticks messing up mplot3d and tick-get/setters
Great - if anything's unclear, I can fairly easily make a test case as Benjamin suggested, so just let me know if that's necessary - thank! On Tue, Jul 27, 2010 at 12:27 AM, Reinier Heeres rein...@heeres.eu wrote: Hi Erik, Sorry for the delay. From just looking at the diff I would say it's a great addition. I'll test tomorrow and push it if it works (which I assume it does). Cheers, Reinier On Tue, Jul 27, 2010 at 2:55 AM, Erik Tollerud erik.tolle...@gmail.com wrote: Just a quick ping about this - did it get applied, or was there something wrong with it? (Or am I just too impatient?) On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud -- Erik Tollerud -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Reinier Heeres Tel: +31 6 10852639 -- Erik Tollerud -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patchs for changing ticks messing up mplot3d and tick-get/setters
Just a quick ping about this - did it get applied, or was there something wrong with it? (Or am I just too impatient?) On Mon, Jul 19, 2010 at 4:26 AM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud -- Erik Tollerud -- The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://ad.doubleclick.net/clk;226879339;13503038;l? http://clk.atdmt.com/CRS/go/247765532/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Patchs for changing ticks messing up mplot3d and tick-get/setters
I noticed some odd behavior when trying to set ticks on 3d plots made using mplot3d.Axes3D ... specifically, if you tries to access any of the 3D axes and change the ticks, it would result in a plot all squashed to one side (indicating some sort of projection problem). After a bit of digging, I discovered the source of the problem: axis.XAxis, the base of the 3D Axis class, calls set_view_interval, which is not overridden in mplot3d.axis3d.Axis, causing the wrong interval to get the range assigned when ticks were added. So the solution was to implement set_view_interval on the 3D Axis. That fix is attached as a diff against the current svn in mpl3d-ticks-fix.diff . Now setting ticks seems to work just fine, so I've included another diff that additionally implements set_?ticks3d and get_?ticks3d methods for Axes3D - that's attached as mpl3d-ticks-fix-add-methods.diff . -- Erik Tollerud mpl3d-ticks-fix.diff Description: Binary data mpl3d-ticks-fix-add-methods.diff Description: Binary data -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch/fix for two legend oddities/bugs
Jae-Joon, your patch looks to be effectively the same except for slightly different behavior when more than 3 points are present... but that was what was originally intended - the numpoints- scatterpoints was a good catch! As for allowing an array markerscale, I agree with Jae-Joon... I think the scatterpoints options are already stretching the limit of how adaptable this legend is supposed to be, and it quickly becomes confusing to match the offsets and the scalings. To be honest, I don't see the use-case for having markerscale be different for each point (not that there isn't a use for it, but it seems rather like a corner-case that probably would be rather data-specific and hence more suitable to subclassing...) On Wed, Jun 9, 2010 at 2:05 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: I'm not very kin to implement every possible options for every possible cases. If you need customization beyond what the current legend class provide, I recommend you to use proxy artists. http://matplotlib.sourceforge.net/users/legend_guide.html#using-proxy-artist I personally think that the drawing of the legend handle should be delegated to the associated artist (but fall back to the default behavior when not provided). Regards, -JJ On Wed, Jun 9, 2010 at 4:32 PM, Benjamin Root ben.r...@ou.edu wrote: I was trying the patch and I realized a possible use-case that might not have been thought of before. Consider the situation where a user does a scatter plot with markers of two different sizes. Then, it isn't that far-fetched that the user might also want to control the markerscale for each marker in the legend. A particular example would be that a user selected a smaller markersize for the second scatterplot so that one could see the markers from the first scatterplot if they share the same coordinates. However, they may wish to display the markers in the legend so that they have the same size. Currently, the markerscale argument accepts only a scalar, and not a list. I don't know how difficult it would be to modify it do that, but it is a thought. Ben Root On Wed, Jun 9, 2010 at 2:23 PM, Jae-Joon Lee lee.j.j...@gmail.com wrote: Thanks for reporting these. I took a look at your patch and slight revised it (see the attached). While I believe that my patch is compatible to yours, it'll be great if you check my patch to see if I missed anything. I'll commit the change soon. Regards, -JJ On Tue, Jun 8, 2010 at 3:16 PM, Erik Tollerud erik.tolle...@gmail.com wrote: I noticed some odd behavior in the legend and managed to track down the source of the problem and make a fix (a diff against the current svn is attached). Specifically, two things were fixed: *The markerscale argument for the legend seems to do nothing... The attached diff properly applies the markerscale scaling for polygon/circle collections and the markers for lines with markers (but NOT patches or the width of lines elements in the legend). *If the scatterpoints argument was 3, all points beyond 3 disappeared. This was because the default scatteryoffset only had 3 entries, so if you didn't specifically overwrite this, the points beyond 3 didn't appear. I've re-worked this so that now the default properly deals with a number of points other than 3. -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Patch/fix for two legend oddities/bugs
I noticed some odd behavior in the legend and managed to track down
the source of the problem and make a fix (a diff against the current
svn is attached). Specifically, two things were fixed:
*The markerscale argument for the legend seems to do nothing... The
attached diff properly applies the markerscale scaling for
polygon/circle collections and the markers for lines with markers (but
NOT patches or the width of lines elements in the legend).
*If the scatterpoints argument was 3, all points beyond 3
disappeared. This was because the default scatteryoffset only had 3
entries, so if you didn't specifically overwrite this, the points
beyond 3 didn't appear. I've re-worked this so that now the default
properly deals with a number of points other than 3.
Index: lib/matplotlib/legend.py
===
--- lib/matplotlib/legend.py (revision 8396)
+++ lib/matplotlib/legend.py (working copy)
@@ -253,7 +253,15 @@
# introduce y-offset for handles of the scatter plot
if scatteryoffsets is None:
-self._scatteryoffsets = np.array([3./8., 4./8., 2.5/8.])
+if scatterpoints2:
+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(scatterpoints)*(3./8.)
+self._scatteryoffsets[1::2] = 4./8.
else:
self._scatteryoffsets = np.asarray(scatteryoffsets)
reps = int(self.numpoints / len(self._scatteryoffsets)) + 1
@@ -446,6 +454,7 @@
fontsize = self._fontsize
+markerscale = self.markerscale
# legend_box is a HPacker, horizontally packed with
# columns. Each column is a VPacker, vertically packed with
@@ -519,6 +528,9 @@
legline_marker.set_clip_box(None)
legline_marker.set_clip_path(None)
legline_marker.set_linestyle('None')
+if markerscale !=1:
+newsz = legline_marker.get_markersize()*markerscale
+legline_marker.set_markersize(newsz)
# we don't want to add this to the return list because
# the texts and handles are assumed to be in one-to-one
# correpondence.
@@ -551,23 +563,20 @@
elif isinstance(handle, RegularPolyCollection):
-#ydata = self._scatteryoffsets
ydata = height*self._scatteryoffsets
size_max, size_min = max(handle.get_sizes()),\
min(handle.get_sizes())
-# we may need to scale these sizes by markerscale
-# attribute. But other handle types does not seem
-# to care about this attribute and it is currently ignored.
+
if self.scatterpoints 4:
-sizes = [.5*(size_max+size_min), size_max,
- size_min]
+sizes = np.array([.5*(size_max+size_min), size_max,
+ size_min])
else:
sizes = (size_max-size_min)*np.linspace(0,1,self.scatterpoints)+size_min
p = type(handle)(handle.get_numsides(),
rotation=handle.get_rotation(),
- sizes=sizes,
+ sizes=sizes*markerscale,
offsets=zip(xdata_marker,ydata),
transOffset=self.get_transform(),
)
@@ -588,12 +597,12 @@
# attribute. But other handle types does not seem
# to care about this attribute and it is currently ignored.
if self.scatterpoints 4:
-sizes = [.5*(size_max+size_min), size_max,
- size_min]
+sizes = np.array([.5*(size_max+size_min), size_max,
+ size_min])
else:
sizes = (size_max-size_min)*np.linspace(0,1,self.scatterpoints)+size_min
-p = type(handle)(sizes,
+p = type(handle)(sizes*markerscale,
offsets=zip(xdata_marker,ydata),
transOffset=self.get_transform(),
)
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo___
Matplotlib-devel mailing
Re: [matplotlib-devel] matplotlib image tutorial
I was looking through this, and have a suggestion as well: You have a line that reads In[10]: plt.hist(lum_img) This should probably be plt.hist(lum_img.ravel(),bins=some larger number) As it is right now, you are making a histogram of each line individually, and my experience has been that this tends to cause issues (memory and confusion-related) with relatively large images. On Wed, Sep 2, 2009 at 6:42 AM, Michael Sarahan mcsara...@ucdavis.edu wrote: Great suggestions. I'll find time to work on them in the near future, hopefully. -Mike On Sat, Aug 29, 2009 at 6:06 PM, Gary Rubengru...@bigpond.net.au wrote: Very nice addition Michael. I note that the plt.colormap() line must have gotten lost. It's referred to but not there. I'll add some ideas to John's list: * Demonstrate the imsave() command. * Rather than show 50 lines or so of array data, just show a few lines, but demonstrate what img.shape is before and after slicing out the B channel with img[:,:,0] * It may be worth mentioning explicitly that img[:,:,0] will give you the blue channel for an RGB and an RGBA image. * Demonstrate the upper and lower keywords where relevant. * Add a pointer to the scipy.ndimage module * Extend the examples with RGB and RGBA images. * You might like to show how to recarrays and views on the individual colour channels. There are examples in the mailing list archives or maybe on the scipy website - I can't remember where. * If you want to get more advanced, talk about higher bit depth images than 8 bits per channel. * If you want to get even more advanced, show how to change the UI to probe the pixel value (I wish matplotlib did this by default). Gary R. John Hunter wrote: On Sat, Aug 29, 2009 at 10:58 AM, Michael Sarahanmcsara...@ucdavis.edu wrote: Here you go. If you can think of anything else to include, I'll work on it. I think the next thing I'll add is something on embedding images in the corners of plots. figimage is the way to do this, right? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] crazy ideas for MPL
Personally, I think traits must be kept out of MPL, for three main reasons: 1. As Eric Bruning points out, while traits is a very powerful tool, it also closes a lot of doors by forcing everything to be written in a trait-like fashion for it to play nice with everything else. While this is great for many applications, I think it does not necessarily belong everywhere, particularly given a tendancy to quickly snowball in complexity (not to mention any new people that want to contribute code have an extra thick manual to read). 2. Installation of traits or traitsgui should not be a necessity for MPL... perhaps this will change in the future, but it's currently a far bigger task to get traits and traits UI working on an arbitrary system than it is to get MPL up and running (at least, that's been my experience in a number of different settings). 3. Chaco - my general mindset on this is that Chaco is great for plotting any and everything in a traits gui, but MPL is much better for the quickcalculations and plots that I make every day as a scientist. When a critical mass is reached it becomes better to integrate a tool into a GUI app, MPL becomes more difficult to manage and chaco is a better tool. But I think it makes a lot of sense to leverage MPL most as the wonderful quick-and-dirty command-line interactive plotting environment that it is rather than making it application-centric, which is where I can envision it going as soon as it has to run with traits. Now a great idea would be to include optional support for things like setting configuration files from a traits interface - I know I've seen talk of doing this for matplotlibrc at some point, and I'd definitely use that. Simlarly, some sort of traits-level extension to support more interactive plots and better layout seems like it could be done without requiring the core to use traits. As for the question of new directions to go: One thing I would like to see is a decent, simple 3D package in the core - nothing fancy (mayavi is great if you want to get fancy), but just something that makes great publication-quality figures with a quick and simple pylab-like interface. That's the main thing I have no good response for when people are contemplating switching to python/numpy/MPL. I also think it might be neat to implement auto-generating function plots - that is, plots where one of the axes is generated by a function at a resolution that scales as you change the plot. I've seen some chaco demos of something like this, but it's rather complicated to implement - a function like pyplot.plotfunc(func,'--b',initialrange=(-1,1)) that does exactly this would be a wonderful capability. This may be more a user perspective than a dev perspective, but still, there it is. On Thu, Jul 2, 2009 at 10:45 AM, Eric Bruningeric.brun...@gmail.com wrote: On Wed, Jul 1, 2009 at 9:51 PM, Andrew Strawstraw...@astraw.com wrote: Gael Varoquaux wrote: On Wed, Jul 01, 2009 at 08:39:30AM -0500, John Hunter wrote: Anyone interested? And if so, feel free to suggest topics or weigh in on some I listed. Actually, I have something I would like to discuss, but never really could pull myself together to do it. I don't have time right now, but I am still going to jot down the ideas. The axes and figure paradigm inherited from matlab works well for simple things, but when I want to more complex layouts, I actually end up struggling with calls to axes with numerical parameters to adjust. In addition, if I have a function that creates a plot with multiple axes, like the figure on: http://neuroimaging.scipy.org/site/doc/manual/html/neurospin/activation_map.html I may want to reuse that function to create more complex figures, stacking several of these views, with possibly other plots. It seems to me having a level of granularity between the figure, and the axes would help me a lot achieving these goals. I haven't had time to hash out an API, or even solid concepts. For people who know LaTeX well, let me draw an analogy: the figure is the page, the axis is the character, what we are lacking in a 'minipage'. I would like a container that can be stacked into a figure, and that can either hold axes, or similar containers. That way, I could specify subplot, or axis relative to this container, rather than relative to the whole figure, and it makes it really easy for me to insert figures in larger figures. One possible API would be 'subfigure', which would have a signature similar to 'axes', but of course things would need to be thought a bit more in detail: do we want clf to erase the figure and not the subfigure? I believe so. Do we want subplot to divide the subfigure, rather than the figure? I believe so too. How do we go back to full figure without erasing the subfigures it contains? I think subfigure(None) might work. How do I select a subfigure I already created? Maybe by passing it a subfigure instance, like the way axes work. Also, Chaco
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
Patch against today's svn is attached. Sorry for the long delay... Right now, scatterpoints is just set to 3 in Legend.__init__, but presumably that should be an rcParam... On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee [EMAIL PROTECTED] wrote: Sorry Erik. Can you make a new patch against the current SVN? Some of the patch was applied (but without scatterpoints option) in the SVN. Thanks, -JJ On Thu, Oct 30, 2008 at 1:58 PM, Erik Tollerud [EMAIL PROTECTED] wrote: No more thoughts on this? Or was some version of the patch committed? On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud [EMAIL PROTECTED] wrote: Actually, looking more closely, there is one thing that's still bothering me: as it is now, it's impossible to have, say, 2 points for plotted values, and 3 points for scatter plots on the same legend (you have to give a numpoints=# command that's shared by everything in the legend, if I'm understanding it). It'd be nice to have a property, say, scatterpoints (and presumably then an associated rcParam legend.scatterpoints ) that sets the number of points to use for scatter plots. That way, I can make plots just like in the original form, but it can also be the same number for both if so desired. I've attached a patch based on the last one that does this, although it probably needs to be changed to allow for an rcParam 'legend.scatterplot' (I don't really know the procedure for adding a new rcParam). On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud [EMAIL PROTECTED] wrote: The current patch looks good to me... it satisfies all the use cases I had in mind, and I can't think of much else that would be wanted. Thanks! I also very much like the idea of the sizebar, although that's probably a substantially larger job to implement. I may look into it though, time permitting... On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote: To help clarify the original purpose of update_from: I wrote this method when writing the original legend implementation so the legend proxy objects could easily copy their style attributes from the underlying objects they were a proxy for (so not every property is copied, eg the xdata for line objects is not copied). So the operating question should be: what properties do I need to copy to make the legend representation of the object. While you are in there, perhaps you could clarify this in the docstrings of the update_from method. Thanks for clarifying this, John. Manuel, The patch looks good to me. We may submit the patch (I hope Erik is okay with the current patch) and it would be great if you handle the submission. -JJ On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz [EMAIL PROTECTED] wrote: Jae-Joon Lee wrote: Thanks Manuel. Yes, we need rotation value and etc, but my point is, do we need to update it within the update_from() method? Although my preference is not to do it, it may not matter much as far as we state what this method does clearly in the doc. Okay, it's probably better to create the object correctly (numsides ...) instead of copying the properties (see also JDHs mail !) And, in your patch, I don't think updating the numsides value has any effect as it does not recreate the paths. I'm attaching the revised patch. In this patch, update_from() only update gc-related properties. And numsides, size, and rotations are given during the object creation time. Yes, this looks better. But creating handle_sizes is a little bit too much effort. This is done internally. It will do passing a sizes list, that may or may not be shorter/longer than numpoints (see revised patch). I also changed the way the yoffsets are updated in _update_positions(). One additional thing I have in mind (for a later time) is a sizesbar similar to a colorbar where you can read off values corresponding to marker sizes... Cheers, Manuel Erik, I see your points. My main concern is that the yoffsets makes the results a bit funny when numpoints is 2. The attached patch has a varying sizes of [0.5*(max+min), max, min]. The yoffsets are only introduced when numpints 2 and you can also provide it as an optional argument. Regards, -JJ On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz [EMAIL PROTECTED] wrote: Manuel Metz wrote: Jae-Joon Lee wrote: Hi Manuel, I think it is a good to introduce the update_from method in Collections. But, I'm not sure if it is a good idea to also update sizes, paths and rotation (in RegularPolyCoolection). My impression is that update_from method is to update gc related attributes. For comparison, Patch.update_from() does not update the path. That's exactly the point why I wasn't fully happy with the patch. The path is generated by the _path_generator, so instead of copying the path it seems to be better to create an instance of the corresponding class (e.g. the StarPolygonCollection class, as suggested before). One should update
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
The current patch looks good to me... it satisfies all the use cases I had in mind, and I can't think of much else that would be wanted. Thanks! I also very much like the idea of the sizebar, although that's probably a substantially larger job to implement. I may look into it though, time permitting... On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote: To help clarify the original purpose of update_from: I wrote this method when writing the original legend implementation so the legend proxy objects could easily copy their style attributes from the underlying objects they were a proxy for (so not every property is copied, eg the xdata for line objects is not copied). So the operating question should be: what properties do I need to copy to make the legend representation of the object. While you are in there, perhaps you could clarify this in the docstrings of the update_from method. Thanks for clarifying this, John. Manuel, The patch looks good to me. We may submit the patch (I hope Erik is okay with the current patch) and it would be great if you handle the submission. -JJ On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz [EMAIL PROTECTED] wrote: Jae-Joon Lee wrote: Thanks Manuel. Yes, we need rotation value and etc, but my point is, do we need to update it within the update_from() method? Although my preference is not to do it, it may not matter much as far as we state what this method does clearly in the doc. Okay, it's probably better to create the object correctly (numsides ...) instead of copying the properties (see also JDHs mail !) And, in your patch, I don't think updating the numsides value has any effect as it does not recreate the paths. I'm attaching the revised patch. In this patch, update_from() only update gc-related properties. And numsides, size, and rotations are given during the object creation time. Yes, this looks better. But creating handle_sizes is a little bit too much effort. This is done internally. It will do passing a sizes list, that may or may not be shorter/longer than numpoints (see revised patch). I also changed the way the yoffsets are updated in _update_positions(). One additional thing I have in mind (for a later time) is a sizesbar similar to a colorbar where you can read off values corresponding to marker sizes... Cheers, Manuel Erik, I see your points. My main concern is that the yoffsets makes the results a bit funny when numpoints is 2. The attached patch has a varying sizes of [0.5*(max+min), max, min]. The yoffsets are only introduced when numpints 2 and you can also provide it as an optional argument. Regards, -JJ On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz [EMAIL PROTECTED] wrote: Manuel Metz wrote: Jae-Joon Lee wrote: Hi Manuel, I think it is a good to introduce the update_from method in Collections. But, I'm not sure if it is a good idea to also update sizes, paths and rotation (in RegularPolyCoolection). My impression is that update_from method is to update gc related attributes. For comparison, Patch.update_from() does not update the path. That's exactly the point why I wasn't fully happy with the patch. The path is generated by the _path_generator, so instead of copying the path it seems to be better to create an instance of the corresponding class (e.g. the StarPolygonCollection class, as suggested before). One should update the rotation attribute (!!); it's only one number. A '+' marker, for example, has rotation = 0, whereas a 'x' marker has rotation=pi/4. That's the only difference between those two ! Also, is it okay to update properties without checking its length?. It does not seem to cause any problems though. It's in principal not a problem to copy the sizes attribute without checking the length. If it's shorter the the number of items the sizes are repeated; if it's longer it gets truncated. mm I guess It would better to use xdata_markers than xdata in the get_handle() method. The difference is when numpoints==1. Using xdata gives two marker points. I was actually about to to commit my patch. I'll try to account your changes and post my version of patch later today. Regards, -JJ On Wed, Oct 15, 2008 at 4:07 PM, Manuel Metz [EMAIL PROTECTED] wrote: hmm Original Message Jae-Joon Lee wrote: - the parameter numpoints should be used (it's ignored right now) Thanks Manuel. I guess we can simply reuse xdata_marker for this purpose. - Some private variables are accessed and a new RegularPolycollection is created (does this work eg. with a StarPolygonCollection? I haven't checked, but I don't think so !). Instead of creating a new RegularPolyCollection it might be more useful to make a copy of the existing object... I was thinking about a update_from() method for the Collection class(es) similar to update_from() for lines. By changing RegularPolyCoolection to type(handles), it
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
Actually, looking more closely, there is one thing that's still bothering me: as it is now, it's impossible to have, say, 2 points for plotted values, and 3 points for scatter plots on the same legend (you have to give a numpoints=# command that's shared by everything in the legend, if I'm understanding it). It'd be nice to have a property, say, scatterpoints (and presumably then an associated rcParam legend.scatterpoints ) that sets the number of points to use for scatter plots. That way, I can make plots just like in the original form, but it can also be the same number for both if so desired. I've attached a patch based on the last one that does this, although it probably needs to be changed to allow for an rcParam 'legend.scatterplot' (I don't really know the procedure for adding a new rcParam). On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud [EMAIL PROTECTED] wrote: The current patch looks good to me... it satisfies all the use cases I had in mind, and I can't think of much else that would be wanted. Thanks! I also very much like the idea of the sizebar, although that's probably a substantially larger job to implement. I may look into it though, time permitting... On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote: To help clarify the original purpose of update_from: I wrote this method when writing the original legend implementation so the legend proxy objects could easily copy their style attributes from the underlying objects they were a proxy for (so not every property is copied, eg the xdata for line objects is not copied). So the operating question should be: what properties do I need to copy to make the legend representation of the object. While you are in there, perhaps you could clarify this in the docstrings of the update_from method. Thanks for clarifying this, John. Manuel, The patch looks good to me. We may submit the patch (I hope Erik is okay with the current patch) and it would be great if you handle the submission. -JJ On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz [EMAIL PROTECTED] wrote: Jae-Joon Lee wrote: Thanks Manuel. Yes, we need rotation value and etc, but my point is, do we need to update it within the update_from() method? Although my preference is not to do it, it may not matter much as far as we state what this method does clearly in the doc. Okay, it's probably better to create the object correctly (numsides ...) instead of copying the properties (see also JDHs mail !) And, in your patch, I don't think updating the numsides value has any effect as it does not recreate the paths. I'm attaching the revised patch. In this patch, update_from() only update gc-related properties. And numsides, size, and rotations are given during the object creation time. Yes, this looks better. But creating handle_sizes is a little bit too much effort. This is done internally. It will do passing a sizes list, that may or may not be shorter/longer than numpoints (see revised patch). I also changed the way the yoffsets are updated in _update_positions(). One additional thing I have in mind (for a later time) is a sizesbar similar to a colorbar where you can read off values corresponding to marker sizes... Cheers, Manuel Erik, I see your points. My main concern is that the yoffsets makes the results a bit funny when numpoints is 2. The attached patch has a varying sizes of [0.5*(max+min), max, min]. The yoffsets are only introduced when numpints 2 and you can also provide it as an optional argument. Regards, -JJ On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz [EMAIL PROTECTED] wrote: Manuel Metz wrote: Jae-Joon Lee wrote: Hi Manuel, I think it is a good to introduce the update_from method in Collections. But, I'm not sure if it is a good idea to also update sizes, paths and rotation (in RegularPolyCoolection). My impression is that update_from method is to update gc related attributes. For comparison, Patch.update_from() does not update the path. That's exactly the point why I wasn't fully happy with the patch. The path is generated by the _path_generator, so instead of copying the path it seems to be better to create an instance of the corresponding class (e.g. the StarPolygonCollection class, as suggested before). One should update the rotation attribute (!!); it's only one number. A '+' marker, for example, has rotation = 0, whereas a 'x' marker has rotation=pi/4. That's the only difference between those two ! Also, is it okay to update properties without checking its length?. It does not seem to cause any problems though. It's in principal not a problem to copy the sizes attribute without checking the length. If it's shorter the the number of items the sizes are repeated; if it's longer it gets truncated. mm I guess It would better to use xdata_markers than xdata in the get_handle() method. The difference is when numpoints==1. Using xdata gives two marker
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for scatter plot legend enhancement
Ah, that makes more sense Jae-Joon - thanks! With this addition it all looks fine to me - I've attached a patch against 6174 that does everything I'd like to see it do... note that I've left in the TODO in collections.py simply because I still am not certain that what I'm doing there is correct in all use-cases... On Mon, Oct 6, 2008 at 11:22 PM, Jae-Joon Lee [EMAIL PROTECTED] wrote: Hi Eric, As far as I know, get_window_extent is meant to return the extent of the object in the display coordinate. And, as you may have noticed, often this is used to calculate the relative position of objects. I quickly went through your patch and my guess is your implementation of get_window_extent is correct in this regard, but I haven't considered this seriously so I may be wrong. On the other hand, I guess the original problem you had is not related with the get_window_extents() method. The legend class has a _update_positions() method which is called before the legends are drawn. And you have to update positions of your handles within this method. In the simple patch below. I tried to implement some basic update code for the polycollections ( I also slightly adjusted the y-offsets. This is just my personal preference). See if this patch works for you. Regards, -JJ Index: lib/matplotlib/legend.py === --- lib/matplotlib/legend.py(revision 6163) +++ lib/matplotlib/legend.py(working copy) @@ -532,6 +540,12 @@ elif isinstance(handle, Rectangle): handle.set_y(y+1/4*h) handle.set_height(h/2) +elif isinstance(handle, RegularPolyCollection): +offsets = handle.get_offsets() +xvals = [x for (x, _) in offsets] +yy = y + h +yvals=[yy-4./8*h,yy-3./8*h,yy-4./8*h] +handle.set_offsets(zip(xvals, yvals)) # Set the data for the legend patch bbox = self._get_handle_text_bbox(renderer) On Tue, Oct 7, 2008 at 12:15 AM, Erik Tollerud [EMAIL PROTECTED] wrote: Does anyone have anything new here? I'm perfectly willing to experiment, but I'm really at a loss as to what get_window_extent(self,render) is supposed to do (clearly get some window extent, but exactly what window and what coordinates the extent is in is what is confusing me). On Tue, Sep 23, 2008 at 11:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud [EMAIL PROTECTED] wrote: Attached is a diff against revision 6115 that contains a patch to improve the behavior of the legend function when showing legends for Erik, I haven't had a chance to get to this yet. Could you please also post it on the sf patch tracker so it doesn't get dropped, and ping us with a reminder in a few days if nothing has happened JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 [EMAIL PROTECTED] Index: lib/matplotlib/legend.py === --- lib/matplotlib/legend.py (revision 6174) +++ lib/matplotlib/legend.py (working copy) @@ -306,18 +306,26 @@ ret.append(legline) elif isinstance(handle, RegularPolyCollection): -if self.numpoints == 1: -xdata = np.array([left]) -p = Rectangle(xy=(min(xdata), y-3/4*HEIGHT), - width = self.handlelen, height=HEIGHT/2, - ) -p.set_facecolor(handle._facecolors[0]) -if handle._edgecolors != 'none' and len(handle._edgecolors): -p.set_edgecolor(handle._edgecolors[0]) -self._set_artist_props(p) -p.set_clip_box(None) -p.set_clip_path(None) -ret.append(p) +xvals=[min(xdata),min(xdata)+self.handlelen/2,min(xdata)+self.handlelen] +yvals=[y-3/4*HEIGHT,y-1/4*HEIGHT,y-3/4*HEIGHT] +nverts=handle.get_paths()[0].vertices.shape[0]-1 +szs=[min(handle._sizes),max(handle._sizes)] +szs.insert(1,(szs[0]+szs[1])/2) +rpc = RegularPolyCollection(nverts
Re: [matplotlib-devel] Patch for scatter plot legend enhancement
Does anyone have anything new here? I'm perfectly willing to experiment, but I'm really at a loss as to what get_window_extent(self,render) is supposed to do (clearly get some window extent, but exactly what window and what coordinates the extent is in is what is confusing me). On Tue, Sep 23, 2008 at 11:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud [EMAIL PROTECTED] wrote: Attached is a diff against revision 6115 that contains a patch to improve the behavior of the legend function when showing legends for Erik, I haven't had a chance to get to this yet. Could you please also post it on the sf patch tracker so it doesn't get dropped, and ping us with a reminder in a few days if nothing has happened JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for scatter plot legend enhancement
Sorry for the dealyed reply - I've been out of town... I posted to the patch tracker, and am dutifully pinging :) On Tue, Sep 23, 2008 at 11:41 AM, John Hunter [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2008 at 12:20 AM, Erik Tollerud [EMAIL PROTECTED] wrote: Attached is a diff against revision 6115 that contains a patch to improve the behavior of the legend function when showing legends for Erik, I haven't had a chance to get to this yet. Could you please also post it on the sf patch tracker so it doesn't get dropped, and ping us with a reminder in a few days if nothing has happened JDH - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] A few more proposed hist() changes
While going through and updating some scripts to use the new features
that were recently added to hist(), I found myself very confused by
the align keywords - I had to go and look at Manuel Metz's post a
couple weeks ago to believe it wasn't a typo in the documentation...
center and edge are exactly the opposite of what one would have
thought (as he noted)... I've attached a diff of my proposed solution
- accepting the old keywords for backwards-compatibility, but have the
documentation only mention two keywords that make more sense ('left'
and 'mid').
I've added two other features as well - for some of the histograms I'm
making, it makes sense to have plots that are cumulative from the left
instead of the right - with this patch, that's allowed by passing in
cumulative=-1 (or anything else that is less than 0 - True still
operates the way it did before). To make this also easier from the
perspective of how some might want the histogram to look, I've also
added a 'right' option to the 'align' keyword.
Hopefully these changes will now satisfy all possible uses that anyone
can imagine for a histogram. :)
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5368)
+++ lib/matplotlib/axes.py (working copy)
@@ -5592,7 +5592,7 @@
def hist(self, x, bins=10, normed=False, cumulative=False,
- bottom=None, histtype='bar', align='edge',
+ bottom=None, histtype='bar', align='mid',
orientation='vertical', rwidth=None, log=False, **kwargs):
call signature::
@@ -5628,6 +5628,10 @@
The last bin gives the total number of datapoints. If normed is
also True then the histogram is normalized such that the last bin
equals one.
+If a value that evaluates to less that one (e.g. -1), the
+direction of accumulation is reversed. In this case, If normed is
+also True then the histogram is normalized such that the first bin
+equals one.
histtype:
[ 'bar' | 'barstacked' | 'step' ] The type of histogram
@@ -5636,9 +5640,10 @@
stacked on top of each other, and 'step' generates a lineplot.
align:
-['edge' | 'center' ] Controles how the histogram is plotted.
-If 'edge', bars are centered between the bin edges.
-If 'center', bars are centered on the left bin edges
+['left' | 'mid' | 'right' ] Controles how the histogram is plotted.
+If 'left', bars are centered on the left bin edges.
+If 'mid', bars are centered between the bin edges.
+If 'right', bars are centered on the right bin edges.
orientation:
[ 'horizontal' | 'vertical' ] If horizontal, barh will be used
@@ -5688,10 +5693,15 @@
n = [n,]
if cumulative:
-if normed:
-n = [(m * np.diff(bins)).cumsum() for m in n]
-else:
-n = [m.cumsum() for m in n]
+ if cumulative 0:
+ slc=slice(None,None,-1)
+ else:
+ slc=slice(None)
+
+ if normed:
+ n = [(m * np.diff(bins))[slc].cumsum()[slc] for m in n]
+ else:
+ n = [m[slc].cumsum()[slc] for m in n]
ccount = 0
colors = _process_plot_var_args.defaultColors[:]
@@ -5721,9 +5731,13 @@
else:
raise ValueError, 'invalid histtype: %s' % histtype
-if align=='edge':
+if align == 'mid' or align=='edge':
boffset += 0.5*totwidth
-elif align != 'center':
+elif align == 'left' or align == 'center':
+pass #TODO?
+elif align == 'right':
+boffset += totwidth
+else:
raise ValueError, 'invalid align: %s' % align
if orientation == 'horizontal':
@@ -5758,10 +5772,14 @@
y = np.zeros( 2*len(bins), np.float_ )
x[0::2], x[1::2] = bins, bins
-
-if align == 'center':
+
+if align == 'mid' or align=='edge':
+pass
+elif align == 'left' or align == 'center':
x -= 0.5*(bins[1]-bins[0])
-elif align != 'edge':
+elif align == 'right':
+x -= (bins[1]-bins[0])
+else:
raise ValueError, 'invalid align: %s' % align
if log:
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] fix for errorbar method skipping over plot color cycle
It'd be nice to get this into the new release unless it has been somehow fixed by some other code path in the latest svn... the line numbers on the diff are no longer accurate, but the idea is still the same - just change all lines of the form caplines.extend( self.plot(leftlo, ylo,ls=None, marker=mlines.CARETLEFT, **plot_kw) ) to caplines.extend( self.plot(leftlo, ylo, 'k|', marker=mlines.CARETLEFT, **plot_kw) ) e.g. change the ls=None to 'k|' and the color cycle is not interrupted. I don't have the 1.1 numpy yet, so I haven't explicitly tested it, but I don't see why anything would have changed... On Tue, Feb 12, 2008 at 10:46 PM, Erik Tollerud [EMAIL PROTECTED] wrote: After a little testing on the subversion repository, the attached diff seems to work. On Feb 10, 2008 12:12 AM, Erik Tollerud [EMAIL PROTECTED] wrote: I noticed while making some plots with upper bound error bars that whenever Axes.errorbars is called with any of the errorbars chosen as upper or lower bounds, that the color cycle was off, skipping over 2 colors each time another errorbar plot was made (e.g. the first would be green and the second would be cyan instead of blue,green,red,cyan). Looking into the axes class, it appears that if you don't specify a color and want the markers to be drawn over the errorbars, the color cycle has already been skipped over one because of calls to draw the markers into the plot. The solution is to change all the lines that say ls='None' in the errorbar method to instead say ls='k' - this will prevent those calls from cycling the colors, and hence only the call to actually draw the markers will do so. Can this patch be committed to svn? -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 4155B Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2996 Cell: (651)307-9409 [EMAIL PROTECTED] -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 2142 Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2587 Cell: (651)307-9409 [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Improved histogram w/multiple types
No one thinks this is worth committing to SVN? I find myself using it quite a bit in my own work - different fields have different ideas about the right way to draw a histogram, so it's good to have options, I think... On Wed, Apr 2, 2008 at 4:39 PM, Erik Tollerud [EMAIL PROTECTED] wrote: I've made some alterations to the hist() function in axes.py (attached is a diff against the current SVN version). I've added the capability to use the same interface to make outline histograms instead of bar histograms (and a third option for outlines with fill - note that this is NOT the same as calling it twice with the other two, as the widths are slightly different). There's a slight compatibility issue in that as it stands in that the returned tuple now has 4 values (I added a list of the lines that are generated if the steps command is used), but I can't really imagine how that could break anything but the poorest-written code... Anyone think this is worth committing to SVN? (One thing that bothers me a little is the part of the code that adds the last two edges to the histogram - the problem is that if you have a line size greater than 1, the outline overshoots the rest of the outline by a very tiny bit... if anyone knows how to cut off the upper row of pixels to make it flush with the rest of the outline... it's perfectly usable as-is, though - that's just a tiny little aesthetic quibble) -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 4155B Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2996 Cell: (651)307-9409 [EMAIL PROTECTED] - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Improved histogram w/multiple types
I've made some alterations to the hist() function in axes.py (attached
is a diff against the current SVN version). I've added the capability
to use the same interface to make outline histograms instead of bar
histograms (and a third option for outlines with fill - note that this
is NOT the same as calling it twice with the other two, as the widths
are slightly different). There's a slight compatibility issue in that
as it stands in that the returned tuple now has 4 values (I added a
list of the lines that are generated if the steps command is used),
but I can't really imagine how that could break anything but the
poorest-written code... Anyone think this is worth committing to SVN?
(One thing that bothers me a little is the part of the code that adds
the last two edges to the histogram - the problem is that if you have
a line size greater than 1, the outline overshoots the rest of the
outline by a very tiny bit... if anyone knows how to cut off the upper
row of pixels to make it flush with the rest of the outline... it's
perfectly usable as-is, though - that's just a tiny little aesthetic
quibble)
--
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
[EMAIL PROTECTED]
Index: lib/matplotlib/axes.py
===
--- lib/matplotlib/axes.py (revision 5027)
+++ lib/matplotlib/axes.py (working copy)
@@ -5168,15 +5168,14 @@
Data analysis
-
-
-def hist(self, x, bins=10, normed=0, bottom=None,
+
+def hist(self, x, bins=10, normed=0, bottom=None, histtype='bar',
align='edge', orientation='vertical', width=None,
- log=False, **kwargs):
+ log=False, lineprops={},**kwargs):
-HIST(x, bins=10, normed=0, bottom=None,
+HIST(x, bins=10, normed=0, bottom=None, histtype='bar',
align='edge', orientation='vertical', width=None,
- log=False, **kwargs)
+ log=False, lineprops={},**kwargs)
Compute the histogram of x. bins is either an integer number of
bins or a sequence giving the bins. x are the data to be binned.
@@ -5192,6 +5191,10 @@
# trapezoidal integration of the probability density function
pdf, bins, patches = ax.hist(...)
print npy.trapz(pdf, bins)
+
+histtype = 'bar' | 'step' | 'stepfill'. The type of histogram
+to draw - 'bar' is a traditional bar-type histogram, 'step'
+generates a lineplot
align = 'edge' | 'center'. Interprets bins either as edge
or center values
@@ -5200,28 +5203,103 @@
will be used and the bottom kwarg will be the left edges.
width: the width of the bars. If None, automatically compute
-the width.
+the width. Ignored for 'step' type.
log: if True, the histogram axis will be set to a log scale
+
+lineprops: a mapping to update the properties of the line
+for the 'step' or 'stepfill' type.
+%(Line2D)s
kwargs are used to update the properties of the
-hist Rectangles:
+hist Rectangles for 'bar' or 'stepfill' type.
%(Rectangle)s
if not self._hold: self.cla()
n, bins = npy.histogram(x, bins, range=None, normed=normed)
-if width is None: width = 0.9*(bins[1]-bins[0])
-if orientation == 'horizontal':
-patches = self.barh(bins, n, height=width, left=bottom,
-align=align, log=log)
-elif orientation == 'vertical':
-patches = self.bar(bins, n, width=width, bottom=bottom,
-align=align, log=log)
+if width is None:
+if 'step' in histtype:
+width = (bins[1]-bins[0])
+kwargs['lw']=0 #make the fill lines non-existent
+else:
+width = 0.9*(bins[1]-bins[0])
+if 'step' in histtype:
+if orientation == 'horizontal':
+if align=='edge':
+lines=self.plot(npy.concatenate((n[-1:],n)),
+npy.concatenate((bins,bins[-1:]+width)),
+ls='steps-post')
+#add lines for the right and left edges
+lines.append(mlines.Line2D([0,n[0]],[bins[0],bins[0]]))
+lines[-1].update_from(lines[0])
+lines[-1].set_ls('-')
+self.add_line(lines[-1])
+lines.append(mlines.Line2D([0,n[-1]],[bins[-1:]+width,bins[-1:]+width]))
+lines[-1].update_from(lines[0])
+lines[-1].set_ls('-')
+self.add_line(lines[-1])
+else:
+lines=self.plot(npy.concatenate((n[-1
Re: [matplotlib-devel] Unnecessary rerendering in wx/wxagg backends
I tested this on 0.91.2 on Ubuntu Gutsy, and wx 2.8.7.1, and found that when I bring up a new window, I see a black canvas and it doesn't draw any of the matplotlib objects until I do something like resizing that must explicitly call a draw at some point. This may be why it's in there... perhaps some sort of checking to see if any draw has been performed yet? On Mon, Mar 31, 2008 at 7:58 AM, Gregor Thalhammer [EMAIL PROTECTED] wrote: Dear developers, I discovered that in backend_wx.py in _onPaint(), the callback function for repainting a matplotlib figure, every time a repaint is done also the bitmap is rerendered: backend_wx.py/_onPaint(): ... # Render to the bitmap self.draw(repaint=False) ... This also affects the behaviour of the wxagg backend. Rerendering and therefore also repainting gets quite slow if, e.g., images are included in the figure. I can see this by simply dragging another window across the matplotlibfigure. Commenting out the rerendering I get a much smoother behaviour. I could not observe problems except that sometimes some parts of the figure are not properly repainted if the matplotlib figure is in the background (I only tested the wxagg backend). Therefore it seems that this rerendering every time a repaint is performed is not really necessary and should be avoided. I tested this on matplotlib 0.91.2 on WinXP, Python 2.5, wx 2.8.7. I checked that in the current svn version the _onPaint() function is unchanged. Gregor - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 4155B Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2996 Cell: (651)307-9409 [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Patch for making SpanSelector usable in embedded matplotlib
You're absolutely correct - I wrote the original patch against 91.2,
and forgot to test it against the new trunk. Below is a new patch
that HAS been tested against the trunk version. It includes another
fix for some API changes in the Rectangle object. Note that there's
also a fix in the RectangleSelector to prevent it from raising an
exception under the new API.
I've also noticed that both the SpanSelector and RectangleSelector
don't seem to draw the rectangle with useblit=False on my machine -
I'm only using useblit=True, though, and it works fine there with the
alterations in this patch.
Index: widgets.py
===
--- widgets.py (revision 4953)
+++ widgets.py (working copy)
@@ -827,16 +827,14 @@
assert direction in ['horizontal', 'vertical'], 'Must choose
horizontal or vertical for direction'
self.direction = direction
-self.ax = ax
+self.ax = None
+self.canvas = None
self.visible = True
-self.canvas = ax.figure.canvas
-self.canvas.mpl_connect('motion_notify_event', self.onmove)
-self.canvas.mpl_connect('button_press_event', self.press)
-self.canvas.mpl_connect('button_release_event', self.release)
-self.canvas.mpl_connect('draw_event', self.update_background)
+self.cids=[]
self.rect = None
self.background = None
+self.pressv = None
self.rectprops = rectprops
self.onselect = onselect
@@ -847,8 +845,23 @@
# Needed when dragging out of axes
self.buttonDown = False
self.prev = (0, 0)
-
-if self.direction == 'horizontal':
+
+self.new_axes(ax)
+
+
+def new_axes(self,ax):
+self.ax = ax
+if self.canvas is not ax.figure.canvas:
+for cid in self.cids:
+self.canvas.mpl_disconnect(cid)
+
+self.canvas = ax.figure.canvas
+
+self.cids.append(self.canvas.mpl_connect('motion_notify_event',
self.onmove))
+self.cids.append(self.canvas.mpl_connect('button_press_event',
self.press))
+ self.cids.append(self.canvas.mpl_connect('button_release_event',
self.release))
+ self.cids.append(self.canvas.mpl_connect('draw_event',
self.update_background))
+ if self.direction == 'horizontal':
trans = blended_transform_factory(self.ax.transData,
self.ax.transAxes)
w,h = 0,1
else:
@@ -859,9 +872,8 @@
visible=False,
**self.rectprops
)
-
+
if not self.useblit: self.ax.add_patch(self.rect)
-self.pressv = None
def update_background(self, event):
'force an update of the background'
@@ -931,10 +943,10 @@
minv, maxv = v, self.pressv
if minvmaxv: minv, maxv = maxv, minv
if self.direction == 'horizontal':
-self.rect.xy[0] = minv
+self.rect.set_x(minv)
self.rect.set_width(maxv-minv)
else:
-self.rect.xy[1] = minv
+self.rect.set_y(minv)
self.rect.set_height(maxv-minv)
if self.onmove_callback is not None:
@@ -1155,8 +1167,8 @@
miny, maxy = self.eventpress.ydata, y # click-y and actual mouse-y
if minxmaxx: minx, maxx = maxx, minx # get them in the right order
if minymaxy: miny, maxy = maxy, miny
-self.to_draw.xy[0] = minx # set lower left of box
-self.to_draw.xy[1] = miny
+self.to_draw.set_x(minx) # set lower left of box
+self.to_draw.set_y(miny)
self.to_draw.set_width(maxx-minx) # set width and height of box
self.to_draw.set_height(maxy-miny)
self.update()
On Feb 11, 2008 7:48 AM, John Hunter [EMAIL PROTECTED] wrote:
On Feb 10, 2008 5:12 PM, Erik Tollerud [EMAIL PROTECTED] wrote:
I've been working on an application that uses matplotlib as its
plotting library, and I've been noticing a steady decrease in
It looks like there is some confusion in your patch vis-a-vis the
migration from the old matplotlib transformation architecture (no on a
branch) to the new (now in the trunk). I'm attaching the migration
document. For example, your patch removes
blended_transform_factory lines (new transforms call on the trunk) and
adds blend_xy_sep_transform lines (old transforms call on the 0.91
maintenance branch).
You can patch either the maintenance branch or the trunk or both, but
I think the patch as submitted is a little mixed up if I am reading
this correctly.
JDH
--
Erik Tollerud
Graduate Student
Center For Cosmology
Department of Physics and Astronomy
4155B Frederick Reines Hall
University of California, Irvine
Office Phone: (949)824-2996
Cell: (651)307-9409
[EMAIL PROTECTED]
Index: widgets.py
Re: [matplotlib-devel] fix for errorbar method skipping over plot color cycle
After a little testing on the subversion repository, the attached diff seems to work. On Feb 10, 2008 12:12 AM, Erik Tollerud [EMAIL PROTECTED] wrote: I noticed while making some plots with upper bound error bars that whenever Axes.errorbars is called with any of the errorbars chosen as upper or lower bounds, that the color cycle was off, skipping over 2 colors each time another errorbar plot was made (e.g. the first would be green and the second would be cyan instead of blue,green,red,cyan). Looking into the axes class, it appears that if you don't specify a color and want the markers to be drawn over the errorbars, the color cycle has already been skipped over one because of calls to draw the markers into the plot. The solution is to change all the lines that say ls='None' in the errorbar method to instead say ls='k' - this will prevent those calls from cycling the colors, and hence only the call to actually draw the markers will do so. Can this patch be committed to svn? -- Erik Tollerud Graduate Student Center For Cosmology Department of Physics and Astronomy 4155B Frederick Reines Hall University of California, Irvine Office Phone: (949)824-2996 Cell: (651)307-9409 [EMAIL PROTECTED] Index: axes.py === --- axes.py (revision 4957) +++ axes.py (working copy) @@ -3880,7 +3880,7 @@ # y are lists leftlo, ylo = xywhere(left, y, xlolims) -caplines.extend( self.plot(leftlo, ylo, ls='None', marker=mlines.CARETLEFT, **plot_kw) ) +caplines.extend( self.plot(leftlo, ylo, 'k|', marker=mlines.CARETLEFT, **plot_kw) ) xlolims = ~xlolims leftlo, ylo = xywhere(left, y, xlolims) caplines.extend( self.plot(leftlo, ylo, 'k|', **plot_kw) ) @@ -3890,7 +3890,7 @@ if xuplims.any(): rightup, yup = xywhere(right, y, xuplims) -caplines.extend( self.plot(rightup, yup, ls='None', marker=mlines.CARETRIGHT, **plot_kw) ) +caplines.extend( self.plot(rightup, yup, 'k|', marker=mlines.CARETRIGHT, **plot_kw) ) xuplims = ~xuplims rightup, yup = xywhere(right, y, xuplims) caplines.extend( self.plot(rightup, yup, 'k|', **plot_kw) ) @@ -3912,7 +3912,7 @@ if lolims.any(): xlo, lowerlo = xywhere(x, lower, lolims) -caplines.extend( self.plot(xlo, lowerlo, ls='None', marker=mlines.CARETDOWN, **plot_kw) ) +caplines.extend( self.plot(xlo, lowerlo, 'k_', marker=mlines.CARETDOWN, **plot_kw) ) lolims = ~lolims xlo, lowerlo = xywhere(x, lower, lolims) caplines.extend( self.plot(xlo, lowerlo, 'k_', **plot_kw) ) @@ -3922,7 +3922,7 @@ if uplims.any(): xup, upperup = xywhere(x, upper, uplims) -caplines.extend( self.plot(xup, upperup, ls='None', marker=mlines.CARETUP, **plot_kw) ) +caplines.extend( self.plot(xup, upperup, 'k_', marker=mlines.CARETUP, **plot_kw) ) uplims = ~uplims xup, upperup = xywhere(x, upper, uplims) caplines.extend( self.plot(xup, upperup, 'k_', **plot_kw) ) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] fix for errorbar method skipping over plot color cycle
I noticed while making some plots with upper bound error bars that whenever Axes.errorbars is called with any of the errorbars chosen as upper or lower bounds, that the color cycle was off, skipping over 2 colors each time another errorbar plot was made (e.g. the first would be green and the second would be cyan instead of blue,green,red,cyan). Looking into the axes class, it appears that if you don't specify a color and want the markers to be drawn over the errorbars, the color cycle has already been skipped over one because of calls to draw the markers into the plot. The solution is to change all the lines that say ls='None' in the errorbar method to instead say ls='k' - this will prevent those calls from cycling the colors, and hence only the call to actually draw the markers will do so. Can this patch be committed to svn? - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
