matplotlib-devel Mailing List for matplotlib (Page 9)

This is not a problem, I compile new nersions of differnet paclages
regularly.
I'll checkout the branch, many thanks !
Matthieu
2008年5月7日 Michael Droettboom <md...@st...>:
> Unfortunately, the fix requires recompiling C code. If you're comfortable
> doing that, the easiest thing is just to check out the svn branch here:
>
> http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint
>
> But for those not doing that, I think a new release is in order, but I'm
> not the one who normally makes those calls etc.
>
> Cheers,
> Mike
>
> Matthieu Brucher wrote:
>
>>
>>
>> > 2) Use:
>> > F.savefig(open(path, "w"), dpi=dpi)
>> This is exactly what matplotlib the *Agg backends do on the 0.91.x
>> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
>> release) still has this bug. This may be reason enough to push out a
>> new maintenance release of 0.91.x, but I say that having done it
>> before ;)
>>
>>
>> This is a really stopper for me, I have to interact with my figures before
>> saving them, and it is a really annoying behavior.
>> Were should this patch be applied ?
>>
>> +1 for a new maintenance release.
>>
>> I was searching for an answer to this, I'm glad the error was known and
>> the fix available, so thanks :)
>>
>> Matthieu
>> --
>> French PhD student
>> Website : http://matthieu-brucher.developpez.com/
>> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
>> LinkedIn : http://www.linkedin.com/in/matthieubrucher
>> ------------------------------------------------------------------------
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>
> --
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
>
>
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Unfortunately, the fix requires recompiling C code. If you're 
comfortable doing that, the easiest thing is just to check out the svn 
branch here:
http://matplotlib.svn.sf.net/svnroot/matplotlib/branches/v0_91_maint
But for those not doing that, I think a new release is in order, but I'm 
not the one who normally makes those calls etc.
Cheers,
Mike
Matthieu Brucher wrote:
>
>
> > 2) Use:
> > F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x
> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
> release) still has this bug. This may be reason enough to push out a
> new maintenance release of 0.91.x, but I say that having done it
> before ;)
>
>
> This is a really stopper for me, I have to interact with my figures 
> before saving them, and it is a really annoying behavior.
> Were should this patch be applied ?
>
> +1 for a new maintenance release.
>
> I was searching for an answer to this, I'm glad the error was known 
> and the fix available, so thanks :)
>
> Matthieu
> -- 
> French PhD student
> Website : http://matthieu-brucher.developpez.com/
> Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
> LinkedIn : http://www.linkedin.com/in/matthieubrucher
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> Manuel Metz wrote:
>> 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?
>>
>> I would prefer the first option...
> 
> I strongly agree.
> 
> Eric
> 
Hi,
so, I just commited the patch and also updated the API_CHANGES file.
Manuel

John Hunter schrieb:
> On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer
> <gre...@gm...> wrote:
>
> 
>> I also discovered this behaviour. It seems to be a Windows only specific
>> behaviour that only affects the bitmaps of the disabled (or grayed out)
>> toolbar buttons. A solution I found is to use the png toolbar bitmaps
>> instead of of the xpm ones. For this, replace in backend_wx.py,
>> NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
>> same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
>> wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
>> bitmaps have an alpha channel, see attached file. Furthermore, in my
>> opinion, the floppy symbol is too small compared to the other icons. I also
>> attached a magnified version.
>> 
>
> Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
> svn branch and trunk, but I don't have ready access to wx here, so if
> you or another wx svn user gets a chance to check, that would be
> great. Else I can do it tonight from home.
>
> 
I checked the svn version (on Linux), works well. On Windows, applying 
these changes manually, I could see grayed out toolbox icons.
Gregor

>
>
> > 2) Use:
> > F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x
> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest
> release) still has this bug. This may be reason enough to push out a
> new maintenance release of 0.91.x, but I say that having done it before ;)
This is a really stopper for me, I have to interact with my figures before
saving them, and it is a really annoying behavior.
Were should this patch be applied ?
+1 for a new maintenance release.
I was searching for an answer to this, I'm glad the error was known and the
fix available, so thanks :)
Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Michael Droettboom wrote:
>> 1) A couple icons seem to be missing. See screenshot enclosed.
It looks like Gregor solved this one.
>> 1) use:
>>
>> filename.encode('ASCII', 'replace')
>>
>> on the string before using it, so that you'll get an odd name with 
>> non-ascii charactors but at least it will work.
> That seems undesirable -- you'll end up with a filename with question 
> marks in it.
Better than than a crash, and no way to save a figure, even with a 
pure-ascii filename. You could use latin-1, or even better, something 
from a system setting, though I have no idea if that's doable. The real 
solution is to allow MPL to take unicode file names -- most modern file 
systems are using unicode now.
>> 2) Use:
>> F.savefig(open(path, "w"), dpi=dpi)
> This is exactly what matplotlib the *Agg backends do on the 0.91.x 
> maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest 
> release) still has this bug.
Darn.
> This may be reason enough to push out a 
> new maintenance release of 0.91.x,
Could be -- it's kind of a show stopper.
>> MPL, I get an invalid PNG.
> Which version of MPL produces an invalid PNG? 
0.91.2
and yes, I think it is a Window bug -- I'm pretty sure it works fine on 
OS-X.
Thanks,
-CHB
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

On Tue, May 6, 2008 at 8:49 AM, Gregor Thalhammer
<gre...@gm...> wrote:
> I also discovered this behaviour. It seems to be a Windows only specific
> behaviour that only affects the bitmaps of the disabled (or grayed out)
> toolbar buttons. A solution I found is to use the png toolbar bitmaps
> instead of of the xpm ones. For this, replace in backend_wx.py,
> NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In the
> same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by
> wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the png
> bitmaps have an alpha channel, see attached file. Furthermore, in my
> opinion, the floppy symbol is too small compared to the other icons. I also
> attached a magnified version.
Thankso Gregor -- I made these changes XPM->PNG for toolbar2 on the
svn branch and trunk, but I don't have ready access to wx here, so if
you or another wx svn user gets a chance to check, that would be
great. Else I can do it tonight from home.
JDH

Chris Barker schrieb:
> Hi all,
>
> I usually use MPL embedded in wx, so I haven't noticed these before 
> but with the pylab window:
>
> 1) A couple icons seem to be missing. See screenshot enclosed.
I also discovered this behaviour. It seems to be a Windows only specific 
behaviour that only affects the bitmaps of the disabled (or grayed out) 
toolbar buttons. A solution I found is to use the png toolbar bitmaps 
instead of of the xpm ones. For this, replace in backend_wx.py, 
NavigationToolbar2Wx::_init_toolbar() 'home.xpm' by 'home.png', etc. In 
the same file, in _load_bitmap() replace wx.BITMAP_TYPE_XPM by 
wx.BITMAP_TYPE_PNG. This also gives a better visual impression since the 
png bitmaps have an alpha channel, see attached file. Furthermore, in my 
opinion, the floppy symbol is too small compared to the other icons. I 
also attached a magnified version.
Gregor

Chris Barker wrote:
> Hi all,
>
> I usually use MPL embedded in wx, so I haven't noticed these before 
> but with the pylab window:
>
> 1) A couple icons seem to be missing. See screenshot enclosed.
I believe that's the way disabled buttons are drawn on Windows (or 
perhaps we need to provide disabled versions of the bitmaps on 
Windows). Do they appear after you have panned/zoomed the plot?
>
> 2) The save button doesn't work, as I get a "cannot return std::string 
> from a Unicode object" error. This is with a unicode build of 
> wxPython. I've had this same problem with my code. This issue is that 
> the savefig code can't handle unicode (regular old fopen, I think). 
> Here are two solutions:
>
> 1) use:
>
> filename.encode('ASCII', 'replace')
>
> on the string before using it, so that you'll get an odd name with 
> non-ascii charactors but at least it will work.
That seems undesirable -- you'll end up with a filename with question 
marks in it.
>
> 2) Use:
> F.savefig(open(path, "w"), dpi=dpi)
This is exactly what matplotlib the *Agg backends do on the 0.91.x 
maintenance branch and the trunk. Unfortunately, 0.91.2 (the latest 
release) still has this bug. This may be reason enough to push out a 
new maintenance release of 0.91.x, but I say that having done it before ;)
>
> Python's open allows unicode filenames, and I was told that recent 
> versions of MPL can take a file, rather than just aname, without an 
> unacceptable performance hit, though in my code, without the latest 
> MPL, I get an invalid PNG.
Which version of MPL produces an invalid PNG? I'd like to track that 
down. It may be Windows-specific.
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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,
I usually use MPL embedded in wx, so I haven't noticed these before but 
with the pylab window:
1) A couple icons seem to be missing. See screenshot enclosed.
2) The save button doesn't work, as I get a "cannot return std::string 
from a Unicode object" error. This is with a unicode build of wxPython. 
I've had this same problem with my code. This issue is that the savefig 
code can't handle unicode (regular old fopen, I think). Here are two 
solutions:
1) use:
filename.encode('ASCII', 'replace')
on the string before using it, so that you'll get an odd name with 
non-ascii charactors but at least it will work.
2) Use:
F.savefig(open(path, "w"), dpi=dpi)
Python's open allows unicode filenames, and I was told that recent 
versions of MPL can take a file, rather than just aname, without an 
unacceptable performance hit, though in my code, without the latest MPL, 
I get an invalid PNG.
thanks,
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Thanks for having a second look at this, Eric. I consider mixed-mode 
drawing somewhat of an experiment at this point -- it's still an open 
question whether it should be included in the next release, and 
definitely needs more use cases. It is currently only used in the trunk 
by quad meshes. In the common case where the mesh is of sufficient 
resolution, the rasterized version results in a smaller, faster file. 
However, it probably needs to be exposed as an option to the user, in 
the case where the quads are large (or to do it adaptively based on dpi, 
but that may be too smart).
John Hunter wrote:
> On Sat, May 3, 2008 at 11:44 PM, Eric Bruning <eri...@gm...> wrote:
>
> 
>> The switch to/from raster mode was made in Axes.draw, where the artists for
>> each axes are looped over. In the artist loop, I check if the artist to be
>> rendered is listed in the draw_raster attribute on the renderer instance. If
>> so, the appropriate calls are made to start and stop rasterizing.
>> 
>
> Hi Eric, thanks for the patch. There are a couple of aspects of the
> design here that I am not comfortable with, but I think with a few
> changes this will be useful (though Michael, who implemented the mixed
> mode renderer, will surely have important comments). The primary
> thing that bothers me is that one of the core aspects of the
> matplotlib backend design is that the renderers know nothing about
> artists -- artists know about renderers, but not the other way around.
> So I don't like using the renderer to store the rasterized artists.
> It makes more sense to me for the artist to have has a property set
> ("set_rasterized" which could be True|False|None where None means "do
> the default thing for the renderer"). Then you could do:
>
> if a.get_rasterized():
> renderer.start_rasterizing()
> a.draw(renderer)
> renderer.stop_rasterizing()
> else:
> a.draw(renderer)
> 
This is where I was (implicitly) going with all this.
> Doing this in the axes.draw method may not be the most natural place
> to do this since it could be done in the artist.draw method, but it
> may be the most expedient. This is an area where having support for
> before_draw and after_draw hooks might be useful. One potential
> problem with either of these approached is it looks like the mixed
> mode renderer is set up to handle multiple rasterized draws before
> dumping the aggregate image into the backend on a stop_renderer, so
> doing the start/stop in any of the approaches above would obviate this
> efficiency.
> The axes could aggregate the rasterized artists before
> rendering and then do them all together, but making this play properly
> with zorder will be tricky.
That's right. To receive significant gains, you would generally want to 
perform a number of drawing operations in a single raster buffer. Given 
how mpl is currently designed, that generally implies a Collection 
(which is fairly easy to wrap start/stop_rasterizing calls around) -- it 
doesn't necessarily have to mean a whole bunch of separate Artist 
objects (which would be much harder to do given the current way things 
are drawn). The latter may be ultimately more optimal, but the former 
is an easy win.
My concern with this patch is that it expects the user to know about 
artists at all. Sure, there are many advanced techniques where the user 
has to know what artists are etc., but for a lot of the pylab-level 
usage, that's not a concept many users must be familiar with. I think 
it makes more sense to just add a "rasterized" kwarg (and 
get/set_rasterized) to calls such as "pcolormesh" so the user can choose 
how it is drawn. The "draw_raster" list concept requires users to 
create a "set" from something that IMHO is more like a flag on 
individual objects. As an obtuse example, it would be like creating a 
list of all blue objects, and a list of all red ones, rather than just 
setting their colors appropriately.
As for the implementation, Eric's patch does appear to deal with the 
z-order problem, (by interleaving rasterized and non-rasterized drawing 
correctly base on zorder), but it doesn't combine adjacent rasterized 
artists into a single buffer. The drawing loop in Axes.draw could 
fairly easily be modified to do that. However, I think a better 
solution that doesn't require an explicit "draw_raster" list, is to make 
"stop_rasterizing" lazy. At the moment, when "stop_rasterizing" is 
called, the buffer is immediately flushed and written out. If instead 
it just set a flag, causing the buffer to be flushed when the next 
vector object is written, then something like
 start_rasterizing()
 draw_line()
 stop_rastering()
 start_rastering()
 draw_line()
 stop_rasterizing()
 draw_line()
would write out a single raster buffer with two lines, followed by a 
vector line. Of course, and here is the tricky bit, if the two 
rasterized objects are really far apart spatially, you waste a lot of 
space on transparent pixels between them. We can let the user decide 
whether to rasterize each individually with a nice clean API, but 
letting the user decide whether to combine adjacent rasterizations gets 
tricky and I think is asking too much of someone who doesn't know the 
mpl internals. Perhaps that is an argument against trying to implicitly 
combine adjacent rasterized draws -- it's trying to be too smart?
Anyway, somewhere in the midst of all this is the correct path...
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> 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.
>
Sounds good. We can leave my update on the 0.91.x maintenance branch, 
however. I suspect its fine to do so.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Here's a more clean implementation, which allows for arrow heads in
both ends as well as custom arrowheads.
harrow and varrow are just wrappers to create horisontal and vertical arrows.
-- 
Best Regards / Med Venlig Hilsen
Troels Kofoed Jacobsen

On Sat, May 3, 2008 at 11:44 PM, Eric Bruning <eri...@gm...> wrote:
> The switch to/from raster mode was made in Axes.draw, where the artists for
> each axes are looped over. In the artist loop, I check if the artist to be
> rendered is listed in the draw_raster attribute on the renderer instance. If
> so, the appropriate calls are made to start and stop rasterizing.
Hi Eric, thanks for the patch. There are a couple of aspects of the
design here that I am not comfortable with, but I think with a few
changes this will be useful (though Michael, who implemented the mixed
mode renderer, will surely have important comments). The primary
thing that bothers me is that one of the core aspects of the
matplotlib backend design is that the renderers know nothing about
artists -- artists know about renderers, but not the other way around.
 So I don't like using the renderer to store the rasterized artists.
It makes more sense to me for the artist to have has a property set
("set_rasterized" which could be True|False|None where None means "do
the default thing for the renderer"). Then you could do:
 if a.get_rasterized():
 renderer.start_rasterizing()
 a.draw(renderer)
 renderer.stop_rasterizing()
 else:
 a.draw(renderer)
Doing this in the axes.draw method may not be the most natural place
to do this since it could be done in the artist.draw method, but it
may be the most expedient. This is an area where having support for
before_draw and after_draw hooks might be useful. One potential
problem with either of these approached is it looks like the mixed
mode renderer is set up to handle multiple rasterized draws before
dumping the aggregate image into the backend on a stop_renderer, so
doing the start/stop in any of the approaches above would obviate this
efficiency. The axes could aggregate the rasterized artists before
rendering and then do them all together, but making this play properly
with zorder will be tricky. It does something like this already with
the "animated" artists so you may want to look at that. For animated
artists in the current implementation, zorder is ignored (the animated
artists are drawn on top). Chaco does something a bit more
sophisticated than this, since they have separate rendering levels and
buffers.
Another, less critical, aspect of the patch that bothers me is
tagging the renderer with the undocumented attribute "draw_raster"
and then checking this with a hasattr in axes.draw. python let's you
do this kind of stuff, and I've done plenty of it myself in
application building, but in my experience it makes for code that is
hard to maintain once the code base grows sufficiently large.
Although the mpl setters and getters are not the most pythonic
approach, they do make for code that is fairly readable and,
importantly, easily documented.
JDH

Hi,
On trunk, there is mixed-mode rendering support built in to (at least) the
SVG and PDF backends, though there are no calls to start/stop_rasterizing()
that utilize the raster mode. I've implemented mode switching for
those backends,
and would appreciate feedback on what I've done.
There are two modes that might drive a switch to raster for some artists:
1. User-driven specification of known complex artitsts.
2. Automatic detection of artist complexity (by type or vertex count).
The first mode is what I coded up, so I'll discuss it below.
A list of artists to rasterize is passed as a draw_raster kwarg to savefig,
which percolates down into print_* in the backend-specific figure canvas.
When the backend's canvas creates a renderer, the draw_raster list is placed
as an attribute on the renderer instance. I figured that the renderer should
be responsible for transporting the list of artists needing rasterization,
since it's at the renderer level that pixel vs. vector matters.
The switch to/from raster mode was made in Axes.draw, where the artists for
each axes are looped over. In the artist loop, I check if the artist to be
rendered is listed in the draw_raster attribute on the renderer instance. If
so, the appropriate calls are made to start and stop rasterizing.
Sample usage:
f=pyplot.figure()
ax=f.add_subplot(111)
p,=ax.plot(range(10))
f.savefig('test.pdf', draw_raster=(p,))
svn diff at
http://www.deeplycloudy.com/20080503-matplotlib-mixed-mode-r5110.diff
Thanks,
Eric Bruning
Graduate Research Assistant, Meteorology, Univ. Oklahoma
As of 6/1/2008, Research Assoc., Univ. Maryland/CICS and NOAA/NESDIS/STAR

Manuel Metz wrote:
> 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?
> 
> I would prefer the first option...
I strongly agree.
Eric
> 
> Manuel

Here's the link to the numpy wiki:
http://projects.scipy.org/scipy/numpy/roadmap#Semanticchangeforhistogram
Manuel Metz wrote:
> 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?
> 
> I would prefer the first option...
> 
> Manuel
> 

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?
I would prefer the first option...
Manuel

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

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

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
> 

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

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

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