matplotlib-users Mailing List for matplotlib (Page 8)

HI,

I agree with Ken -- this is definitely not a flamewar.  I have no
ill-will toward anyone here, or any of the codes in discussion.  In
fact, quite the opposite. I also do not have a lot of time to devote
to this discussion or MPlot itself, mostly due to running experiments
and working on and supporting about other analysis software.  I have
very little allegiance to MPlot, take no pride in it and in no way
'want it to win' over anything else.  I do want something that has the
end-user level flexibility of MPlot, and would happily use something
else if available.  I am committed to wxPython because, while a
long-time and confirmed Unix (now linux/OSX) person, about 90% of the
'scientific customers' for my software use Windows (and at my age and
baseline crankiness, I don't convert easily to anything).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Massimo wrote:

> I have only tried a little wxmpl, and still didn't try MPlot, but I was
> wondering: can MPlot be rewritten using WxMpl?

Definitely.  Volunteers welcome.  My only advice here would be to
remember that bridging wxPython and matplotlib should use the best of
both and that the maintainers will have to know both, but the users of
the library should probably not have to know anything about
matplotlib, because they're going to be asking "I'm writing this wx
Application and want to include a graph -- what should I use?".

> In this way we wouldn't have to "choose" and to fork the goal of a
> unified wxPython/MPL solution. Instead, we would have a flexible stack
> of solutions at different levels. WxMpl would stay less or more as it
> is, providing a quite low level interface for people who need/like it (I
> feel I'm among these people, although it's still very possible to change
> my mind). On top of it, MPlot would extend WxMpl, creating advanced
> wrappers and controls to ease things for who needs "intermediate"
> scripting (a need that I think is very real). And possibly in future
> Pylab would stay on top of this stack, using MPlot and WxMpl to deal
> with interactive plotting.

I agree.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John wrote:

> Ken, Matt: would either or both of you like to bundle these packages
> into the mpl releases so they would be easier for users to find and
> use?  We could either put them in the main release or in a "toolbox".

This is OK with me, but I can go either way.  I sent MPlot to you over
a year ago and suggested that it could be included with MPL.  At the
time, I think you had no 'toolbox' model for that kind of thing.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Andrew wrote:

> My idea is for an interaction model similar to most spreadsheet graph
> objects (e.g. Excel), where context menus control the individual
> components of the plot(s).  Perhaps with introspection, many of the
> customizable features could be automatically extracted and presented to
> the user, so that menus and dialog boxes wouldn't have to be completely
> coded by hand.
>
> I'd like the plot to appear simple (by default), but with suitable
> access (perhaps triggered by mouseover?) to hidden features like a
> toolbar, scrollable axes, crosshair cursors (with coordinate readout),
> and zoom controls.
>
> I'm certainly willing and able to contribute to this development.  I'm
> conflicted as to which code base to begin with, however.

There's potentially a lot of flexibility and actions to trigger there.
With BLT (and Pmw.BLT) clicking on a component (say, a trace or label)
could cause a 'configure' box to modify its attributes (line color,
etc).  I found this could confuse users who would accidentally click
on things, but it's not a terrible model.  For MPlot, I made
Menu->Option->Configure or
right-click->pop-up->Configure bring up a form for many graph customization=
s.

To do this kind of interactivity, I believe that mpl would have to
support it, and that might be tricky using the wxAgg backend  (that
is, I'm not sure how easy it would be to convert coordinates on the
agg-image back to the Artist that rendered it).   So I think clickable
plot objects is a reasonable way to go, but I might not make it the
highest priority.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Ken wrote:

> > So, out of curiousity which of the *all* the features do you actually
> > use that can't be wrapped away to a higher level interface?
>
> I can't think of any features that can't be wrapped away into a higher le=
vel
> interface, at least hypothetically.  Things like creating two subplots th=
at
> share an X axis (so they zoom together) would be a bit hairy, but I'm sur=
e it
> could be done.

Oh, well I think this would get so application specific that it would
be just as easy to do it at the GUI level than at the MPL level.

> That being said, it would be frustrating if you had to periodically rewri=
te
> the user interaction code to add support new things, like subplots and
> overlapping Axes.  Providing this kind of support initially was an import=
ant
> goal while writing WxMpl.

Oh the 'user-level support code' is definitely the larger part of the
work for adding any plot type.  With imshow(), you'd need to provide a
GUI to choose color tables and scalebars to adjust levels and
contrast, and have a place on the GUI for displaying coordinates and
intensities.  And of course, zooming, flipping, etc.  For the
application we both happen to most need false-color-maps for (x-ray
fluorescence), I'd also want a way to put overlay one map in red and
another in green (with user-selectable colors of course).  So adding
'axes.imshow()' is the easy part.  Thanks to matplotlib.  I did this
once with PIL and the Tk canvas -- and I'm using that program today,
as it turns out.

> > I've seen the matplotlib code, and have used a fair number of plotting
> > libraries in my day. The matplotlib results are wonderful, but the API =
is a
> > bit goofy, don't you think? Does FigureCanvas->Figure->Axes make sense =
to
> > you? I'd be OK with two of those, but I don't understand how three poss=
ibly
> > helps.
>
> I don't think it's goofy at all.  You have FigureCanvas because seperatin=
g out
> the thing that "draws" the figure is the best way to implement backend
> neutrality.  You have Figure and Axes (rather than just Axes) because tha=
t's
> the best way to implement things like subplots, plotting overlapped axes,=
 and
> figimage(), colorbars, and figure legends.

I think we agree: the hierarchy is implementation driven, not use driven.

> > A grid of multiple plots  is certainly possible by packing
> > panels together.
> That's not quite what I meant:
>        http://matplotlib.sourceforge.net/examples/shared_axis_demo.py

All I'm saying is that this _could_ be handled at a GUI level.  The
advantage there is that you absolutely know someone using a wxPython
plotting widget will know wxPython, whereas their understanding of
matplotlib may be zero.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Fernando said:

> > >I'm also really very concerned about the priority given to pylab and i=
python.
> >
> > I'm really concerned about it too. As a MPL newbie, I found it very
> > misleading. I'd like to see a full programming stack on top of MPL, wit=
h
> > pylab, MPlot and wxMpl being integrated components of it, and with a
> > nice documentation about it.
>
> Chill out, there is no dark plan here :)  It's simply a matter of usage
> patterns: my personal audience is one of other programmers, I'm mostly an
> algorithms developer and the code I write is used by other mathematicians=
,
> physicists, etc. to write programs.

