matplotlib-users Mailing List for matplotlib

On 6/22/07, John Hunter <jd...@gm...> wrote:
> Truly an interesting bug. It doesn't show up in PS but does in Agg.
> The most likely explanation is that the draw marker function is
> setting a clip path that isn't properly getting cleared and subsequent
> draws are being clipped to the original axes.
Yep this was it -- fixed in svn. Thanks for the clever test case!
JDH

On 6/22/07, Antonio Gonzalez <Ant...@ki...> wrote:
> I'm seeing a rather odd behaviour when plotting (using mpl 3405):
> - create a figure with two subplots
> - plot something on each axis
> - plot an extra something on the first axis USING A SYMBOL
> - set axis off
> - show()
> Result: the second plot won't be shown
Truly an interesting bug. It doesn't show up in PS but does in Agg.
The most likely explanation is that the draw marker function is
setting a clip path that isn't properly getting cleared and subsequent
draws are being clipped to the original axes.
I'll look into it.
JDH

I'm seeing a rather odd behaviour when plotting (using mpl 3405):
- create a figure with two subplots
- plot something on each axis
- plot an extra something on the first axis USING A SYMBOL
- set axis off
- show()
Result: the second plot won't be shown
However, the second plot will be shown if I follow the same process
without using a symbol, or if I don't switch off the axes.
To illustrate, consider the following code:
from pylab import figure, rand, show
fig = figure()
ax1 = fig.add_subplot(121)
ax2 = fig.add_subplot(122)
ax1.plot(rand(100))
ax1.plot([50, 60], [.5, .6], '^')
ax2.plot(rand(100))
for ax in fig.axes: ax.set_axis_off()
show()
The second plot (ax2) is not shown. Now, if line 8 is commented, or if a
symbol is not used in line 6, as in:
ax1.plot([50, 60], [.5, .6])
then the two plots are shown as expected.
Looks like a bug to me, right?
Regards,
Antonio

