Improved histogram w/multiple types

Development matplotlib-devel
#1

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)

histerik.diff (6.92 KB)

···

--
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
etolleru@...244...

#2

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 <erik.tollerud@...149...> 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
etolleru@...244...

#3

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...

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
etolleru@...244...

-------------------------------------------------------------------------
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

···

On Wed, Apr 2, 2008 at 4:39 PM, Erik Tollerud <erik.tollerud@...149...> wrote:

#4

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...

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
etolleru@...244...

-------------------------------------------------------------------------
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

···

On Wed, Apr 2, 2008 at 4:39 PM, Erik Tollerud <erik.tollerud@...149...> wrote:

-------------------------------------------------------------------------
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

#5

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

···

On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <erik.tollerud@...149...> wrote:

#6

John Hunter 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

···

On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <erik.tollerud@...149...> wrote:

#7

Eric Firing wrote:

John Hunter 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 :wink:

Manuel

···

On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud <erik.tollerud@...149...> wrote:

#8

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 <erik.tollerud@...149...> 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 :wink:

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

#9

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 <erik.tollerud@...149...> 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 :wink:

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
  
-------------------------------------------------------------------------
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel