matplotlib-users Mailing List for matplotlib

>>>>> "Delbert" == Delbert D Franz <iq...@so...> writes:
 Delbert> After downloading and installing these two packages all
 Delbert> but date_demo_rrule.py completed properly. The error in
 Delbert> this case was an unknown name "rand". A check of the
 Delbert> Python Library reference stated it was obsolete. I
 Delbert> replaced it with random.randrange but got another error,
 Delbert> an assertion error apparently on the y value. Being
 Delbert> somewhat new to Python and even newer to matplotlib I
 Delbert> gave up on that demo.
 Delbert> Perhaps someone else can test date_demo_rrule.py and see
 Delbert> what happens. It is always a good thing when demos in
 Delbert> fact run!
True! But all of these demos do run for me. I suggest you flush your
existing matplotlib by removing site-packages/matplotlib and your
"build" directory and reinstall from the official source at
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=281218.
Please follow the instructions at
http://matplotlib.sourceforge.net/installing.html, eg make sure you
have numeric or numarray installed when you compile matplotlib.
Let us know if you have more troubles, and please include a full
traceback from one of the date demos and run it with
> python date_demo1.py --verbose-helpful
and report the output.
 Delbert> I am also testing under MS Windows and the dateutils and
 Delbert> pytz files came with that install but none of the example
 Delbert> files came. Not sure why they are not included in the
 Delbert> *.exe installer.
It's a distutils thing. Suggestions here welcome.
JDH

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:
 Chris> One thing that could help here is if all the drawing
 Chris> commands were "vectorized". This would mean that rather
 Chris> than asking the back-end to draw one primitive at a time, a
 Chris> whole set could be passed in. This would allow the back end
 Chris> to possibly optimize the drawing of the set. An example is
 Chris> wxPython's DC.DrawXXXList() methods. These methods take a
 Chris> python sequence of drawing primitives, and loop through
 Chris> that sequence in C++ code. It makes a huge difference when
 Chris> drawing simple objects, like points or line segments.
 Chris> I haven't looked closely at the matplotlib code to see if
 Chris> this can be done, but it could make a difference.
This is basically what collections already do --
http://matplotlib.sourceforge.net/matplotlib.collections.html.
Typically when we find an area of code where a bunch of primitives are
being drawn independently, we refactor them as a collection. There is
a default draw implementation in python that the backends can override
in extension code (as agg does). Even if you just use the default
python drawing implementation, eg
backend_bases.RendererBase.draw_line_collection, the result is much
faster that instantiating a large number of independent objects.
Every property in a collection is a sequence (might be just length
one) and the drawing code iterates over the collection and gets the
value of a property for the i-th element of the collection as
 thisprop = prop[i % len(props)]
So if you have a len(1) list, every element in the collection shares
the prop, if you have a len(props) list, every element has a unique
property and < len(props) the props cycle.
Actually, a dictionary mapping element index to property value, which
has a default value, would be more flexible, and the performance hit
might not be bad. Might be worth refactoring.
Actually, the code to plot line markers could be sped up by using
collections to draw line markers. Currently we're using plain old
python loops for this. 
JDH

Perry Greenfield wrote:
>> Actually, I believe that the low level contour engine we are using
>> supports this. It takes 2-d arrays for both x and y that represent
>> the x and y coordinates of the array being contoured and generates
>> plotting points based on those x and y arrays. These arrays allow
>> for irregular grids.
completely irregular? or only orthogonal structured grids. From your 
description, it sounds like the later. Could it take an unstructured set 
of (x,y,z) points and contour the z values?
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Peter Groszkowski wrote:
> I use Hardy's multiquadric interpolation to to do the math, then use 
> imshow (or pcolor) to make a surface map. I only have data for the 120 
> points (where the circle are - those are actuators), and interpolate the 
> rest.
> 
> If people are interested, I can clean up the code a little and post it.
Please do.
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Perry Greenfield wrote:
>
> On Dec 9, 2004, at 2:12 PM, Chris Barker wrote:
>
>> LUK ShunTim wrote:
>>
>>> As it's being implemented, here is a little wish. I'd like to see 
>>> the capability of contouring on an arbitrary grid. That is, 
>>> matplotlab would be able to plot the contours of a function f(x_i, 
>>> y_i) given on an arbitrary set of points (x_i, y_i), not necessarily 
>>> set out on a regular grid.
>>
>>
>> This would be nice, but it's a bit of a project. One way to do it 
>> would be to Delaunay triangulate the points, then you can compute the 
>> contours from the triangular grid. Delaunay triangulation is not 
>> trivial, and you really want to use an efficient scheme to do it. One 
>> possibility is:
>>
>> http://www-2.cs.cmu.edu/~quake/triangle.html
>>
>> It is very robust and fast, and can be compiled as a library. I've 
>> been planning for ages to write a Python wrapper for it, but haven't 
>> gotten to it yet.
>>
>> If someone works on this, I'd like to help.
>>
>> -Chris
>>
>
> Actually, I believe that the low level contour engine we are using
> supports this. It takes 2-d arrays for both x and y that represent
> the x and y coordinates of the array being contoured and generates
> plotting points based on those x and y arrays. These arrays allow
> for irregular grids. At the moment, the routine generates uniform
> x and y grids as arguments to pass along, but it could be generalized
> to take these as extra arguments without much trouble.
I use Hardy's multiquadric interpolation to to do the math, then use 
imshow (or pcolor) to make a surface map. I only have data for the 120 
points (where the circle are - those are actuators), and interpolate the 
rest.
If people are interested, I can clean up the code a little and post it.

Hi,
I'm doing relatively simple line plots the WXAgg backend, but I
also find matplotlib to be somewhat slower than I'd hope for.
On a WindowsXP box (P4 1.7GHz, 512Mb RAM), in a wx event loop
issuing a plot() as fast as I can go, I get about 1 plot every
0.25 to 0.30 sec. This is just barely fast enough for my needs. 
If I could reliably go at 10 plots/sec, that would be great.
It turns out that the dynamic_demo_wx.py example does go much
faster, but it does not actually re-do a plot(). Instead it just
changes the subplots line data. That's interesting, but I need
the view to be adjusted as well, as the scale will change with
time for my data. So far, I'm just re-issuing plot(), but I'd be
willing to do something slightly fancier.
Anyway, that led me to try to track down where the slowness in
plot() was coming from. Using nothing more sophisticated than
print statements, I believe the performance bottleneck is in
axis.py in Axis.draw(), in this block:
 for tick, loc, label in zip(majorTicks, majorLocs, majorLabels):
 if not interval.contains(loc): continue
 seen[loc] = 1
 tick.update_position(loc)
 tick.set_label1(label)
 tick.set_label2(label) 
 tick.draw(renderer)
 extent = tick.label1.get_window_extent(renderer) 
 ticklabelBoxes.append(extent)
For me, this block (run twice for a plot()) typically takes at
least 50% of the plot time. Commenting out the
tick.draw(renderer) and the following two 'extent' lines roughly
doubles the drawing rate (though no grid or ticks are shown). I
was surprised by this, but have not tracked it down much beyond
this. I'm not using mathtext in the labels and had only standard
numerical Tick labels in this example.
I don't know if this is applicable to the slowness of the contour
plots or error bars or if collections would help here. But it
doesn't seem like tick drawing should be the bottleneck. Anyway,
this seems like a simple place to test in other situations, and
may be a good place to look for possible optimizations.
Thanks, 
--Matt

On Dec 9, 2004, at 2:33 PM, Perry Greenfield wrote:
>
> Actually, I believe that the low level contour engine we are using
> supports this. It takes 2-d arrays for both x and y that represent
> the x and y coordinates of the array being contoured and generates
> plotting points based on those x and y arrays. These arrays allow
> for irregular grids. At the moment, the routine generates uniform
> x and y grids as arguments to pass along, but it could be generalized
> to take these as extra arguments without much trouble.
>
> Let me know if I misunderstand what you are trying to do.
>
> Perry
>
Correction. It already supports that feature now (but it isn't
checked in yet).

