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

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

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

Re: Improved histogram w/multiple types

On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud
<erik.tollerud@...> 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.

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

Re: Improved histogram w/multiple types

John Hunter wrote:
> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud
<erik.tollerud@...> 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 

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

Re: Improved histogram w/multiple types

Eric Firing wrote:
> John Hunter wrote:
>> On Wed, Apr 2, 2008 at 6:39 PM, Erik Tollerud
<erik.tollerud@...> 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 

New arrow implementation, proof of concept.

Hi Matplotlib devs

I'm happily using this software. Have just always found your arrow 
implementation a bit strange, as it assumes equal axis. 

Here is a new, simple first draft of an arrow implementation, that does not 
assume equal axis. Feel free to use any of the code under your preferred 
license. Or comment, and I will keep working on it.

An example is included in the file.

Best Regards
Troels Kofoed Jacobsen

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

numpy histogram 1.1 -> 1.2

Hi,
   while adding the step-histogram I learned about the change of 
numpy.histogram. As MPL trunk relies in numpy 1.1, I think its a good 
idea to switch to the new histogram, i.e. use "new=True". Indeed, this 
is required to be able to allow to give bin-edges, which is possible 
with MPL 0.91.
   However, while keeping API compatibility on the one hand by allowing 
to provide bin-edges, this step also breaks API compatibility since the 
definition of bins has changed:

numpy 1.0.4

In [1]:from numpy import *
In [2]:random.seed(18)
In [3]:x = random.random(100)
In [4]:histogram(x, bins=array([0,0.1,0.2]))
Out[4]:(array([11, 11, 78]), array([ 0. ,  0.1,  0.2]))

numpy 1.1.0.dev5106'

In [1]:from numpy import *
In [2]:random.seed(18)
In [3]:x = random.random(100)
In [4]: histogram(x, bins=array([0,0.1,0.2]),new=True)
Out[4]: (array([11, 11]), array([ 0. ,  0.1,  0.2]))

How should this be handled? Follow numpy, breaking API compatibility and 
point to the API change of histogram? Or keeping API compatibility with 
MPL0.91 and write a wrapper function?