From: Erik T. <eri...@gm...> - 2008-04-02 23:39:03
Attachments:
histerik.diff
|
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 eto...@uc... |
From: Erik T. <eri...@gm...> - 2008-05-01 21:13:48
|
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 <eri...@gm...> 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 > eto...@uc... > |
From: Manuel M. <mm...@as...> - 2008-05-02 07:10:15
|
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 <eri...@gm...> 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 >> eto...@uc... >> > > ------------------------------------------------------------------------- > 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 > Mat...@li... > 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 |
From: Eric F. <ef...@ha...> - 2008-05-02 07:47:36
|
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 <eri...@gm...> 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 >>> eto...@uc... >>> >> ------------------------------------------------------------------------- >> 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 >> Mat...@li... >> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: John H. <jd...@gm...> - 2008-05-02 13:10:36
|
On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> 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 |
From: Eric F. <ef...@ha...> - 2008-05-02 18:09:02
|
John Hunter wrote: > On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> 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 |
From: Manuel M. <mm...@as...> - 2008-05-02 22:02:32
|
Eric Firing wrote: > John Hunter wrote: >> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> 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 |
From: Johann Cohen-T. <co...@sl...> - 2008-05-15 11:52:33
|
hello, is there an example in the distribution that shows these new features? How about the idea to allow for an option to get cumulative histograms, that sounded a very nice idea.... thanks, Johann Manuel Metz wrote: > Eric Firing wrote: > >> John Hunter wrote: >> >>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
From: Manuel M. <mm...@as...> - 2008-05-16 14:59:41
|
Johann Cohen-Tanugi wrote: > hello, > is there an example in the distribution that shows these new features? I just added an example to the trunk, see examples/histogram_demo_step.py > How about the idea to allow for an option to get cumulative histograms, > that sounded a very nice idea.... I also added the keyword 'cumulative' to the axes hist() method. Actually, in the current version, if cumulative=True AND normed=True the cumulative histogram is normed to 1, which seemed to be most convenient to me (rather than 1/binwidths which is what numpy.hist actually does). Manuel > thanks, > Johann > > Manuel Metz wrote: >> Eric Firing wrote: >> >>> John Hunter wrote: >>> >>>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <eri...@gm...> 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 >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |