matplotlib-users Mailing List for matplotlib (Page 4)

>>>>> "Eric" == Eric Firing <ef...@km...> writes:
 Eric> John, For the command-line selection mechanism of numerix.py
 Eric> to work, the following change is needed:
 Eric> if which[0] is None: ## Add this line which =
 Eric> rcParams['numerix'], "rc"
 Eric> Otherwise, the rcParams value clobbers the command-line
 Eric> value.
Thanks for the alert on the numerix problem. The numerix module was
written before matplotlibrc existed and it appears was not properly
updated. It may be better to simplify this and only provide 2
choices, command line then rc file. Does anyone need any of the other
methods of choosing numerix? Is there any reason to keep .numerix or
the NUMERIX env var?
 Eric> Update on pcolor_demo2.py: strange things are going on, but
 Eric> now, using profile.py, I get 2.72 seconds with Numeric and
 Eric> 9.49 seconds with numarray. I don't have any explanation
 Eric> for why it was taking 80 seconds with numarray when I tried
 Eric> it earlier today. It is still much slower than with
 Eric> Numeric, though, which seems odd.
pcolor_demo2 uses imshow which is written in extension code using the
numerix/numarray compatibility layer. Todd and Perry can correct me
if I'm wrong, but I think you'll get better numarray performance if
you compile that extension with the 'NUMERIX = numarray' in setup.py.
The NUMERIX variable in setup.py determines which library the
extension code is compiled against. Whether you use numeric or
numarray, it will work with either, but you should get much better
performance if you match this compile flag to the library you use
most.
Let us know if this is indeed the cause of the performance hit. Here
are my numbers (best of three runs)
 rc setting 
 Numeric | numarray 
 compiled | 
 --------------------------------
 Numeric | 0.45s | 1.13s
 numarray | 0.59s | 0.60s
JDH

Eric Firing wrote:
> Update on pcolor_demo2.py: strange things are going on, but now, using 
> profile.py, I get 2.72 seconds with Numeric and 9.49 seconds with 
> numarray. I don't have any explanation for why it was taking 80 seconds 
> with numarray when I tried it earlier today. It is still much slower 
> than with Numeric, though, which seems odd.
> 
Numarray will be slower on "smaller" operations, in particular
if one is manipulating many small arrays, or looping over many
indiviual array element accesses. I haven't profiled it but
I'm guessing the difference lies in the list comprehension that
calculates the vertices which is doing many array indexings.
Perry Greenfield

John,
For the command-line selection mechanism of numerix.py to work, the 
following change is needed:
if which[0] is None: ## Add this line
 which = rcParams['numerix'], "rc"
Otherwise, the rcParams value clobbers the command-line value.
Update on pcolor_demo2.py: strange things are going on, but now, using 
profile.py, I get 2.72 seconds with Numeric and 9.49 seconds with 
numarray. I don't have any explanation for why it was taking 80 seconds 
with numarray when I tried it earlier today. It is still much slower 
than with Numeric, though, which seems odd.
Eric

John,
Numerix.py behaves quite differently from what its doc string says. 
Here is a revised doc string that describes how it behaves at present, 
with => highlighting the differences:
"""numerix imports either Numeric or numarray based on various selectors.
0. If the value "--numarray" or "--Numeric" is specified on the
command line, then numerix imports the specified array package.
1. The value of numerix in ~/.matplotlibrc: either Numeric or numarray
=>2. The value of numerix in /usr/share/matplotlib/.matplotlibrc, as above.
(**I don't know what the Windows equivalent is.**)
=>3. The value of numerix in matplotlib/__init__.py, in the defaultParams
dictionary, which is presently "Numeric". Only if this is changed to None
will the search continue.
4. If the environment variable NUMERIX is defined as either "Numeric"
or as "numarray", then numerix will import from the specified array package.
5. If the file numerix or .numerix in the HOME directory of the current
user contains a single line specifying either "Numeric" or "numarray",
then the specified array package is imported.
6. If none of the above is done, the default array package is Numeric.
7. If the Numeric is selected and the import fails, numarray is tried.
To summarize: the commandline is examined first, the rc file seconds,
the environment third, the configuration file next, and the default
array package is Numeric. If everything else fails, numarray is tried.
=>In a standard matplotlib installation, however, only the first two
methods--command line and the user's rc file--of specifying the array
package will be effective for the unprivileged user.
"""
Eric

John,
Thanks very much. If you would like me to try the new snapshot, and it 
is ready soon enough, let me know what the email attachment size would 
be, if it would exceed about 100k. There is a limit on email size going 
to the ship, but it can be relaxed if I know in advance that something 
is coming.
I have encountered surprisingly large differences between Numeric and 
numarray:
 pcolor_demo2.py takes about 3 seconds with Numeric, 80 seconds with 
numarray.
In tests of non-plotting operations, I have generally found numarray faster.
The cruise is going fine. Weather was a bit rough off New Zealand but I 
expect it will be fairly smooth from here on. This is a Small 
Waterplane Area Twin Hull (SWATH) ship, so it rides better than most; it 
is a little like a catamaran on stilts, with most of the buoyancy in 
fully submerged pontoons.
Eric
...
>
>When I get everything cleaned up I'll put together some before and
>after numbers from my unit tests.
>
>Hope all is well at sea!
>
>JDH
>
> 
>

>>>>> "Eric" == Eric Firing <ef...@km...> writes:
 Eric> Yes, I saw that, tried putting in explicit gc.collect()
 Eric> calls, but it didn't help. I concluded the problem was
 Eric> different. I also looked at the draw function in
 Eric> backend_gtk.py. What I don't understand is how and when the
 Eric> no-longer-used gtk objects (pixmap, etc) really can and
 Eric> should be de-allocated. Evidently they persist when the
 Eric> python reference to them goes out of scope.
 Eric> Thanks for your changes.
Hi Eric,
You can test the new release which includes both Steve's changes and a
number of fixes on my end. I'll attach the script below that I used
to profile the leak, a modified version of your script. By my
numbers, the average memory consumed per loop is down from 145.9 using
0.54.1 to 12.3 using 0.54.2. Not perfect, but more than 10x better.
I have definitely identified a leak in freetype (as mentioned above,
which is fixed in freetype CVS) and there appears to be a leak in
libpng but I have tracked down precisely where. Neither of these are
terribly large. I strongly suspect that some of the remaining leak is
my doing, so I'll continue to try and sniff these out. The python
code uses a lot of circular references (figures contain axes and text
which in turn contain a reference to the figure that contains them and
so on) which makes the task a little harder.
Let me know how it goes.
JDH
import os, sys, time
import matplotlib
matplotlib.use('Agg')
from matplotlib.matlab import *
def report_memory(i):
 pid = os.getpid()
 a2 = os.popen('ps -p %d -o rss,sz' % pid).readlines()
 print i, ' ', a2[1],
 return int(a2[1].split()[0])
def updatefig(i):
 ind = arange(100)
 xx = rand(len(ind), 1)
 figure(1)
 plot(ind, xx[:,0])
 savefig('dd_ef%d.png' % i, dpi = 75)
 close(1)
 return report_memory(i)
N = 100
for i in range(N):
 val = updatefig(i)
 if i==1: start = val
end = val
print 'Average memory consumed per loop: %1.4f\n' % ((end-start)/float(N))

This is the second bugfix release of the 0.54 series
Here's the CHANGELOG
 * Rewrote ft2font using CXX as part of general memory leak fixes;
 also fixed transform memory leaks
 * Fixed several problems with log ticks and scaling 
 * Fixed width/height issues for images 
 * Fixed draw_if_interactive bug for semilogx; 
 * Fixed text clipping to clip to axes 
 * Fixed leading newline text and multiple newline text 
 * Fixed plot_date to return lines 
 * Fixed plot to work with x or y having shape N,1 or 1,N 
 * Added renderer markeredgewidth attribute of Line2D. 
 * Fixed tick label clipping to work with navigation.
 * Added renderer grouping commands to support groups in
 SVG/PS. 
 * Fixed, this time I really mean it, the singleton plot
 plot([0]) scaling bug; Fixed Flavio's shape = N,1 bug 
 * added colorbar 
 * Made some changes to the matplotlib.colors.Colormap to
 propertly support clim 
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=244568

