matplotlib-users Mailing List for matplotlib

On 12/01/05 04:43, massimo sandal wrote:
> Ken:
> >An embedding library will give you those features, plus ones which 
> >pylab does not (e.g. printing support, selecting points and regions).
> 
> Ok. What I wanted to know is if in pylab there were hard-coded features 
> that the MPL OO interface has not, or if these features were already 
> present in MPL but simply had to be called and merged together by the 
> user (don't know if I'm being clear here - anyway you seem to point it's 
> the second, happier case).
I think I understand the question now. I thought you were worried about 
interactive plotting features, but I now believe you're asking about plotting 
in general (please correct me if I'm wrong!).
In terms of plotting, etc, I can't think of anything that pylab can do that 
you can't do using the OO API. You sometimes have to do a bit more work 
(because pylab manages a lot of details for you), but I haven't ran into any 
major problems. Of course, I'm using about one tenth of matplotlib's 
capabilities in my day-to-day work (plot(), imshow(), pcolor()), so you're 
milage may vary slightly. :-)
> >On using matplotlib bindings and the Navigator toolbars, I'd guess you
> >don't want to do this. The toolbars are ugly, take up screen real
> >estate, do stuff you don't need and don't do stuff you do need.
> 
> I agree toolbars are not essential, but they're nice IMHO. I don't 
> strictly need them, except for the panning and zooming tools. Hope 
> they're not hard to reproduce, should I have a look at the pylab code?).
Here are the toolbar classes:
WX backend -- matplotlib.backends.backend_wx.NavigationToolbar2Wx
WXAgg backend -- matplotlib.backends.backend_wxagg.NavigationToolbar2WxAgg
NavigationToolbar2WxAgg just overrides the "get_canvas(fig, frame)" method to 
return a FigureCanavsWXAgg, so you'll want to look at NavigationToolbar2Wx if 
you're interested in how it works.
The following files in the "examples/" subdirectory of the source distribution 
make use of a WX toolbar. They should help you get started, if you choose to 
go that route.
	dynamic_demo_wx.py
	dynamic_image_wxagg2.py
	embedding_in_wx2.py
	embedding_in_wx4.py
	wxcursor_demo.py
Ken