On Dec 9, 2004, at 2:12 PM, Chris Barker wrote:
> LUK ShunTim wrote:
>> As it's being implemented, here is a little wish. I'd like to see the 
>> capability of contouring on an arbitrary grid. That is, matplotlab 
>> would be able to plot the contours of a function f(x_i, y_i) given on 
>> an arbitrary set of points (x_i, y_i), not necessarily set out on a 
>> regular grid.
>
> This would be nice, but it's a bit of a project. One way to do it 
> would be to Delaunay triangulate the points, then you can compute the 
> contours from the triangular grid. Delaunay triangulation is not 
> trivial, and you really want to use an efficient scheme to do it. One 
> possibility is:
>
> http://www-2.cs.cmu.edu/~quake/triangle.html
>
> It is very robust and fast, and can be compiled as a library. I've 
> been planning for ages to write a Python wrapper for it, but haven't 
> gotten to it yet.
>
> If someone works on this, I'd like to help.
>
> -Chris
>
Actually, I believe that the low level contour engine we are using
supports this. It takes 2-d arrays for both x and y that represent
the x and y coordinates of the array being contoured and generates
plotting points based on those x and y arrays. These arrays allow
for irregular grids. At the moment, the routine generates uniform
x and y grids as arguments to pass along, but it could be generalized
to take these as extra arguments without much trouble.
Let me know if I misunderstand what you are trying to do.
Perry

Arnd Baecker wrote:
> P.S.: I agree on the speed issues. Unfortunately
> most of the newer python graphics packages tend to be
> slower than older packages.
I think this has two reasons:
1) They are written more in Python, rather than wrapping an existing 
library written in C or whatever.
2) They often are back-end independent. This introduces an extra layer 
at every drawing command, and makes it difficult to take advantage of 
possible optimizations available for a given back end, like Arnd has 
done for his stuff.
One thing that could help here is if all the drawing commands were 
"vectorized". This would mean that rather than asking the back-end to 
draw one primitive at a time, a whole set could be passed in. This would 
allow the back end to possibly optimize the drawing of the set. An 
example is wxPython's DC.DrawXXXList() methods. These methods take a 
python sequence of drawing primitives, and loop through that sequence in 
C++ code. It makes a huge difference when drawing simple objects, like 
points or line segments.
I haven't looked closely at the matplotlib code to see if this can be 
done, but it could make a difference.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

LUK ShunTim wrote:
> As it's being implemented, here is a little wish. I'd like to see the 
> capability of contouring on an arbitrary grid. That is, matplotlab would 
> be able to plot the contours of a function f(x_i, y_i) given on an 
> arbitrary set of points (x_i, y_i), not necessarily set out on a regular 
> grid.
This would be nice, but it's a bit of a project. One way to do it would 
be to Delaunay triangulate the points, then you can compute the contours 
from the triangular grid. Delaunay triangulation is not trivial, and you 
really want to use an efficient scheme to do it. One possibility is:
http://www-2.cs.cmu.edu/~quake/triangle.html
It is very robust and fast, and can be compiled as a library. I've been 
planning for ages to write a Python wrapper for it, but haven't gotten 
to it yet.
If someone works on this, I'd like to help.
-Chris
-- 
Christopher Barker, Ph.D.
Oceanographer
 		
NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Chr...@no...

Am Donnerstag, 9. Dezember 2004 17:38 schrieb John Hunter:
> Note it
> would be possible to define setitem, getitem, and possibly setslice,
> getslice and iter for collections to make them behave more like lists
> of objects, which would be nice if we (you) want to make this change.
Would that be possible at all? Do individual items in a collection have an 
identity at all that could be exposed in Python? Do they have individual 
properties?
Note, that I probably won't have the time to look into this matter myself. 
Maybe one day, but certainly not in the near future.
Ciao,
Nobbi
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Hi,
1. slow plot
2. cursor issue
3. key press event !
-------
1/ 
Here is the piece of code which is quite slow I think. Compared to 
pgplot this
is a factor of more than 10. It does first draw a default plot (0,1 ?) 
and then
overplot on it for each subplot.
for this particular case I have 10 subplots. The slices are made of 
about 10-20
points each only (stored in a 3D array which is 48x5x20 points).
I hope this answers the question. Sorry for the ''specifics''.
 for i in arange(ncoef) :
 subplot(nrow, 2, i+1)
 if i > 1 :
 temparray = self.Vcoef[indgal][i][:minind] / 
self.Vcoef[indgal][1][:minind]
 plot(self.Vrad[indgal][:minind], temparray, 'b-o', ms=4)
 else :
 plot(self.Vrad[indgal][:minind], 
self.Vcoef[indgal][i][:minind], 'b-o', ms=4)
 ylabel('$C_{%d'%i+'}$')
 for i in arange(ncoef) :
 j = i + ncoef
 subplot(nrow, 2, j+1)
 plot(self.Vrad[indgal][:minind], 
self.Vphi[indgal][i][:minind], 'b-o', ms=4)
 ylabel('$\phi_{%d'%i+'}$')
2/ the cursor issue and how to interact with it:
yes indeed the solution I took is close to what is shown in some examples.
I used a new class which I then use later on in interactive mode or not.
Below is a simple/shortened example of the structure I create by just 
transferring
the data (x,y,key, etc) to the cursor structure. I can then use : toto = 
cursor()
to have it working. (I in fact define several different cursor_* classes 
for different purposes).
So sorry if my mail sounded like ''I have found a new way...''.
class cursor :
 def __init__(self):
 print 'Class initialized'
 self.figure = Figure()
 self.canvas = get_current_fig_manager().canvas
 self.canvas.mpl_connect('button_press_event', self.on_click)
 self.x = 0
 self.y = 0
 self.button = 1
 def on_click(self, event):
 self.x = event.x
 self.y = event.y
 self.xd = event.xdata
 self.yd = event.ydata
 self.button = event.button
 ...
3/ key press event
>Currently key_press_event is not implemented (though mouse move and
>motion to capture and report key presses as event.key). We added this
>because this is how we do the event handling across backends for the
>toolbar. There are also some fixes in CVS to make disconnects work
>properly, eg in the tk backend.
>
>It would be fairly straightforward to add a key_press_event under the
>same framework.
>
> 
>
That WOULD be great since this is exactly what I needed. For example being
able to type ''h'' to make an horizontal cut of my image at the location 
corresponding
to the mouse position.... I do that easily with ppgplot for example.
-- 
===============================================================
Observatoire de Lyon ems...@ob...
9 av. Charles-Andre tel: +33 4 78 86 83 84
69561 Saint-Genis Laval Cedex fax: +33 4 78 86 83 86
France http://www-obs.univ-lyon1.fr/eric.emsellem
===============================================================

>>>>> "Eric" == Eric Emsellem <ems...@ob...> writes:
 Eric> P.S.: by the way I solved the cursor problem I posted (and
 Eric> got no answer) by defining a new cursor class (something
 Eric> already hinted by many on the web), if anyone is
 Eric> interested..
Been out of town at meetings for the last week...
Have you seen
http://matplotlib.sourceforge.net/examples/coords_demo.py, which shows
how to connect to mouse motion and click? The interface is being
streamlined in 0.65. Ie in CVS, one simply needs to do
 def on_click(event): pass
 connect('button_press_event', on_click)
Currently key_press_event is not implemented (though mouse move and
motion to capture and report key presses as event.key). We added this
because this is how we do the event handling across backends for the
toolbar. There are also some fixes in CVS to make disconnects work
properly, eg in the tk backend.
It would be fairly straightforward to add a key_press_event under the
same framework.
For "cursoring", see the *cursor*.py examples in the examples subdir
of the matplotlib src distro.
But please also post your solution which may be useful....
JDH

>>>>> "Norbert" == Norbert Nemec <No...@ne...> writes:
 Norbert> I have experienced some extreme inefficiency using
 Norbert> errorbar plots for large datasets. Obviously, the
 Norbert> "hlines" routine is a huge bottleneck. Would it be
 Norbert> possible, in principle, to use an efficient collection
 Norbert> instead?
As Perry noted, it would be nice to see some of Eric's code to see if
this is the kind of bottleneck he is bumping into.
It would be very straightforward to use collections here is what they
were designed for - removing bottlenecks created by instantiating many
similar objects. I've never plotted a large number of errorbar lines
so haven't bumped into this one.
Note this might break some code which is relying on the fact that the
errorbar routing is returning a list of errorbar lines. collections
are designed to respond similarly to lists of lines under the set
command. Eg
 set(lines, color='r', linewidth=4)
and 
 set(collection, color='r', linewidth=4)
will both work.
But if someone is currently doing 
 lines[2].set_color('g')