There is a nice gnuplot python interface out there. Google for gnuplot.py
On 6/22/07, Stephan Bourduas <ste...@vi...> wrote:
> On June 20, 2007, Eric Firing wrote:
> > Unfortunately, the 3D plotting capability is incomplete and mostly
> > unmaintained.
>
> >
> > Orest Kozyar wrote:
> > > One thing I would really love to be able to do is generate a surface
> > > map that is color-coded. Right now I can generate a single-color
> > > surface map, but a color-coded surface map would be much easier to
> > > interpret.
>
> I needed to make a surface plot last week and I ended up using gnuplot
> (http://www.gnuplot.info/) instead of matplotlib. As stated above, the 3D
> plotting capabilities of matplotlib are somewhat limited, so you may need to
> use an alternative package. gnuplot generates plots which are quite similar
> to Matlab, check out the 'pm3d' plot style:
>
> http://gnuplot.sourceforge.net/demo_4.2/pm3d.html
>
> You can also control the color map:
> http://gnuplot.sourceforge.net/demo_4.2/pm3dcolors.html
>
> Stephan
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On June 20, 2007, Eric Firing wrote:
> Unfortunately, the 3D plotting capability is incomplete and mostly
> unmaintained.
>
> Orest Kozyar wrote:
> > One thing I would really love to be able to do is generate a surface
> > map that is color-coded. Right now I can generate a single-color
> > surface map, but a color-coded surface map would be much easier to
> > interpret.
I needed to make a surface plot last week and I ended up using gnuplot 
(http://www.gnuplot.info/) instead of matplotlib. As stated above, the 3D 
plotting capabilities of matplotlib are somewhat limited, so you may need to 
use an alternative package. gnuplot generates plots which are quite similar 
to Matlab, check out the 'pm3d' plot style:
http://gnuplot.sourceforge.net/demo_4.2/pm3d.html
You can also control the color map:
http://gnuplot.sourceforge.net/demo_4.2/pm3dcolors.html
Stephan

Thank you Benoit,
but I am actually using the hist command, not the bar command. :(
>Hey,
>> I would love to be able to plot them next to each
>> other as it should be (like this basically:
>This is quite easy...
>
>You should do sth like:
>width=3D0.5
>position =3D 0.25
>bar(xAxis-position, yAxis, width, color=3D'#BBBBBB')
>
>width defines the width of the bar. And position allows you to move =20
>the bar along the x-axis ticks (by addition or substracting position =20
>to you x-axis vector)
>Benoit
On 6/20/07, Giorgio F. Gilestro <gi...@gi...> wrote:
> Hi there,
> I am trying to find a way to improve the plotting of a distribution.
> I am using the boxplot command and the dist command to plot the spread
> of a distribution: see first two panel here:
> http://img75.imageshack.us/img75/5260/distonevy0.png
> Now, whenever I add data to be plot on the hold axes I face two
> problems that I don't really know how to solve ( see:
> http://img232.imageshack.us/img232/2219/disttwopl2.png )
>
> The first one is that I don't manage to get the upper boxplot to be
> drawn using different colors.
> The second is that the bars representing the distribution (middle
> panel) are drawn one in front of the others, hiding in this way the
> ones in the back. I would love to be able to plot them next to each
> other as it should be (like this basically:
> http://img75.imageshack.us/img75/6218/distthreeef4.jpg )
>
> Anyone has some suggestion?
>
> Thanks!
> Giorgio
>

I would also highly recommend Ken McIvor's wxmpl:
http://agni.phys.iit.edu/~kmcivor/wxmpl/
It makes wxPython and mpl play very nicely together.
I have been involved in several threads recently about how no to
import pylab in data analysis libraries and when embedding in gui's.
You may find this thread useful:
http://www.mail-archive.com/mat...@li.../msg02732.html
Ryan
On 6/22/07, John Hunter <jd...@gm...> wrote:
> On 6/22/07, Paul Smith <pau...@ca...> wrote:
> > I've converted an analysis program that does some plotting to use the
> > matplotlib API, then wrote a GUI control program using wxWidgets to call it.
> > I've tried to keep the two parts as separate as possible so there is an
> > analysis class that is instantiated in the GUI part, and then the GUI part
> > just calls the analysis methods.
>
> > Ok, so under ipython -pylab everything seems to (mostly) go ok. The GUI
>
> This appears to be your problem. If you are using mpl in a wx app,
> you should not be importing pylab or running ipython in pylab mode
> because you will get mainloop conflicts. Rather, use the matplotlib
> API directly following the lead of examples/embedding_in_wx*.py and
> tthen run ipython in -wthread mode rather than pylab mode.
>
> JDH
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 6/22/07, Roman Bertle <be...@sm...> wrote:
> very nice! The only remaining problem is that an analysis library
> functions might return several figures. In my case the data depends on
> several parameters, and the function returns a dictionary containing for each
> parameter set statistics, histograms and plots. The user should be able
> to decide for which parameter he wants to pop up a plot, or save it to a
> file, but for your approach all these windows pop up automatically, and
> not only when the user does a fig.show() for the figure he is interested
> in. Unfortunately the latter does not work if the figure is an
> matplotlib.figure.Figure() instance, as in my approach.
I agree with everything you say, only it is difficult to encapsulate
and get the details right for raising and hiding GUI windows across
backends, handling the mainloop etc. Not at all impossible, but it
takes a concerted effort across 5 user interfaces. Note I did
recently (in svn) add a fig.show() method, which will show new figures
created in an event loop after the global show starts the GUI
mainloop.
I do something similar to Ryan, but slightly more general to handle
the case you mention -- the need to possibly create multiple figures.
I define a figure generating function in my GUI code, and pass either
that function, or pylab.figure -- not pylab.figure() -- into my
functions that need to create figures. Client code can then call that
function as often as they wish to create multiple figure windows.
I've included below a class which is callable that is used to generate
GTK figures that I sometimes use in my gtk apps. That way functions I
use in my apps can also be called from pylab by passing in
pylab.figure
But as above, I would be very happy to have a finer degree of control
in pylab. If you would like to take a stab at a patch to your backend
of choice to support better control of figure raising and hiding from
the pylab interface, give it a whirl. It would make it easier for
other backend maintainers to follow your lead and port the code into
the various backends.
class GTKFigure:
 def __init__(self, title):
 self.title = title
 def __call__(self):
 from matplotlib.figure import Figure
 from matplotlib.backends.backend_gtkagg import
FigureCanvasGTKAgg as FigureCanvas
 from matplotlib.backends.backend_gtkagg import
NavigationToolbar2GTKAgg as NavigationToolbar
 win = gtk.Window()
 win.set_default_size(800,600)
 win.set_title(self.title)
 vbox = gtk.VBox()
 win.add(vbox)
 fig = Figure(figsize=(5,4), dpi=80)
 canvas = FigureCanvas(fig) # a gtk.DrawingArea
 vbox.pack_start(canvas)
 toolbar = NavigationToolbar(canvas, win)
 vbox.pack_start(toolbar, False, False)
 win.show_all()
 return fig

On 6/22/07, Paul Smith <pau...@ca...> wrote:
> I've converted an analysis program that does some plotting to use the
> matplotlib API, then wrote a GUI control program using wxWidgets to call it.
> I've tried to keep the two parts as separate as possible so there is an
> analysis class that is instantiated in the GUI part, and then the GUI part
> just calls the analysis methods.
> Ok, so under ipython -pylab everything seems to (mostly) go ok. The GUI
This appears to be your problem. If you are using mpl in a wx app,
you should not be importing pylab or running ipython in pylab mode
because you will get mainloop conflicts. Rather, use the matplotlib
API directly following the lead of examples/embedding_in_wx*.py and
tthen run ipython in -wthread mode rather than pylab mode.
JDH

Hi Paul,
Paul Smith wrote:
>
> I’ve converted an analysis program that does some plotting to use the 
> matplotlib API, then wrote a GUI control program using wxWidgets to 
> call it. I’ve tried to keep the two parts as separate as possible so 
> there is an analysis class that is instantiated in the GUI part, and 
> then the GUI part just calls the analysis methods.
>
> Ok, so under ipython -pylab everything seems to (mostly) go ok. The 
> GUI comes up, data gets loaded into the analysis object, processed and 
> plotted in a couple of separate matplotlib windows (ie. ones that are 
> not specifically part of the GUI), and results come back to update 
> some wx textctrl fields on the GUI. I qualify this as mostly ok 
> because if I use the TkAgg backend for the plotting, which is done by 
> the analysis class, the whole lot crashes to non-existence as soon as 
> either plot window is moved (yep, this is Windows). If I use the wxAgg 
> backend, however, it seems to play nice(r).
>
I think this is due to using TkAgg with wxPython, IIRC TK and WX don't
"like" to work together, I think there is some conflict but don't
remember the details.
>
> The problem is when all this is done outside of ipython – ie. running 
> from the command line ala "python myAnalysisUI.py" - the matplotlib 
> figures come up when required but text fields are no longer updated in 
> the GUI once plotting is done. The GUI is still responsive to clicks 
> on buttons etc, but it’s as if the final bit after plotting gets blocked.
>
> This makes me wonder about a couple of things. How well do essentially 
> independent matplotlib windows work with a wx App?
>
What do you call an independent window? Is this a wx.Frame which shows
the matplotlib plots?
Do have a smallish sample which shows the problem?
...
>
> The other vitals are: OS: WinXP, Python 2.5, matplotlib 0.90.1, 
> wxPython 2.8.0.1, ipython 0.8.2
>
I have just about the same, WinXP / Vista, Python 2.5.1, matplotlib
0.90.1 wxPython 2.8.4.0 (but have used older versions too).
Werner

* Ryan Krauss <rya...@gm...> [070622 09:47]:
> I don't think we are actually disagreeing with one another. I have
> written the kind of library you are talking about and used the same
> library from ipython and in a wxpython app. All of my plotting
> functions expect a fig instance as an input. When calling the library
> from ipython, I pass in a fig=pylab.figure(), when using the data
> analysis library with wxpython, my fig comes from the get_figure
> method of a wxmpl PlotPanel instance. wxmpl handles all canvas issues
> for me.
> 
> So, in my libraries, I have inputs that are fig instances. Creating a
> fig with pylab.figure() is how I use my library from ipython.
> 
> I actually have this code in one of my data analysis library functions
> 
> def plotting_function(x, y, other inputs, fig=None):
> if fig is None:
> from pylab import figure
> fig = figure(fignum)
> 
> and the code works beautifully as a library and plays well with
> ipython and wxpython.
Hello,
very nice! The only remaining problem is that an analysis library
functions might return several figures. In my case the data depends on
several parameters, and the function returns a dictionary containing for each
parameter set statistics, histograms and plots. The user should be able
to decide for which parameter he wants to pop up a plot, or save it to a
file, but for your approach all these windows pop up automatically, and
not only when the user does a fig.show() for the figure he is interested
in. Unfortunately the latter does not work if the figure is an
matplotlib.figure.Figure() instance, as in my approach.
Best Regards, Roman

I've converted an analysis program that does some plotting to use the
matplotlib API, then wrote a GUI control program using wxWidgets to call it.
I've tried to keep the two parts as separate as possible so there is an
analysis class that is instantiated in the GUI part, and then the GUI part
just calls the analysis methods.
 
Ok, so under ipython -pylab everything seems to (mostly) go ok. The GUI
comes up, data gets loaded into the analysis object, processed and plotted
in a couple of separate matplotlib windows (ie. ones that are not
specifically part of the GUI), and results come back to update some wx
textctrl fields on the GUI. I qualify this as mostly ok because if I use the
TkAgg backend for the plotting, which is done by the analysis class, the
whole lot crashes to non-existence as soon as either plot window is moved
(yep, this is Windows). If I use the wxAgg backend, however, it seems to
play nice(r).
 
The problem is when all this is done outside of ipython - ie. running from
the command line ala "python myAnalysisUI.py" - the matplotlib figures come
up when required but text fields are no longer updated in the GUI once
plotting is done. The GUI is still responsive to clicks on buttons etc, but
it's as if the final bit after plotting gets blocked.
 
This makes me wonder about a couple of things. How well do essentially
independent matplotlib windows work with a wx App? The fact one backend
works (wxAgg) and one doesn't (TkAgg) is a bit strange. Should I be doing
something related to threads, which is where maybe ipython is doing a better
job, to finish what needs doing in the GUI once plotting has finished?
Haven't done anything involving threading so far so I'm guessing here. I
should add I do import a few things from pylab - figure, show, twinx. I
gather pylab and wx don't mix well.
 
A Minor Detail: wxAgg backend plots by default are missing the left and
right navigation button bitmaps in the toolbar which looks a bit funny to
me. Only when you pan/zoom do they start to appear. I made the following
change to my local copy of backend_wx.py so they'd always appear, if
anyone's interested. Doesn't seem to be bothered when clicking arrows if
there's no history.
 def set_history_buttons(self):
## can_backward = (self._views._pos > 0)
## can_forward = (self._views._pos < len(self._views._elements) - 1)
## self.EnableTool(self._NTB2_BACK, can_backward)
## self.EnableTool(self._NTB2_FORWARD, can_forward)
 self.EnableTool(self._NTB2_BACK, True)
 self.EnableTool(self._NTB2_FORWARD, True)
 
The other vitals are: OS: WinXP, Python 2.5, matplotlib 0.90.1, wxPython
2.8.0.1, ipython 0.8.2
 
Paul Smith
Systems Engineer
CAT Underground Mining Technology
Ph: +61 (0)3 9853 4050
Fax: +61 (0)3 9853 4955