Massimo,
> Matt:
> >I would also characterize wxMPL as being focused on the
> >programmer/script writer, not on the end user of an application. So
> >it's not exactly a 'wxPython Plot Widget'. But it might make the code
> >of MPlot easier to use/manage/improve.
>
> I don't grasp what do you want to mean... if wxMPL is a wx interface for
> MPL, it seems focusing on the end user is the programmer's task, isn't
> it? and it seems right to me. In which sense is MPlot more "focused on
> the end user"? and what do you mean with "wxMPL is not exactly a
> 'wxpython plot widget'"?
Here's what I think the fundamental differences are. Maybe Ken can
give an opinion too.
wxMPL gives a nice and relatively complete set of tools with which you
can build any MPL functionality into a wxPython application. You'll
have to do some MPL-aware programming with wxMPL to get it to do what
you want. Like (correct me if I'm wrong, Ken), you'll have to
explicitly enable/disable zooming, and add your own GUI controls for
having user-set titles and such, and know that to plot, you need to
get the axes from the figure and use axes.plot(). I believe there
is no user-level way for altering the plots made with wxMPL.
In contrast, MPlot provides a PlotPanel and PlotFrame that already
have bindings for zooming, picking coordinates, and so on built in,
has a plot() method of its own, and also provides a GUI form (from a
pop-up menu that shows up on right-click) for users to change plot
titles, placement of legend, font sizes, and symbol and line types and
colors for the different 2D traces. To do this, MPlot does make
forced choices for bindings -- zooming is by dragging a rubberband
box, coordinates show up only on left-click, etc (I believe that wxMPL
also makes similar forced choices. This greatly reduces the need
for mpl-aware coding. You simply say
 self.plotframe =3D MPlot.PlotFrame(self)
 self.plotframe.Show()
 self.plotframe.plot(xdata,ydata)
you don't need to worry about bindings or making a form for the user
to change the plot titles or colors or use the matplotlib OO API at
all. MPlot takes care of that, or tries to anyway.
> if wxMPL is a wx interface for MPL, it seems focusing on the end user is =
the programmer's
> task, isn't it? and it seems right to me
With wxMPL it is, and wxMPL gives tools to programmer to make
applications. With MPlot, much of what you'd want is already built
in: it is a plotting component ready to be put into an application.=20
You could write your own wxHTML widget yourself too, or you could use
the one that already exists. It's simply a question of using
pre-existing packaged solutions or rolling your own from lower-level
parts.
> In which sense is MPlot more "focused on the end user"?
MPlot provides user-level control of plot characteristics (line type,
color, symbol type, titles) with a GUI form and a reasonably complete
set of functionality (printing, saving, etc). Just creating a MPlot
PlotPanel provides all that functionality.
> and what do you mean with "wxMPL is not exactly a 'wxpython plot widget'"=
?
Well, I'd say it's a class library from which one can build wxPython
plotting widgets.
Personally, I want a wxPython plotting widget that is a little further
removed from the underlying plotting library but is also pretty
feature heavy. I don't want to have to use the low-level
matplotlib API to say in a wxPython Program: 'make a wxPlotter', and
'plot x,y to the wxPlotter'. I looked closely at wxPyPlot when I wrote
MPlot (and I had a similar wrapping of BLT that I've used -- really, a
consistent interface is highly useful and easy on users). I wanted
something at a high enough level that knowledge of matplotlib is not
necessary for an enduser to use a PlotPanel, or even for a wxPython
programmer to use it in a program. In my opinion, MPlot ends up
looking a lot better than wxPyPlot -- all because of matplotlib.
Hope that helps, and that Ken (or anyone else) can clear up anything
I've got wrong.
--Matt

 It would help if you were more specific. Are you referring to
animation or static images? I can generate a million point scatter
plot in under a minute, and I would consider this pretty good for a
general purpose plotting package.
- Charlie
On 12/1/05, Michael McKerns <mmc...@it...> wrote:
> I completely agree with Alexander Mont.
>
> > From: Alexander Mont <alexmont1@co...>
> > "Test results"
> > 2005年11月23日 19:34
>
>
> Matplotlib is currently too slow to render large
> datasets. This needs improvement. Is anyone
> working on this problem? I believe this issue
> was also brought up at the last SciPy...
>
> ---
>
> Mike McKerns
> 242A Keck Laboratory MC138-78
> California Institute of Technology
> TEL: (626)395-5773 or (626)590-8470
> FAX: (626)795-6132
> http://www.its.caltech.edu/~mmckerns
> mmc...@ca...
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log fi=
les
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

I completely agree with Alexander Mont.
> From: Alexander Mont <alexmont1@co...>
> "Test results"
> 2005年11月23日 19:34
Matplotlib is currently too slow to render large
datasets. This needs improvement. Is anyone
working on this problem? I believe this issue
was also brought up at the last SciPy...
---
Mike McKerns
242A Keck Laboratory MC138-78
California Institute of Technology
TEL: (626)395-5773 or (626)590-8470
FAX: (626)795-6132
http://www.its.caltech.edu/~mmckerns
mmc...@ca...

So I was fairly successful at performing the horrid act known as
building mpl for windows. The problem I run into (py24) is the
"--install-script postinstall.py" flag. Where/what is this script?=20
The build works if I omit this.
Thanks,
- Charlie

On Wednesday 30 November 2005 16:18, John Hunter wrote:
> >>>>> "Carl" == Carl Dr Kleffner <cmk...@gm...> writes:
>
> Carl> Hi matplot-list, drawing scatterplots with thousends of
> Carl> scatter dots (marker='o') yields in bloated file sizes for
> Carl> vector-formats (ps, svg). The reason for that is, that each
> Carl> marker circle ist made of a large number of lines instead of
> Carl> a simple arc (0..360 degree) i.e.
>
> Carl> Can this be patched easily? and btw what is the meaning of
> Carl> the _newstyle attribute in the drawing methods?
>
> Originally the backends drew each marker with a separate function
> call, which was slow and prevented optimizations. We introduced a new
> API to make marker drawing fast, but rather than break all the
> noncompliant backends we left a flag in for newstyle, meaning the new
> API, to determine which method to use. Unfortunately, this supported
> laziness, and no backends other than *Agg support the new method
> (which can be 25x faster...) It would also enable you to introduce
> these optimizations, eg postscript macros, if you added it to PS.
> Search the dev archives for newstyle for length discussions. I'll be
> happy to advise further if you are interested in pursuing this.
I think the draw_markers function already exists for ps, I wrote it up a while 
back, but we ended up masking it when problems arose in the new API.
Darren

Thanks John, the new package worked.
Vineet
----- Original Message ----
From: John Hunter <jdh...@ac...>
To: Vineet Jain <vi...@al...>
Cc: 
Sent: Wednesday, November 30, 2005 11:46:26 AM
Subject: Re: [Matplotlib-users] Problem with 0.85 package for ubuntu
>>>>> "Vineet" == Vineet Jain <vi...@al...> writes:
 Vineet> Using the 0.85 package for ubuntu, I get the following
 Vineet> error when I run my application:
 
It was indeed a problem with the ubuntu package and it is fixed now
 > sudo apt-get update
 > sudo apt-get install python-matplotlib-jdh
Please do not cross-post to the users and dev list...
JDH

John Hunter <jdh...@ac...> writes:
>>>>>> "Charlie" == Charlie Moad <cw...@gm...> writes:
>
> Charlie> simple pylab script: a = axes() a.set_xticklabels(['a',
> Charlie> 'b', 'c']) show()
>
> Charlie> TypeError: list indices must be integers
>
> Did someone fix this? I can't replicate it.
I had similar problems with an earlier CVS version (using WXAgg), but
a recent cvs update command fixed it. Perhaps the problem has been
masked instead of fixed, since pylab fails to show the x coordinate of
the mouse pointer when I move it around. That is, the text in the
bottom right panel is something like "x=, y=3.5016e-1". It seems that
the code that caused the exception is related to computing these
coordinates.
-- 
Jouni K Seppänen

Whoa!
Thank you for all your answers. It's one of the most helpful mailing 
lists I ever joined.
John:
 >There is some tutorial documentation, particularly Robert Leftwich's
 >tutorial - http://matplotlib.sourceforge.net/leftwich_tut.txt. This
 >link recently disappeared (by accident) from the FAQ entry
 >http://matplotlib.sf.net/faq.html#OO
Thank you very much (and kudos for your work, by the way: the more I 
dive into it, the nicer it looks). I already had seen the faq entry, but 
the little tutorial by Leftwich with the class list just makes me feel 
better :)
Ken:
 >An embedding library will give you those features, plus ones which 
 >pylab does not (e.g. printing support, selecting points and regions).
Ok. What I wanted to know is if in pylab there were hard-coded features 
that the MPL OO interface has not, or if these features were already 
present in MPL but simply had to be called and merged together by the 
user (don't know if I'm being clear here - anyway you seem to point it's 
the second, happier case).
 >It now checks to see if one already exists, so you can to use pylab 
 >from your wxPython application without everything blowing up.
Hmm. Evil temptation! But I'm more and more looking at wx embedding,anyway.
Anyway it's nice to know it's an option if someone wants to hack 
something someday.
Chris:
 >Be sure to join the wxpython-users mailing list. They (We) are every 
 >bit as helpful as this group.
I really hope so!
Niklas:
 >First of all, why not take a look at an existing solution for AFM:
 >http://gwyddion.net/
 >It looks very good and is already very mature. It provides a plugin 
 >architecture, a modern graphical interface, is portable and seems to 
be >funded as well. However, it can only analyze surface data, and I 
don't >know if this is what you meant with '2d graph'.
I didn't know about it. It seems really a good app, and I just mailed to 
my collegues if they know about it, it could help in our lab. Alas, (1) 
I'm all in that odd "force spectroscopy" thing (despite being two years 
I work with AFM, I never did an image!), and I don't see mention about 
it (2) I'd prefer to code my app to cover my needs. Who knows if it will 
be the app of someone else too? I hope to do a good enough work for it. 
I don't like that much to hack just for myself.
Anyway if you know about good force spectroscopy analysis free software, 
let me know!
Matt:
 >I would also characterize wxMPL as being focused on the
 >programmer/script writer, not on the end user of an application. So
 >it's not exactly a 'wxPython Plot Widget'. But it might make the code
 >of MPlot easier to use/manage/improve.