or
 for line in lines:
 line.set_something(else)
there would be a backward incompatibility with this change. Note it
would be possible to define setitem, getitem, and possibly setslice,
getslice and iter for collections to make them behave more like lists
of objects, which would be nice if we (you) want to make this change.
Is anyone changing the properties of individual error lines returned
by errorbar?
JDH

Am Mittwoch, 8. Dezember 2004 16:35 schrieb Perry Greenfield:
> Could you give some indication of what speed you are getting vs what you
> have gotten under other plotting packages?
I have experienced some extreme inefficiency using errorbar plots for large 
datasets. Obviously, the "hlines" routine is a huge bottleneck. Would it be 
possible, in principle, to use an efficient collection instead?
-- 
_________________________________________Norbert Nemec
 Bernhardstr. 2 ... D-93053 Regensburg
 Tel: 0941 - 2009638 ... Mobil: 0179 - 7475199
 eMail: <No...@Ne...>

Perry Greenfield wrote:
> 
> On Dec 8, 2004, at 3:29 AM, Eric Emsellem wrote:
> 
>> Hi,
>>
>> I am now trying to switch from ppgplot to matplotlib and I
>> really like the latter for the much nicer plots and functionalities
>> (although limitations such as the absence of contour plots is a 
>> critical one).
> 
> 
> There is progress being made on contour plots. We've implemented a basic
> version that John Hunter is looking at now.
> 
It's really nice to hear that. As Eric said, it's one thing that is 
sorely missed.
As it's being implemented, here is a little wish. I'd like to see the 
capability of contouring on an arbitrary grid. That is, matplotlab would 
be able to plot the contours of a function f(x_i, y_i) given on an 
arbitrary set of points (x_i, y_i), not necessarily set out on a regular 
grid.
Regards,
ST
--

Delbert D. Franz writes:
 > I am evaluating matplotlib for its date handling for plotting time 
 > series produced by a unsteady-flow simulation package. 
 > I downloaded the Debian package from http://anakonda.altervista.org/debian
 > because I could not get apt-get to get the package after modifying
 > my sources.list. 
This problem went away for me when I upgraded
to date-util to version 0.5
https://moin.conectiva.com.br/DateUtil#head-f5cbdf6bfb51439be085b5c6b7460a7c91eabc3c
-- Phil

I am evaluating matplotlib for its date handling for plotting time 
series produced by a unsteady-flow simulation package. 
I downloaded the Debian package from http://anakonda.altervista.org/debian
because I could not get apt-get to get the package after modifying
my sources.list. 
However, dpkg did not complain about any missing packages and 
several test cases worked well. However, none of the following 
examples would run
date_demo1.py 
 error---cannot import date2num, num2date
date_demo2.py
 error--cannot import name MONDAY
date_demo_convert.py
 error--cannot import DayLocator, HourLocator
date_demo_rrule.py
 error--cannot import name YEARLY
After some time checking docs and looking at the various
*.py files involved, I noticed that none of the dateutl files 
were on my system and neither were the pytz files. 
The documentation on the web site clearly states that 
the dateutil files are included in the package but somehow 
they got missed in the 0.64-1 release downloaded from the
site given above. 
After downloading and installing these two packages all 
but date_demo_rrule.py completed properly. 
The error in this case was an unknown name "rand".
A check of the Python Library reference stated it was
obsolete. I replaced it with random.randrange but 
got another error, an assertion error apparently on 
the y value. Being somewhat new to Python and 
even newer to matplotlib I gave up on that demo. 
Perhaps someone else can test date_demo_rrule.py
and see what happens. It is always a good thing when
demos in fact run!
I am also testing under MS Windows and the dateutils
and pytz files came with that install but none of the 
example files came. Not sure why they are not 
included in the *.exe installer. 
I am using Python 2.3.4
matplotlib 0.64-1
Libranet 2.8.1
Kernel 2.6.9
 Delbert Franz 

 Hello,
I have a problem to plot some data.
I use "plot" to plot some data and "scatter" for other. I obtain a plot 
whith the point trace with "scatter" are behind the points from "plot". 
I tried to change the order in the script but that change nothing.
Do you know how to do this? (I want use scatter because I want have a 
specific size for this points)
Thanks,
 Nicolas