I think Fernando is not quite understanding the concern or complaint.=20
I also don't think anyone is 'hot' about it either.  And I know that
Ken and I both "understand how free software works".  As it turns out,
I'm mostly 'an algorithm developer' too and write open source
applications that other scientists use as well.

Certainly IPython is very nice, and has an important niche -- I've
even used it a couple of times myself.  The issue (for mpl) is that it
may appear to be the "normal" way one uses mpl.  I do find that to
similar to confusing python with IPython.  IPython is one way to use
python, but it's not only way .... and it's not driving decisions
about python.

For mpl, I believe that the 'make a wx mainloop for a command-line
program' did drive some fairly ugly business in backend_wx.py that
ended up making it harder to use backend_wx for GUIs.  I tried to
patch this to be favor GUI writers, but the conflict was resolved in
favor of the wx-mainloop-in-commandline.  I believe this may be fixed
now.

More importantly, when discussing matplotlib the usage is generally
given in terms of pylab, and often 'from pylab import *', which
conveys the idea that matplotlib is intended for writing quick-n-dirty
code.  And, as you can see from this discussion, the best way to use
it in real GUI applications is not always well resolved <wink>.    So
it is easy to conclude that pylab and ipython -pylab are given
priority.

I stand by my concern about this, and  I think you're missing an
important point if you easily dismiss the fact that Massimo's found
this to be misleading.

Finally, I'll be out of town and won't be able to respond for at least
a week.  Sorry this was so long, and thanks again.

-Matt

massimo sandal wrote:

>> So relax, nobody is trying to be misleading about anything, we're all
>> here simply working on what each of us needs, so the evolution process is
>> rather inhomogeneous.
> 
> 
> Perhaps I hadn't been clear. I'm not complaining of features missing. I'm
> just saying that, for example, the docs are misleading, because they focus
> on pylab when they would have to show both pylab and the OO interface.

The docs don't "have" to show anything: they are as complete as the people who 
wrote them have had the time/energy/interest/ability to make them.

