Re: [matplotlib-devel] Improved histogram w/multiple types
Erik Tollerud wrote: > 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 Hi Erik, thanks for the reminder. If no one else does ... I will have a look at your patch. Would be a good idea to provide an adequate example, but that should be no problem. Manuel - 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
Re: [matplotlib-devel] Improved histogram w/multiple types
Manuel Metz wrote: > Erik Tollerud wrote: >> 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 > > Hi Erik, > >thanks for the reminder. If no one else does ... I will have a look > at your patch. Would be a good idea to provide an adequate example, but > that should be no problem. > > Manuel Manuel, Spurred by Erik's reminder, I started looking at it, but I am badly distracted and short of time, and so it would be great if you can take it from here. Scanning the patch, I wondered whether it could be done more concisely (probably not much, if any), and whether it would make sense to use the "fill" method for the "stepfill" form; it appears that at present it is using regular bar patches for the filling. But if it works as-is maybe it's fine. The idea of offering a step-plot version seems worthwhile. Another feature that I suspect would be useful would be a "cumulative" option, to yield a cumulative histogram. Eric > > - > 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 - 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
Re: [matplotlib-devel] Improved histogram w/multiple types
On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: > 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... I'm not sure I understand this: won't it break all code written like: n, bins, patches = ax.hist(x, 50, normed=1) which is the code presented in the histogram example and a fairly common approach. I don't see this as an example of the "poorest written code".I am inclined to not break this call signature unless the lines are actually used, ie 'step' in histtype. On a quick read of the code, you either get lines or patches but not both, so how about n, bins, patches = ax.hist(x, 50, normed=1) or n, bins, lines = ax.hist(x, 50, normed=1, histtype='lines') > No one thinks this is worth committing to SVN? Don't take our silence as lack of interest -- it more likely means we filed it away meaning to get back to it and have fallen behind. Gentle reminders are appreciated. Manuel, since you offered, you can take the lead on getting the final version into svn. JDH - 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] Possible win32 memory bug
I'm working through some recent mpl bugs in the tracker. Here's one that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in _subprocess.c. This file is a copy of a file included with Python 2.5, so it's really a bug we inherited from there. https://sourceforge.net/tracker/index.php?func=detail&aid=1949978&group_id=80706&atid=560720 Read the Debian bug for more detailed info: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468977 It seems this bug was found using an automated tool and only represents a theoretical problem. The Debian folks also rightly don't care since matplotlib's _subprocess.c only gets built in Win32 with Python < 2.5. Note, however, that Python 2.5.2 includes the patch in the bug report as well as two other memory-related fixes, so I thought I would just update to that. I went ahead and committed this to SVN (branch and trunk), since I'm reasonably confident in this code, but it would be great if a regular Windows user could test this out and close the bug. Cheers, Mike -- Michael Droettboom Science Software Branch Operations and Engineering Division Space Telescope Science Institute Operated by AURA for NASA - 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
Re: [matplotlib-devel] Improved histogram w/multiple types
John Hunter wrote: > On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: > >> 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... > > I'm not sure I understand this: won't it break all code written like: > > n, bins, patches = ax.hist(x, 50, normed=1) > > which is the code presented in the histogram example and a fairly > common approach. I don't see this as an example of the "poorest > written code".I am inclined to not break this call signature > unless the lines are actually used, ie 'step' in histtype. On a quick > read of the code, you either get lines or patches but not both, so how > about > > n, bins, patches = ax.hist(x, 50, normed=1) > > or > >n, bins, lines = ax.hist(x, 50, normed=1, histtype='lines') That was my first reaction also, but the proposed "stepfill" option yields a bunch of bar patches *and* a line. The solution may be to accomplish "stepfill" with two separate calls, or to have 4 outputs only in the "stepfill" case. Or, with sufficient rewriting I think the "stepfill" case could yield a single patch and a single line, and the third output in this case could be a single corresponding 2-element tuple or list. That is, the third output is considered simply a list of artists. Now I will stop speculating and leave it to Manuel to sort out. Eric - 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
Re: [matplotlib-devel] Possible win32 memory bug
Michael Droettboom wrote: > I'm working through some recent mpl bugs in the tracker. Here's one > that relates to a mis-matched pair of PyObject_New/PyMem_DEL calls in > _subprocess.c. This file is a copy of a file included with Python 2.5, > so it's really a bug we inherited from there. > > https://sourceforge.net/tracker/index.php?func=detail&aid=1949978&group_id=80706&atid=560720 > > Read the Debian bug for more detailed info: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=468977 > > It seems this bug was found using an automated tool and only represents > a theoretical problem. The Debian folks also rightly don't care since > matplotlib's _subprocess.c only gets built in Win32 with Python < 2.5. Mike, subprocess is new in 2.4, so I assume we should build it only for Python < 2.4, correct? In that case, it can be removed entirely from the trunk, since we are requiring >= 2.4 there. Last week I put in the version-checking and removed the subprocess build from setupext.py, but I did not remove the _subprocess.c file itself--just in case the decision to require 2.4 was reconsidered. Eric > > Note, however, that Python 2.5.2 includes the patch in the bug report as > well as two other memory-related fixes, so I thought I would just update > to that. I went ahead and committed this to SVN (branch and trunk), > since I'm reasonably confident in this code, but it would be great if a > regular Windows user could test this out and close the bug. > > Cheers, > Mike > - 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
Re: [matplotlib-devel] Improved histogram w/multiple types
Eric Firing wrote: > John Hunter wrote: >> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: >> >>> 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... >> I'm not sure I understand this: won't it break all code written like: >> >> n, bins, patches = ax.hist(x, 50, normed=1) >> >> which is the code presented in the histogram example and a fairly >> common approach. I don't see this as an example of the "poorest >> written code".I am inclined to not break this call signature >> unless the lines are actually used, ie 'step' in histtype. On a quick >> read of the code, you either get lines or patches but not both, so how >> about >> >> n, bins, patches = ax.hist(x, 50, normed=1) >> >> or >> >>n, bins, lines = ax.hist(x, 50, normed=1, histtype='lines') > > That was my first reaction also, but the proposed "stepfill" option > yields a bunch of bar patches *and* a line. The solution may be to > accomplish "stepfill" with two separate calls, or to have 4 outputs only > in the "stepfill" case. Or, with sufficient rewriting I think the > "stepfill" case could yield a single patch and a single line, and the > third output in this case could be a single corresponding 2-element > tuple or list. That is, the third output is considered simply a list of > artists. Now I will stop speculating and leave it to Manuel to sort out. > > Eric I have just committed a patch to add the histogram step functionality. I took Erik Tollerud's patch as basis, but basically re-wrote it completely in the end ... The advantages are: (i) considerably smaller code and (ii) return values are unchanged, ie. n, bins, patches = ax.hist(x, 50) n, bins, patches = ax.hist(x, 50, histtype='step') In contrast to the original patch, histtype='step' is filled and to produce a non-filled histogram, one has to use facecolor='None'. Hope I haven't overlooked anything or broken other code ;-) Manuel - 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