>>>>> "Eric" == Eric Firing <ef...@km...> writes:
 Eric> John, I am using pygtk2.2, built and installed from the
 Eric> tarball on top of my existing pygtk2.0, which was installed
 Eric> from rpm.
 Eric> The problem does not seem to be inevitable with pygtk
 Eric> plotting; testing I have done so far with pyStripchart 0.0.7
 Eric> (http://jstripchart.sourceforge.net), also with pygtk2.2,
 Eric> has given no indication of a leak. It is a much more
 Eric> specialized (hence simpler) package, though. It draws
 Eric> directly to a DrawingArea instead of using a Pixmap.
Hi Eric, I spent a good bit of time working on the memory leak
problem. It turns out there were numerous problems in both the
transforms module and the ft2font module, which affect all backends.
I've got the former entirely cleared up, and the latter almost done.
I'm writing some unit tests to check for leaks as I go. In the next
day or so I should have a snapshot ready for you to test.
So while there may still be a small problem with pygtk >2.0, I'm not
aware of it. I think the major problems rest squarely on the
shoulders of yours truly.
I wrote the transforms module using CXX, which is a C++ python
extension building library that handles most of the nasty bits for
you, including reference counting. But I was too reliant on it, and
there were some subtleties that I was neglecting involved with
managing reference counts when new pointers are allocated on the heap
and stored in other classes. Fortunately it was a fairly easy fix and
now the transforms are not leaking any detectable memory.
The ft2font module was another matter, since I had written that by
hand. I decided the best way to get this in tip-top shape was to also
rewrite this using CXX, rather than work out all of the intricacies of
reference counting myself. That was a bit more work, but I'm mostly
done. I found one very small leak in the freetype library itself, but
a little searching on the devel list shows that it is fixed in CVS >2.1.8.
But this is only a few bytes per font instance (which are cached and
reused by matplotlib) so this shouldn't present any troubles.
When I get everything cleaned up I'll put together some before and
after numbers from my unit tests.
Hope all is well at sea!
JDH

On Tue, 2004年06月08日 at 21:53, John Hunter wrote:
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> Steve> There does seem to be a memory problem when using Python
> Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
> Steve> resource leak? Why do I run out of memory using Pixbuf?"
> 
> I submitted a patch to fix a pygtk memory leak in get_image that was
> incorporated into pygtk 2.2.
> 
> http://bugzilla.gnome.org/show_bug.cgi?id=133681
> 
> Which version are you using? Do you still see a problem with pygtk
> 2.2 or later?
Thanks for the link. I'm using pygtk from cvs and ran a test for myself
to check that get_image() no longer leaks memory.
I think the FAQ 8.4 reports a memory inefficiency problem, not a memory
leak. It shows a loop where you quickly allocate memory and can use a
large amount of system memory before the Python garbage collector has a
chance to free the unused memory.
Steve

John,
I am using pygtk2.2, built and installed from the tarball on top of my 
existing pygtk2.0, which was installed from rpm.
The problem does not seem to be inevitable with pygtk plotting; testing 
I have done so far with pyStripchart 0.0.7 
(http://jstripchart.sourceforge.net), also with pygtk2.2, has given no 
indication of a leak. It is a much more specialized (hence simpler) 
package, though. It draws directly to a DrawingArea instead of using a 
Pixmap.
Eric
John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
>>>>>> 
>>>>>>
>
> Steve> There does seem to be a memory problem when using Python
> Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
> Steve> resource leak? Why do I run out of memory using Pixbuf?"
>
>I submitted a patch to fix a pygtk memory leak in get_image that was
>incorporated into pygtk 2.2.
>
> http://bugzilla.gnome.org/show_bug.cgi?id=133681
>
>Which version are you using? Do you still see a problem with pygtk
>2.2 or later?
>
>I'll take a look at incorporating your changes, in an case.
>
>But as Kirill pointed out, there is a separate problem with Agg that I
>have to track down.
>
>JDH
>
> 
>

Steve,
>There does seem to be a memory problem when using Python and GTK+. Have
>you seen the pygtk FAQ 8.4 "Is there a resource leak? Why do I run out
>of memory using Pixbuf?"
>
> 
>
Yes, I saw that, tried putting in explicit gc.collect() calls, but it 
didn't help. I concluded the problem was different. I also looked at 
the draw function in backend_gtk.py. What I don't understand is how and 
when the no-longer-used gtk objects (pixmap, etc) really can and should 
be de-allocated. Evidently they persist when the python reference to 
them goes out of scope.
Thanks for your changes.
Eric
>>From looking at matplotlib/backends/backend_gtk.py I noticed every
>FigureCanvasGTK.draw() operation allocates memory for a new pixmap and a
>new graphics context. So looping 200 times in your first test script
>allocates memory for 200 pixmaps and 200 graphics contexts, yet the
>pixmap size has not changed and the graphics context has not changed. I
>think it would be more memory efficient to create a pixmap and continue
>using it until a larger pixmap is required. The graphics context does
>not change its default settings, so it does little, but is required for
>the GDK calls, again it looks to me like it would be better to create
>one and reuse it.
>
>Here are some changes I made to matplotlib/backends/backend_gtk.py I
>estimate saves around 10% of the memory leak.
>However I can't check that it plots correctly properly because I
>currently get a plot of a black rectangle in GTK mode (GTKAgg works OK),
>which I think was mentioned as a numarray problem with the latest
>matplotlib release.
>
>FigureCanvasGTK.__init__(self,figure): # add the following line
> self.pixmap_width, self.pixmap_height = -1, -1 # new
>
> 
>
FigureCanvasGTK.draw(self): # replace with this:
> def draw(self):
> if not self._doplot: return
> drawable = self.window 
> if drawable is None: return
> 
>
> 
> width = int(self.figure.bbox.width())
> height = int(self.figure.bbox.height())
>
> if width > self.pixmap_width or height > self.pixmap_height:
> self._gpixmap = gtk.gdk.Pixmap(drawable, width, height)
> self.pixmap_width = width
> self.pixmap_height = height
>
> self.figure.draw( RendererGTK(self, self._gpixmap,
>self.figure.dpi) )
> drawable.draw_drawable(self._ggc, self._gpixmap, 0, 0, 0, 0,
>width, height)
>
>FigureCanvasGTK.realize(self, widget): # add the following line:
> self._ggc = self.window.new_gc()
>
>Regards
>Steve
>
>
> 
>

I have a few comments which may help to improve the matplotlib functionality:
(1) When the data values are large (or small), the mantissas are rounded off 
 in the scientific notation of the x- or y-tick labels. For example:
>>> plot([1.e9,2.e9,4.e9])
In fact, this is a generally harder problem. In the following contrived and 
unlikely situation, it shows the similar problem:
>>> x=1.
>>> y=1.e-8
>>> plot([x,x+y,x+3*y,x+6*y])
This example has another curious problem. The tick labels are overploted in 
some places and missing in others.
(2) Right now, hist() can only plot filled "bar charts". It will be 
nice if it can also plot not-filled bar charts, bars without gaps in between, 
filled with color of choice, and histogram with only the top bar, without 
the vertical bars, except at the ends.
(3) For asymmetric error bars, the x(y)err's first array is for the "-" and 
the second for the "+". Will it be more intuitive to have that reversed?
(4) When symbols are plotted (e.g. "o" or "x"), the legend shows a bunch (4) 
of them. Will it be better to just plot one?
Thanks,
JC Hsu

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
 Steve> There does seem to be a memory problem when using Python
 Steve> and GTK+. Have you seen the pygtk FAQ 8.4 "Is there a
 Steve> resource leak? Why do I run out of memory using Pixbuf?"
I submitted a patch to fix a pygtk memory leak in get_image that was
incorporated into pygtk 2.2.
 http://bugzilla.gnome.org/show_bug.cgi?id=133681
Which version are you using? Do you still see a problem with pygtk
2.2 or later?
I'll take a look at incorporating your changes, in an case.
But as Kirill pointed out, there is a separate problem with Agg that I
have to track down.
JDH

On Mon, 2004年06月07日 at 22:17, Kirill Lapshin wrote:
> TkAgg -- works fine from console, but if ran from IDLE or PythonWin it 
> creates a window border only, does not populate it with plot. If I try 
> to move the plot window whole python session crashes with generic 
> runtime error message (windows error message box with a single Ok button).
Try running with "idle -n" rather than just "idle" by changing the
properties of a copy of the idle shortcut.
TkAgg is know to work with:
python
idle -n
IPython
TkAgg is know not to work with:
SciTE
pythonw
Pythonwin
idle
Regards,
Todd Miller

There does seem to be a memory problem when using Python and GTK+. Have
you seen the pygtk FAQ 8.4 "Is there a resource leak? Why do I run out
of memory using Pixbuf?"
>From looking at matplotlib/backends/backend_gtk.py I noticed every
FigureCanvasGTK.draw() operation allocates memory for a new pixmap and a
new graphics context. So looping 200 times in your first test script
allocates memory for 200 pixmaps and 200 graphics contexts, yet the
pixmap size has not changed and the graphics context has not changed. I
think it would be more memory efficient to create a pixmap and continue
using it until a larger pixmap is required. The graphics context does
not change its default settings, so it does little, but is required for
the GDK calls, again it looks to me like it would be better to create
one and reuse it.
Here are some changes I made to matplotlib/backends/backend_gtk.py I
estimate saves around 10% of the memory leak.
However I can't check that it plots correctly properly because I
currently get a plot of a black rectangle in GTK mode (GTKAgg works OK),
which I think was mentioned as a numarray problem with the latest
matplotlib release.
FigureCanvasGTK.__init__(self,figure): # add the following line
 self.pixmap_width, self.pixmap_height = -1, -1 # new
FigureCanvasGTK.draw(self): # replace with this:
 def draw(self):
 if not self._doplot: return
 drawable = self.window 
 if drawable is None: return
 
 width = int(self.figure.bbox.width())
 height = int(self.figure.bbox.height())
 if width > self.pixmap_width or height > self.pixmap_height:
 self._gpixmap = gtk.gdk.Pixmap(drawable, width, height)
 self.pixmap_width = width
 self.pixmap_height = height
 self.figure.draw( RendererGTK(self, self._gpixmap,
self.figure.dpi) )
 drawable.draw_drawable(self._ggc, self._gpixmap, 0, 0, 0, 0,
width, height)
FigureCanvasGTK.realize(self, widget): # add the following line:
 self._ggc = self.window.new_gc()
Regards
Steve

Barry Drake wrote:
>I've recently returned to Matplotlib and Scipy (and
>happy to be back!!!). I had the same problem and
>solved it by putting the lines
>
>import matplotlib
>matplotlib.use('WXAgg')
>
>before the usual import
>
>from matplotlib.matlab import *
> 
>
Barry, thanks a lot for your input, however I did try WXAgg, as well as 
WX and TkAgg and none of them works for me. One thing I forgot to 
mention in my previous e-mail though. I am using interactive mode. I 
just tried the same experiment in non-interactive mode, and WX works 
fine. However we are mostly interested in interactive mode, because we 
mostly use plotting for debugging purposes.
--Kirill

Kirill,
I've recently returned to Matplotlib and Scipy (and
happy to be back!!!). I had the same problem and
solved it by putting the lines
import matplotlib
matplotlib.use('WXAgg')
before the usual import
from matplotlib.matlab import *
This worked for all of the example code.
If you don't have the examples, which are not included
in the Windows installer, go back to the download page
again and grab the .zip file. This includes numerous
examples that you should be able to run with the two
lines mentioned above.
Hope this helps.
Barry Drake
--- Kirill Lapshin wrote:
> Hello,
> 
> I am a newbie to Matplotlib and all Python
numeric
> stuff, so sorry if it 
> is a FAQ.
> 
> I've installed NumPy 23.1, SciPy 0.3 and
Matplotlib
> 54.1. Python is 
> 2.3.4. The problem I have is that none of
backends
> works properly.
> 
> TkAgg -- works fine from console, but if ran from
> IDLE or PythonWin it 
> creates a window border only, does not populate
it
> with plot. If I try 
> to move the plot window whole python session
crashes
> with generic 
> runtime error message (windows error message box
> with a single Ok button).
> 
> WX/WXAgg -- both don't work from console -- show
> empty window, cursor 
> turns in hourglass when it is over plot window.
From
> GUI app 
> (IDLE/PythonWin) it seems to work at first glance
--
> plot gets created, 
> but the plot window can not be closed with either
> Alt-F4 or mouse. It 
> just does not react on close command. Moreover,
> python objects 
> corresponding to window seems to get destroyed
when
> I try to close 
> window, because if I do few plots commands
without
> trying to close the 
> window, new plots appear in first window, however
as
> soon as I try to 
> close the window (it won't close, remember?), new
> plots will open new 
> window. That second window can be closed, but
first
> one still remain 
> unclosable.
> 
> GTK/GTKAgg -- can't really try that one, because
it
> requires compiling 
> GTK, and we don't have compiler yet.
> 
> 
> Any ideas how that can be fixed, work arounded,
> debugged? I am pretty 
> comfortable with debugging Python code, but as I
> said I don't have C 
> compiler yet, so can't debug extensions.
> 
> This behavior observed on brand new computer with
> freshly installed Win 
> XP. The same behavior I am observing on my a bit
old
> Win XP laptop.
> 
> --Kirill
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: GNOME
Foundation
> Hackers Unite! GUADEC: The world's #1 Open
Source
> Desktop Event.
> GNOME Users and Developers European Conference,
> 28-30th June in Norway
> http://2004/guadec.org
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
>
https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello,
I am a newbie to Matplotlib and all Python numeric stuff, so sorry if it 
is a FAQ.
I've installed NumPy 23.1, SciPy 0.3 and Matplotlib 54.1. Python is 
2.3.4. The problem I have is that none of backends works properly.
TkAgg -- works fine from console, but if ran from IDLE or PythonWin it 
creates a window border only, does not populate it with plot. If I try 
to move the plot window whole python session crashes with generic 
runtime error message (windows error message box with a single Ok button).
WX/WXAgg -- both don't work from console -- show empty window, cursor 
turns in hourglass when it is over plot window. From GUI app 
(IDLE/PythonWin) it seems to work at first glance -- plot gets created, 
but the plot window can not be closed with either Alt-F4 or mouse. It 
just does not react on close command. Moreover, python objects 
corresponding to window seems to get destroyed when I try to close 
window, because if I do few plots commands without trying to close the 
window, new plots appear in first window, however as soon as I try to 
close the window (it won't close, remember?), new plots will open new 
window. That second window can be closed, but first one still remain 
unclosable.
GTK/GTKAgg -- can't really try that one, because it requires compiling 
GTK, and we don't have compiler yet.
Any ideas how that can be fixed, work arounded, debugged? I am pretty 
comfortable with debugging Python code, but as I said I don't have C 
compiler yet, so can't debug extensions.
This behavior observed on brand new computer with freshly installed Win 
XP. The same behavior I am observing on my a bit old Win XP laptop.
--Kirill

John,
I would like to use matplotlib in data acquisition and processing 
software for a shipboard acoustic Doppler current profiler (ADCP), and I 
am presently at sea on the University of Hawaii Research Vessel Kilo 
Moana (25S, 175W). Until June 17 or 18, when I arrive in Honolulu, I 
will not have access to the mailing list via my normal email address, 
ef...@ha..., but mail sent to me on the ship, 
ef...@km..., will be transferred about 3 times per day.
I am working with a Linux machine, Mandrake 10.0, 2.6 kernel, pygtk 
2.2. I suspect that the memory-monitoring parts of the scripts I have 
attached are Linux-specific.
The attached scripts illustrate what seem to be pervasive memory leaks 
when doing repeated plots, using GTK or GTKAgg to plot to the screen, or 
using Agg to make png files only. I have tried several variations--all 
result in fairly steady increase in memory consumption. 
Memory usage increase can also be seen by running the pcolor_demo.py, 
and repeatedly raising and lowering the window, thereby forcing redraws.
Do you expect that such leakage is inevitable with matplotlib? I hope 
not; matplotlib is by far the most promising plotting package I have 
found as a prospective Matlab replacement.
On another topic: I believe I saw in earlier mailing list correspondence 
a request for transparent plotting of data with NaNs in it--that is, a 
NaN in a line should cause the line to be broken and a symbol omitted, 
in pcolor should cause simply an empty (white, black, or transparent) 
cell, etc., as in Matlab. I would like to second this request. In 
physical oceanography, bad or missing measurements are ubiquitous, and 
Matlab's treatment of NaNs enormously reduces the pain of dealing with 
such glitches. Ideally, this sort of thing would be done equivalently 
with NaNs in a numarray or with the mask in a masked array, so that one 
could use either approach.
Thanks for the excellent work you have already done.
Eric Firing
ef...@km... until June 17
ef...@ha... thereafter

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:
 Jin-chung> Hi: I encounter the following problems, most are
 Jin-chung> related to log plots. I am using version 0.54.1 on
 Jin-chung> Solaris. Did I miss something trivial?
Hi Jin-chung,
I think I have all these problems sorted out now. If you would like
to test them, the latest snapshot is here
http://nitace.bsd.uchicago.edu:8080/files/share/matplotlib-0.54.2b.tar.gz
Thanks for the detailed examples!
JDH

>>>>> "Mark" == Mark Engelhardt <ma...@st...> writes:
 Mark> For me, the plot generated by x2 (the second call of show)
 Mark> is dense in the middle and fades out at the edges. I assume
 Mark> this is somehow due to the line redrawing over itself as it
 Mark> moves from point to point.
 Mark> Is there a good way to clean it up, other than always
 Mark> sorting the x variable list?
Hi Mark,
The problem arises from a combination of when in the rendering
pipeline matplotlib does the transformation from data to display
coordinates, and how agg handles antialiasing with subpixel rendering.
The short answer is that matplotlib handles the transformation in the
front end and then passes the backend display coords to render. This
doesn't play nicely with agg, which does different things depending on
the fractional value of the display coordinate (aka subpixel
rendering). It's something I would like to change, but it is a fairly
substantial piece of work so I'm holding off on it for now. Drawing
with
 plot(x, y, antialiased=False)
will improve the situation, but then you won't have anitaliasing, and
it still won't be perfect.
I posted a variant of your question to the antigrain mailing list (see
below) in hopes of understanding this issue better myself, and Maxim,
the antigrain author, was kind enough to write this web page in reply
 http://antigrain.com/tips/line_alignment/line_alignment.agdoc.html
He also pointed out that SVG has the same behavior. The best
solution, as noted above, is to render in the following order
 set the path
 apply the affine transformation
 rasterize
whereas I am doing
 apply the affine transformation
 set the path
 rasterize
and there is no way to change this w/o significant changes to al lthe
drawing functions in all the backends.
Note that the following simpler example exposes the problem
 from matplotlib.matlab import *
 x = array([2,5,3,1,4])
 plot(x, x)
 show()
If I come up with something better I'll let you know; even after
reading Maxim's webpage I'm still confused on a couple of issues so
I'll follow-up. Note that this is a problem specific to the agg
backend, so if you need to produce something for distribution and want
to avoid this problem, you might be able to use another backend.
I'll include my post to the antigrain list below, where I have
translated your example into display coords, ie, what agg sees.
JDH
From: John Hunter <jdh...@ac...>
Subject: [AGG] line paths, subpixel, and aa
To: Vec...@li...
Date: 2004年6月04日 15:39:44 -0500
Reply-To: vec...@li...
I develop a plotting library (matplotlib) that has an antigrain
backend. The library is setup to do the transformations on the front
end and pass the backends drawing commands in display coordinates.
The library was designed before I started using antigrain as a
backend, and one unfortunate side-effect of this is that the backend
often gets coordinates with a variety of fractional values, eg 100.0,
100.25, 100.5. The front end does not understand agg's subpixel
rendering. 
So occasionally we get "strange" results like uneven thickness of
lines. I have a few hacks to deal with this in common use cases, but
it still is a lingering problem. 
Here is one particularly strange (to me) manifestation. I don't fully
understand how agg handles line widths with antialiasing and subpixel
locations, so I'm hoping to use this example to enlighten me.
If a path is drawn as (canvas is 640x480 - all these points more or
less fall on the same line)
 path.move_to(204, 332.4);
 path.line_to(576, 48);
 path.line_to(328, 237.6);
 path.line_to(80, 427.2);
 path.line_to(452, 142.8);
There is a strong effect of line width. For example, the line at (80,
427.2) is extremely (vanishingly) thin, but thick in the middle at
328, 237.6. raw rgba pixel dump is at
http://nitace.bsd.uchicago.edu:8080/files/share/line_aa.raw.
If the order the line is drawn is changed to (points ordered by
increasing x,y)
 path.move_to(80, 427.2);
 path.line_to(204, 332.4);
 path.line_to(328, 237.6);
 path.line_to(452, 142.8);
 path.line_to(576, 48);
The line width is more or less uniform.
Can someone enlighten me here? (Complete example below).
On another note, does anyone have advice on how to solve these kinds
of problems in general. Another example is in drawing of horizontal
or vertical tick lines for graphs. The tick locations are in data
coordinates and the front end transforms these into display coords as
above. Depending on the data location, these might end up having any
fractional display value, and thus the thickness of these rendered
lines varies. My solution for this case is to detect at the backend
(agg) whether the line is horizontal or vertical and "snap-to" the
nearest integer + 0.5 location. This works OK for horiz and vertical
lines.
But for arbitrary line paths, eg, sine waves, snapping all points to
the same fractional value introduces other kinds of visual problems,
so I don't do this - but then I get the kinds of problems in the
example above.
General question: if the transformations were handled in agg, eg the
frontend passed data coords and I set the transformation matrices in
agg accordingly, would I still face these problems?
Sorry for the somewhat vague and meanering post - hopefully someone
can understand my problem and enlighten me!
John Hunter
#include <fstream>
#include "agg_path_storage.h"
#include "agg_pixfmt_rgb24.h"
#include "agg_pixfmt_rgba32.h"
#include "agg_rasterizer_scanline_aa.h"
#include "agg_renderer_scanline.h"
#include "agg_rendering_buffer.h"
#include "agg_scanline_bin.h"
#include "agg_scanline_p32.h"
#include "agg_conv_stroke.h"
typedef agg::pixel_formats_rgba32<agg::order_rgba32> pixfmt;
typedef agg::renderer_base<pixfmt> renderer_base;
typedef agg::rasterizer_scanline_aa<> rasterizer;
// antialiased
typedef agg::renderer_scanline_p_solid<renderer_base> renderer;
typedef agg::scanline_p8 scanline;
// aliased
//typedef agg::scanline_bin scanline;
//typedef agg::renderer_scanline_bin_solid<renderer_base> renderer;
int main(int argc, char* argv[]) {
 unsigned width(640), height(480);
 unsigned stride(width*4);
 size_t NUMBYTES(width*height*4);
 agg::int8u buffer[NUMBYTES];
 agg::rendering_buffer rbuf;
 rbuf.attach(buffer, width, height, stride);
 //draw_anti_aliased
 pixfmt pixf(rbuf);
 renderer_base rb(pixf);
 renderer ren(rb);
 rasterizer ras;
 scanline sline;
 agg::path_storage path;
 rb.clear(agg::rgba(1.0, 1.0, 1.0, 1.0));
 path.move_to(204, 332.4);
 path.line_to(576, 48);
 path.line_to(328, 237.6);
 path.line_to(80, 427.2);
 path.line_to(452, 142.8);
 /*
 path.move_to(80, 427.2);
 path.line_to(204, 332.4);
 path.line_to(328, 237.6);
 path.line_to(452, 142.8);
 path.line_to(576, 48);
 */
 agg::conv_stroke<agg::path_storage> stroke(path);
 stroke.width( 1);
 ras.add_path(stroke);
 ren.color(agg::rgba(0.0, 0.0, 0.0, 1.0));
 ras.render(sline, ren);
 size_t i;
 std::ofstream of2( "line_aa.raw", std::ios::binary|std::ios::out);
 for (i=0; i<NUMBYTES; ++i)
 of2.write((char*)&buffer[i], sizeof(char));
 
}

>>>>> "Jin-chung" == Jin-chung Hsu <hs...@st...> writes:
 Jin-chung> Hi: I encounter the following problems, most are
 Jin-chung> related to log plots. I am using version 0.54.1 on
 Jin-chung> Solaris. Did I miss something trivial?
No, all your bugs are valid. Several of them are trivial fixes. One
of them (the 0.3 tick problem) is subtle and important. I'm still
trying to figure it out.
I'll keep you posted.
Thanks for the examples,
JDH

Hi,
I've noticed that the line density seems to vary if the x-values in a 
2D plot are not ordered and the x,y pairs fall on the same line.
For example, compare these 2 plots:
def f(x):
	return x+1
x1 = arange(5)
x2 = array([2,5,3,1,4])
plot(x1, f(x1))
show()
plot(x2, f(x2))
show()
For me, the plot generated by x2 (the second call of show) is dense in 
the middle and fades out at the edges. I assume this is somehow due to 
the line redrawing over itself as it moves from point to point.
Is there a good way to clean it up, other than always sorting the x 
variable list?
Thanks,
Mark

>>>>> "Nils" == Nils Wagner <nw...@me...> writes:
 Nils> Dear experts, I am interested in a plot of equipotential
 Nils> curves. If desired, the regions between contours should be
 Nils> shaded or colored to indicate their magnitude.
 Nils> Is this feature already available in matplotlib ? A small
 Nils> example will be appreciated.
There is no contour per se, but you can use imshow or pcolor with a
custom colormap that has only few levels to emulate one, as shown in
this screenshot and example below
 http://nitace.bsd.uchicago.edu:8080/files/share/poormans_contour.png
We are interested in developing a real contour function however, which
also provides contour lines, etc, as mentioned on
http://matplotlib.sourceforge.net/goals.html.
Cheers,
John Hunter
#!/usr/bin/env python
from matplotlib.matlab import *
def bivariate_normal(X, Y, sigmax=1.0, sigmay=1.0,
 mux=0.0, muy=0.0, sigmaxy=0.0):
 """
 Bivariate gaussan distribution for equal shape X, Y
 http://mathworld.wolfram.com/BivariateNormalDistribution.html
 """
 Xmu = X-mux
 Ymu = Y-muy
 rho = sigmaxy/(sigmax*sigmay)
 z = Xmu**2/sigmax**2 + Ymu**2/sigmay - 2*rho*Xmu*Ymu/(sigmax*sigmay)
 return 1.0/(2*pi*sigmax*sigmay*(1-rho**2)) * exp( -z/(2*(1-rho**2)))
delta = 0.01
x = arange(-3.0, 3.0, delta)
y = arange(-3.0, 3.0, delta)
X,Y = meshgrid(x, y)
Z1 = bivariate_normal(X, Y, 1.0, 1.0, 0.0, 0.0)
Z2 = bivariate_normal(X, Y, 1.5, 0.5, 1, 1)
# difference of Gaussians
cmap = ColormapJet(10) # only 10 levels for discrete color steps
im = imshow(Z2-Z1, cmap)
# set the interpolation method: 'nearest', 'bilinear', 'bicubic' and much more
im.set_interpolation('bilinear')
axis('off')
#savefig('test')
show()

Dear experts,
I am interested in a plot of equipotential curves.
If desired, the regions between contours should be shaded or colored to
indicate their magnitude.
Is this feature already available in matplotlib ?
A small example will be appreciated.
Thanks in advance.
Nils