I don't grasp what do you want to mean... if wxMPL is a wx interface for 
MPL, it seems focusing on the end user is the programmer's task, isn't 
it? and it seems right to me. In which sense is MPlot more "focused on 
the end user"? and what do you mean with "wxMPL is not exactly a 
'wxpython plot widget'"?
 >On using matplotlib bindings and the Navigator toolbars, I'd guess you
 >don't want to do this. The toolbars are ugly, take up screen real
 >estate, do stuff you don't need and don't do stuff you do need.
I agree toolbars are not essential, but they're nice IMHO. I don't 
strictly need them, except for the panning and zooming tools. Hope 
they're not hard to reproduce, should I have a look at the pylab code?). 
For the bindings, yes, I'd really like consistency between the graphic 
toolkit and MPL.
 >Finally, I was very happy to see your
 >response to the fairly silly 'use some other package', and agree
 >completely with your sentiment.
Well, he just tried to be helpful.
Anyway, after having heard both developers, I'm still confused about 
what to use, if wxMPL or MPlot... I think I'll give wxMPL a try, first.
Thank you all for your long and informative answers. It's a bless to 
have both the MPL, wxMPL and MPlot developers being here to help me, 
along with such experienced and friendly users.
It's two years I use almost exclusively free software, and nevertheless 
the both technical and human wonders of it don't cease to amaze me. 
Thank you all.
Massimo
-- 
Massimo Sandal
University of Bologna
Department of Biochemistry "G.Moruzzi"
snail mail:
Via Irnerio 48, 40126 Bologna, Italy
email:
mas...@un...
tel: +39-051-2094388
fax: +39-051-2094387