It may well be true that the OO interface is under-documented (I don't know). 
If that is the case, then a worthwhile contribution woudl be to write such 
documentation, or to organize the existing one better.  The mpl wiki cookbook 
is there for all to contribute, so you don't even need to bottleneck on John's 
time or resources. A good set of OO pages/tutorials on the wiki, with examples 
and summaries of WXMPL/MPlot/whatever would (if it doesn't exist already) be 
an excellent contribution that users can make.

John has already explicitly said that he'd like to see wxmpl/mplot included, 
so he's obviously open to contributions on this front.

Cheers,

f

On 12/1/05, Charlie Moad <cw...@gm...> wrote:
>      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.

Hi matplotlib'ers!
while the end result in matplotlib is starting to "get there", the speed is
not yet where it has to be to be useful IMO. I hereby post a little challen=
ge
for the matplotlib developers;

get the actual plotting time (from the first plot command until show is don=
e)
on the below dataset down to less than a second,(including the quiver
command in the plot.py file).

download the 3 files here (ca 600kb in total)

http://www.ii.uib.no/~avle/slow1/

execfile('plot.py') to plot the dataset (works for me with cvs as of today)=
.
 the first part of the file is just some convenience funcs for loading
the data. the plotting happen near the end.

this is a moderately sized grid, 433x560 cells (those of you into
oceanography may recognize the area). what I observe on my pentium
2.54ghz linux box:

-after "data ok" on screen, it takes ca15s to render. pygist uses < 0.5s
-zoom operations take ca 5s. pygist is "instant".
-you don't want to wait for an additional quiver layer. it must take
minutes to finish. pygist is instant. with quiver, also zooming is
equally slow, the ui freeze for ages.
-often one wants to add contours from other fields on top of this, in
pygist this adds no
 visible delay, matplotlib easily doubles the rendering time.

typical usage for me is to load many such datasets, and do a lot of
zoom in/out/pan to various features, modify colors/levels, add
velocity vectors etc. currently this is quite
painful in matplotlib, as one zoom operation on realistic datasets
easily takes 10 seconds on a multi ghz machine. pygist is very fast,
even on a 400mhz laptop, memory usage is also a lot lower.

so, I think matplotlib is a great effort, and shows a lot of promise, but
for realistic use, it is (at least for me) still far too slow!

Helge

On 12/02/05 09:26, And...@gt... wrote:
> I'd like to have many more features available to the user than are
> currently provided by Mplot, but when I'm coding I'd like to be able to
> drop in a complete panel without having to do the coding that I'd need to
> do with WxMPL.

It sounds you'd like to see a library with a simplified API that supports most 
kinds of plots while letting users edit things like the axes title, line 
width, number of histogram bins, etc.  Am I correct?

> Perhaps with introspection, many of the customizable features could be
> automatically extracted and presented to the user, so that menus and dialog
> boxes wouldn't have to be completely coded by hand.

I would definitely go with introspection and declarative programming.  First, 
come up with a reasonable object picking algorithm (see the `object_picker.py' 
example).  Let matplot manage all of the plot objects' data (axes title, line 
style, edge color, etc).  Use declarative programming to define the editable 
parameters for each object.  Finally, use introspection to map between type of 
the object and the list of editable parameters.  PEP 246 adaption might be 
useful here, since it would let you break the tight coupling between types and 
their parameters:

	def OnPickObject(self, evt):
		obj = evt.object
		params = adapt(obj, IObjectParameters, None)
		if params is not None:
			frame = ObjectEditorFrame(self, params)
			frame.Show()

	# ...imagine that ObjectEditorFrame looks something like right hand
	# side of the window on page 15 of
	# 	http://www.python.org/pycon/papers/chaco.pdf
	# except that is automagically builds its contents based on the
	# its IObjectParameters argument.

It might be a good idea to bug John about matplotlib transitioning to using
the Traits package from Enthough, which would take care of managing the object
parameters for you. They developed it for use in their Chaco plotting library,
which went MIA shortly after release.

> I'd like the plot to appear simple (by default), but with suitable
> access (perhaps triggered by mouseover?) to hidden features like a
> toolbar, scrollable axes, crosshair cursors (with coordinate readout),
> and zoom controls.

A toolbar that pops up via mouseover would be pretty impressive, but I can't 
think of a way to implement it off the top of my head.  I'm not sure what you 
mean by "scrollable axes".  Do you mean pannning, the way pylab plots work? 
Crosshair cursors are easy and coordinate readout are pretty easy and I 
believe they already work in both MPlot and WxMpl.  Likewise zoom controls.

> I'm certainly willing and able to contribute to this development.  I'm
> conflicted as to which code base to begin with, however.

I'm not sure what to recommend.  Merging MPlot and WxMpl so that MPlot uses 
WxMpl for rendering and plot-level user interactions like zooming would be one 
way to start.  I think you'd probably be better off going with a more dynamic 
approach to parameter editing, since it would be a bit more work up front but 
a lot less work to add plot types.  If done right, the object picking and 
parameters stuff could even be backend independent.

Ken

John,

I would be inclined to vote for the toolbox option.  I gather that these 
are substantial backend-specific extensions, so they don't seem very 
appropriate for the main mpl package.  Disclosure: I don't use wxpython 
and haven't tried it recently.

Eric


> Ken, Matt: would either or both of you like to bundle these packages
> into the mpl releases so they would be easier for users to find and
> use?  We could either put them in the main release or in a "toolbox".
> 
> JDH

>You need to understand that this is simply how free software works: =
when=20
>someone needs something badly enough _for themselves_, they get off =
their butt=20
>and write it.  Then it's available for all to use (if released).  I did =
that=20
>for interactive mpl support over a year ago, so that's why it's been=20
>prominently displayed for a while (and this _is_ useful to a lot of =
people,=20
>since quick-and-dirty interactive data analysis is a very common task). =
 Now=20
>you guys are doing the same for WX tools, and that's fantastic.   I'm =
sure=20
>John will advertise it equally prominently.

>So relax, nobody is trying to be misleading about anything, we're all =
here=20
>simply working on what each of us needs, so the evolution process is =
rather=20
>inhomogeneous.

Perhaps I hadn't been clear. I'm not complaining of features missing. =
I'm just saying that, for example, the docs are misleading, because they =
focus on pylab when they would have to show both pylab and the OO =
interface. Pylab is a wonderful feature of MPL, but it's not the only =
one. I'm relaxed, I just feel that it's quite sad to focus only on pylab =
when users would like to know about the beautiful programming interface =
that already exists and that lies beneath.

m.

massimo sandal wrote:

>>I'm also really very concerned about the priority given to pylab and ipython.
> 
> 
> I'm really concerned about it too. As a MPL newbie, I found it very
> misleading. I'd like to see a full programming stack on top of MPL, with
> pylab, MPlot and wxMpl being integrated components of it, and with a
> nice documentation about it.

Chill out, there is no dark plan here :)  It's simply a matter of usage 
patterns: my personal audience is one of other programmers, I'm mostly an 
algorithms developer and the code I write is used by other mathematicians, 
physicists, etc. to write programs.  Hence,  command-line, interactive use is 
_my_ priority, and I did the work (along with John's and others' help) to make 
sure that mpl would work as well as possible in this context.  I have 
currently no need to write GUIs, so I haven't worked on that.  Others also 
liked these capabilities, and contributed for example the interactive Qt support.

I think it's great that a nice set of OO, high-level tools is being developed 
for MPL with WX, I may even need those in the future.  If others need similar 
Qt or Tk-based tools they may also develop them, which is great as well.

You need to understand that this is simply how free software works: when 
someone needs something badly enough _for themselves_, they get off their butt 
and write it.  Then it's available for all to use (if released).  I did that 
for interactive mpl support over a year ago, so that's why it's been 
prominently displayed for a while (and this _is_ useful to a lot of people, 
since quick-and-dirty interactive data analysis is a very common task).  Now 
you guys are doing the same for WX tools, and that's fantastic.   I'm sure 
John will advertise it equally prominently.

So relax, nobody is trying to be misleading about anything, we're all here 
simply working on what each of us needs, so the evolution process is rather 
inhomogeneous.

Cheers,

f

On 12/02/05 04:54, massimo sandal wrote:
> Hey, I didn't want to start a flamewar on all this!

It's not a flamewar!  Matt and  haven't began maligning each other's ancestry 
yet!  :-)

> I just want to understand the objectives of the three projects.
> It is true in your opinion?

I'd say you've got it right.

>> I understand that for _you_ a library that wx-dresses
>> matplotlib is OK, but why not try to have a good feature-rich plotting
>> package for wxPython?
> 
> I have only tried a little wxmpl, and still didn't try MPlot, but I was
> wondering: can MPlot be rewritten using WxMpl?

It certainly could.  WxMpl could take care of the basic user interaction stuff 
(e.g. zooming), leaving MPlot to focus on plot editing features.

> But it's true that there are situation in which you badly need something
> like that. I think the "stack" solution can be an idea.

I really like the idea of stacking the different levels of abstraction on top 
of each other.  It would allow us to reduce code duplication without limiting 
what application developers can do with matplotlib.

>> I'm also really very concerned about the priority given to pylab and 
>> ipython.
> 
> I'm really concerned about it too. As a MPL newbie, I found it very
> misleading.

I haven't really given it much thought.  Most people presumably use MPL from 
IPython or scripts via pylab, so focusing documentation efforts on it make 
sense.  I think that getting a good OO API manual would really improve things 
for application developers, but might be hard to justify in the big-picture.

Ken

    You guys are having a great discussion about using matplotlib with
wxWindows in many different ways.  I just wanted to chime in and let
any other lurkers know that matplotlib can also be easily embedded in
GTK apps with PyGTK.  I've done this several times to make small
applications that help me in data analysis.  The examples directory is
a great place to start.
    I don't have any experience with matplotlib+PyGTK on platforms
other than Linux.  (Ahh, the joys of scientific programming: now
Windows.)  Perhaps wxWindows handles cross-platform apps better, I'm
not qualified to answer.
    If other people are interested, I could try writing up a Wiki page
with one of my small "matplotlib embedded in a GTK app" programs.
--
    -- Graeme
    gra...@gm...

> -----Original Message-----
> From: massimo sandal [mailto:mas...@un...]=20
> Sent: Friday, December 02, 2005 10:47 AM
> To: Henshaw, Andy
> Cc: mat...@li...
> Subject: Re: [Matplotlib-users] advice on writing an application
>=20
> > [...]
> > I'm certainly willing and able to contribute to this=20
> development.  I'm=20
> > conflicted as to which code base to begin with, however.
>=20
> Tell me what do you think too about the "stack model" I=20
> proposed a couple of posts above. I'd like to help with it,=20
> but I'm still very much in the learning phase...
>=20
> Massimo

Not sure, at this point, but it seems to be a reasonable approach.
You'd need a stacking model that allows the end-programmer to cleanly
access the functionality of the lower levels, however.

Andy Henshaw
Georgia Tech Research Institute

> Sorry to horn in here, but this is a topic in which I am very
> interested.  What I want is both of these solutions combined!  I'd like
> to have the full power of MatPlotLib when I'm developing my
> applications, but, I'd also like to have (nearly) that full power
> presented to the user for further customization and interaction.  I'd
> like to have many more features available to the user than are currently
> provided by Mplot, but when I'm coding I'd like to be able to drop in a
> complete panel without having to do the coding that I'd need to do with
> WxMPL.
> [...] 
> I'm certainly willing and able to contribute to this development.  I'm
> conflicted as to which code base to begin with, however.

Tell me what do you think too about the "stack model" I proposed a 
couple of posts above. I'd like to help with it, but I'm still very much 
in the learning phase...

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

>On 12/01/05 16:13, Matt Newville wrote:
>> Here's what I think the fundamental differences are.  Maybe Ken can=20
>> give an opinion too.

> My take on things is that WxMpl and MPlot solve two different
problems. =20
> WxMpl is intended to be a FigureCanvasWxAgg that has some
pointy-clicky=20
> user interactions (e.g. zoom) built in.  I gather that Matt considers=20
> it "focused on the programmer/script writer, not on the end user=20
> of an application" because it doesn't provide end-users with any means
> to edit the plot.  MPlot lets users interactively change the title,
> axes labels, etc.
>=20
> I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his=20
> approach wasn't solving my problem: I was thrilled what matplotlib=20
> and wanted *all* of it to Just Work with wxPython. Allowing users=20
> to edit plots was less important to me than supporting as many kinds
> of plots as possible.  By focusing on adding user interaction to=20
> FigureCanvasWxAgg I was able to support all of matplotlib's OO API
> in one fell swoop.

Sorry to horn in here, but this is a topic in which I am very
interested.  What I want is both of these solutions combined!  I'd like
to have the full power of MatPlotLib when I'm developing my
applications, but, I'd also like to have (nearly) that full power
presented to the user for further customization and interaction.  I'd
like to have many more features available to the user than are currently
provided by Mplot, but when I'm coding I'd like to be able to drop in a
complete panel without having to do the coding that I'd need to do with
WxMPL.

My idea is for an interaction model similar to most spreadsheet graph
objects (e.g. Excel), where context menus control the individual
components of the plot(s).  Perhaps with introspection, many of the
customizable features could be automatically extracted and presented to
the user, so that menus and dialog boxes wouldn't have to be completely
coded by hand.

I'd like the plot to appear simple (by default), but with suitable
access (perhaps triggered by mouseover?) to hidden features like a
toolbar, scrollable axes, crosshair cursors (with coordinate readout),
and zoom controls.

I'm certainly willing and able to contribute to this development.  I'm
conflicted as to which code base to begin with, however.

Andrew Henshaw
Georgia Tech Research Institute

> Ken, Matt: would either or both of you like to bundle these packages
> into the mpl releases so they would be easier for users to find and
> use?  We could either put them in the main release or in a "toolbox".

As a (new) MPL user, I think it's an excellent proposal. Both WxMpl and 
MPlot are MPL extensions, anyway, and they're probably extremly useful 
for a large proportion of MPL users.

I'd like to know what do you all think about the wxmpl < mplot < pylab 
stack idea, by the way...

m.

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

>>>>> "Ken" == Ken McIvor <mc...@ii...> writes:

    Ken> Matplotlib is an incredible piece of software.  I agree with
    Ken> you, John deserves to be knighted.

Just let me know when and where to show up :-)

    Ken> P.S.  Since Matt posted a short MPlot example, I figured I
    Ken> should post a short WxMpl counter-example :-P

Ken, Matt: would either or both of you like to bundle these packages
into the mpl releases so they would be easier for users to find and
use?  We could either put them in the main release or in a "toolbox".

JDH

Hi,
interpolation seems not to be supported for pcolor plots. Is that true? I want
to plot nonaequidistant gridded data, so imshow is not the right choice. Using
contourf with a large number of contour levels works fine but the eps output is
huge. I'd prefer to have the image embedded as bitmap in an eps, that's why I'd
like to use pcolor.
Regards, Christian

Hey, I didn't want to start a flamewar on all this!
Please breath! :)

  >>My take on things is that WxMpl and MPlot solve two different problems.

Here's how I do see things now, based on your descriptions:

- pylab is made for pure interaction or quick-and-dirty (but
nevertheless useful) scripts for interactive data analysis
- MPlot is thought "in between", for advanced scripting or simple
programming: it allows the end user to do quite complex things with not
so much programming and other users of the script to interact with the
plot, giving up some strict programming flexibility.
- wxMpl is thought for programming: it requires knowledge of WxWidgets,
a bit more abstraction and careful thinking from the programmer, but it
gives maximum flexibility.

Note that I said "is thought", not "is made only for": it is surely
possible to script with wxMpl and to do advanced programming with MPlot.
I just want to understand the objectives of the three projects.
It is true in your opinion?

> Well, that and the fact that to use wxMPL you have to understand
> matplotlib.  Like, that
> a figure has an axes, and axes has  'plot()' and 'imshow()'.

Well, I see nothing really bad in it. To fully use the power of a
library, I guess you should understand how does the library works, or at
least what its APIs are.

>>I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his approach
>>wasn't solving my problem: I was thrilled what matplotlib and wanted *all* of
>>it to Just Work with wxPython.
> I think it would be much better for everyone if we could work on a
> single solution and I was pretty disappointed when I showed you what I
> had and you went off and wrote something else that fills very many
> similar niches.  I'm sure MPlot is not as fancy or subclassed as
> wxMPL, but having a common wxPython plot control based on matplotlib
> that was easy to use and just ready to plug into an application would
> be better for everyone, I think.
  >[...]
  > I understand that for _you_ a library that wx-dresses
  > matplotlib is OK, but why not try to have a good feature-rich plotting
  > package for wxPython?

I have only tried a little wxmpl, and still didn't try MPlot, but I was
wondering: can MPlot be rewritten using WxMpl?
In this way we wouldn't have to "choose" and to fork the goal of a
unified wxPython/MPL solution. Instead, we would have a flexible stack
of solutions at different levels. WxMpl would stay less or more as it
is, providing a quite low level interface for people who need/like it (I
feel I'm among these people, although it's still very possible to change
my mind). On top of it, MPlot would extend WxMpl, creating advanced
wrappers and controls to ease things for who needs "intermediate"
scripting (a need that I think is very real). And possibly in future
Pylab would stay on top of this stack, using MPlot and WxMpl to deal
with interactive plotting.

>>Allowing users to edit plots was less important to me than supporting as many kinds of
>>plots as possible.
> 
> Really? I find this hugely important.  For mapping, it will be vital
> to allow the user to adjust contrast and change color maps, where
> user-driven changing of data value -> display is critical for
> understanding the data.

Well, it depends on the data you're using and on what you're doing. For
the work I'm planning, I don't need all of this: I'd prefer integration
into an application and full MPL support.
But it's true that there are situation in which you badly need something
like that. I think the "stack" solution can be an idea.

> Yes, provided you know matplotlib.  Which is, to be fair, kind of
> quirky.  I mean is all of
>     app = MyPlotApp()
>     figure = app.get_figure()
>     axes = figure.gca()
>     axes.plot(x,y)
> 
> really necessary?    I've seen the matplotlib code, and have used a
> fair number of plotting libraries in my day. The matplotlib results
> are wonderful, but the API is a bit  goofy, don't you think?  Does
> FigureCanvas->Figure->Axes make sense to you?   I'd be OK with two of
> those, but I don't understand how three possibly helps.

I think having the 'privilege' to deal with object properties is good in
the end for the programmer, although it can be confusing for the noob.

> I'm also really very concerned about the priority given to pylab and ipython.

I'm really concerned about it too. As a MPL newbie, I found it very
misleading. I'd like to see a full programming stack on top of MPL, with
pylab, MPlot and wxMpl being integrated components of it, and with a
nice documentation about it.

>>As I said earlier, I think we're trying to solve different problems. I do want
>>to use the low-level matplotlib API, because it's a more flexible and
>>powerful.  If necessary, I want to be able to say in a wxPython program "make
>>a wxPlotter and then make two subplots, one a line plot with two embedded
>>axes, the other a histogram and a line plot, and then chain their X axes
>>together".
> 
> How often do you actually do this?  Does it need a library?   I'd
> guess 80% of the results could be had with a much higher-level
> interface.  A grid of multiple plots  is certainly possible by packing
> panels together.  I  don't use histograms or bar graphs much myself,
> but these would be trivial to add to something with a more MPlot- (or
> if you like, more BLT-)like interface.

You have different needs. I feel next to the needs of Ken, but for
example my desktop neighbour here that does AFM imaging would feel on
the side of Matt. It is useless to say "how often do you do this?",
because you don't know what my needs are. I think a scientific library
should be as much general and agnostic as possible.

> I think you may be in the mindset of a library-writer where 'user' is
> an application developer. The question was about writing applications,
> and there User is the person running the program.  They care 0% about
> the cleanliness of the API, but if the fonts too small or they change
> the red solid line to blue dots, the program sucks.

I think the user wants to see a good program. I think the programmer
(that sometimes is the user, sometimes is not) has the responsibility to
care about usability details, not the user. So if the fonts are too
small, it's a problem that the programmer must solve. I'm all for
configuration (I hate people that say "configurability confuses users")
but it can be embedded in, let's say, a .myplotrc. But that's my
opinion, and I understand you want more direct user interaction, instead.

I understand you felt disappointed when you did MPlot and your friend (I
hope you're friends) went away and did something else. I think simply
you should try to collaborate to fit both niches in a coherent stack,
instead of competing for the wx and MPL union.

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 members

I have done a quick search of the archives, but did not find anything
information regarding my problem (or at least to my knowledge).  I have
written an application using wxPython and I am using embedded matplotlib
plotting to show some of the generated results.  This I have done fairly
similar to the embedding in wx examples presented for matplotlib and it
works fine with little effort.  So far so good.

My problem however is that I am unable to change my font style (it seems
to be Times New Roman or similar and I want it to be Arial) for the
labels ext., even though I can change just about everything else there
is to change, including font size, the coverage of the canvas by the
figure and so forth.  This I do be merely changing the matplotlibrc file
copied to my application directory.  Are there any suggestions or may be
a request for more detail information regarding my problem?

Regards

Johann Strauss

On 12/01/05 16:13, Matt Newville wrote:
> Here's what I think the fundamental differences are.  Maybe Ken can
> give an opinion too.

My take on things is that WxMpl and MPlot solve two different problems.  WxMpl 
is intended to be a FigureCanvasWxAgg that has some pointy-clicky user 
interactions (e.g. zoom) built in.  I gather that Matt considers it "focused 
on the programmer/script writer, not on the end user of an application" 
because it doesn't provide end-users with any means to edit the plot.  MPlot 
lets users interactively change the title, axes labels, etc.

I wrote WxMpl after Matt sent me MPlot 0.7 because I felt that his approach 
wasn't solving my problem: I was thrilled what matplotlib and wanted *all* of 
it to Just Work with wxPython. Allowing users to edit plots was less important 
to me than supporting as many kinds of plots as possible.  By focusing on 
adding user interaction to FigureCanvasWxAgg I was able to support all of 
matplotlib's OO API in one fell swoop.

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

Zooming and point-under-cursor are enabled by default.  You are correct, WxMpl 
provides no GUI tools to allow application users to alter plots.

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

Yep.  I've followed the BLT convention of zooming by selection a rectangular 
area and unzooming by right-clicking.

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

As always, there is a trade off involved.  In other words, MPlot would be a 
sensible choice if allowing users to edit their plots is very important. 
WxMpl makes sense if having access to all of MPL's plotting abilities is very 
important.  Furthermore, there's nothing stopping someone from adding support 
for more kinds of plots to MPlot or from building a plot editor on top of 
WxMpl, if they were so inclined.

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

Well I'd say it's a wxPython plotting widget that lets you build plot editors. 
  I guess it all depends on your definition of "wxPython plotting widget".  :-)

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

As I said earlier, I think we're trying to solve different problems. I do want 
to use the low-level matplotlib API, because it's a more flexible and 
powerful.  If necessary, I want to be able to say in a wxPython program "make 
a wxPlotter and then make two subplots, one a line plot with two embedded 
axes, the other a histogram and a line plot, and then chain their X axes 
together".

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

I hadn't considered "end users" when writing WxMpl, on the notion that they 
weren't going to be writing their own wxPython applications any time soon. 
That being said, I have added some convenience classes to make WxMpl easier to 
use for ad hoc plotting.

> In my opinion, MPlot ends up looking a lot better than wxPyPlot -- all
> because of matplotlib.

Matplotlib is an incredible piece of software.  I agree with you, John 
deserves to be knighted.

Ken


P.S.  Since Matt posted a short MPlot example, I figured I should post a short 
WxMpl counter-example :-P


import wxmpl
import matplotlib.cm as cm
import matplotlib.mlab as mlab
import matplotlib.numerix as nx

dx, dy = 0.025, 0.025
x = nx.arange(-3.0, 3.0, dx)
y = nx.arange(-3.0, 3.0, dy)
X,Y = mlab.meshgrid(x, y)
Z = (1- X + X**5 + Y**3)*nx.exp(-X**2-Y**2)

class MyPlotApp(wxmpl.PlotApp):
     ABOUT_TITLE = 'WxMpl Example'
     ABOUT_MESSAGE='Behold! An example!\nCopyright 2005 Yoyodyne Inc'

app = MyPlotApp(title='WxMpl Example')
figure = app.get_figure()
axes = figure.gca()

img = axes.imshow(Z, cmap=cm.jet, extent=(-3, 3, -3, 3))
figure.colorbar(img)
axes.set_title('$(1 - X + X^5 + Y^3)*e^{\/^{(-X^2-Y^2)}}$')
axes.set_xlabel('X Axis')
axes.set_ylabel('Y Axis')

app.MainLoop()

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