Dear Massimo,
Sorry I wasn't able to respond sooner. I've been running experiments
all day. As a warning, this response may be long, and I won't take
the time to be overly polite. So let me say it now: Matplotlib is a
great plotting library and John should be knighted.
I was in a similar dilemma a little over a year ago when I was
comfortable enough with matplotlib and its development that I knew it
was what I wanted to commit to using. At that time (late summer
2004), wxmpl did not exist and many of the additions for interactivity
in matplotlib did not exist. I had already decided to abandon
Tkinter/Pmw.BLT plotting, but it took awhile to find a better
solution. Matplotlib is it.
And I definitely wanted (and still want) a wxPython plotting widget
which is intended to go into applications. Much of matplotlib, and
the other responses seem to fail to understand this: I (and I'm
assuming you) want a plotting widget that goes into a wxPython
application. I want to say something not much harder than
 plotpanel =3D SomeMatplotLibPanel(wx_parent_id)
 plotplanel.plot(x,y)
And then have the user (that is *MY* user -- the person running the
program, not the person writing the script) be able to change the
color, change the titles, zoom in, zoom out, print, save to a PNG.
MPlot tries to do this. For 2-d line plots, it does this fairly well.
 It may not be the best code, it certainly could use improvement.=20
Please feel free to make or suggest changes. If you (or anyone else)
would like to use it or develop it, please let me know how I can help
you. I'd love for it to be improved -- it really needs false color
maps soon. OTOH, if something better comes along, I'll happily use
it.
Pylab is NOT suitable for applications. It assumes that the end user
is someone who uses python. Somehow this became the higher priority
for matplotlib. I think this is a terrible mistake. Seeing so many
examples and questions on this mailing list assuming
 from pylab import *
is really quite sad. To me it suggest this lovely packaged advertised
as a library is not being used as a library at all. Matplotlib is far
too nice to be an add-on to IPython or used only for writing
quick-n-dirty scripts.
wxMPL is definitely a very nice wx wrapping of MPL. My recollection
is that Ken McIvor wrote wxmpl after I showed him MPlot, but I'd defer
to Ken's version of the story. I'm also very happy that Ken's
maintaining the wx backend. I definitely spent most of the effort in
MPlot on bindings, printing, user configuration, and worrying about
being able to 'stripchart' (update a trace at close to 'real time').=20
I'm sure that some of what I wrote could be replaced with wxmpl or
matplotlib calls at this point. You may understand my reluctance to
do this (like it works and I have my own data to analyze and
applications to write), but I would not be opposed to seeing this
done.
I would also characterize wxMPL as being focused on the
programmer/script writer, not on the end user of an application. So
it's not exactly a 'wxPython Plot Widget'. But it might make the code
of MPlot easier to use/manage/improve.
On using matplotlib bindings and the Navigator toolbars, I'd guess you
don't want to do this. The toolbars are ugly, take up screen real
estate, do stuff you don't need and don't do stuff you do need. I'm
sure these are fine when you're doing a quick-n-dirty plot with an
'ipython -pylab' script, but I somehow never need to do that. Using
the matplotlib bindings would mean separate kinds of event handlers
for a MPL Panel and a non-MPL Panels. I guess that's inevitable, but
I'd still suggest sticking with straight wx.Bind methods. I don't
think the MPL bindings provide anything that can't easily be
reproduced, though it's been awhile since I looked at them.
Since you're short on time (we all are), I suggest giving MPlot a spin
and see if it does enough of what you need. I'd appreciate hearing
what does and doesn't. Finally, I was very happy to see your
response to the fairly silly 'use some other package', and agree
completely with your sentiment.
Cheers,
--Matt
PS: a very short wxPython / MPlot example:
import wx
import MPlot
import matplotlib.numerix as Num
x =3D Numpy.arange(0.0,10.0,0.1)
y =3D Numpy.sin(2*x)/(x+2)
app =3D wx.PySimpleApp()
pframe =3D MPlot.PlotFrame()
pframe.plot(x,y)
pframe.set_title('Test Plot')
pframe.set_xlabel(r'$R (\angstrom)$')
pframe.write_message('MPlot PlotFrame example: Try Help->Quick Reference')
pframe.Show()
pframe.Raise()
app.MainLoop()