matplotlib-users Mailing List for matplotlib

Chris,
Both with respect to documentation and functionality, what you are 
encountering is the historical aspect of masked arrays as a tacked-on 
part of python numeric packages, and of matplotlib. Support and 
integration are improving, but still far from perfect. A largely new, 
and substantially different, implementation of masked arrays has been 
transplanted into numpy since the last release. Similarly, mpl got a 
heart transplant since the last release, and it has some implications 
for the way nans and masked arrays are handled. There is lots more room 
for fundamental work on both numpy masked arrays (e.g., moving core code 
to pyrex/cython or C to speed them up) and on mpl.
Now with respect to your particular case here, trying to plot a filled 
line with gaps: poly_between has no notion of masked arrays at present. 
 If it did, how should it behave? At the very least, additional 
arguments are needed to specify what should happen for fill-type 
plotting with missing values. If we can come up with a clear 
description of the behaviors that should be available, then maybe we can 
provide them in mpl. I would be happy to fix this gap in mpl's handling 
of gappy data, but I can't make it a priority use of my time right now.
For a quick fix, it sounds like what you need is either a function to 
break up your data set into gapless chunks, each of which could be 
plotted by a call to fill, or a function (a variant of poly_between) 
that would replace the gap regions with top and bottom lines at the same 
place (the bottom level? the x-axis?) so the whole thing could be 
plotted in one call to fill, provided the patch outline is suppressed.
I seem to recall someone else with a similar need in the past few 
months, so maybe someone on the list has a ready-made solution for you.
Eric
Chris Withers wrote:
> Eric Firing wrote:
>> This is not doing what you think it is,
> 
> Indeed, I guess I was seeing nans being treated as missing values rather 
> than being masked...
> 
>> You should use numpy.masked_where(numpy.isnan(aa), aa).
> 
> I am now ;-)
> 
> However, I'm still running into problems when I try and plot the gappy 
> data on a filled line as follows:
> 
> dates = *an array of datetimes*
> values = *an array containing data values and a few nans*
> values = numpy.ma.masked_where(numpy.isnan(values),values)
> xs,ys = mlab.poly_between(dates,0,values)
> pylab.fill(xs,ys,'r')
> 
> For starters, I get this warning:
> 
> numpy\core\ma.py:609: UserWarning: Cannot automatically convert masked 
> array to numeric because data is masked in one or more locations.
> 
> ...and wherever a NaN occurs in the data, the line is plotted off the 
> top of the axes. I want it to appear at 0 if there's no data. Well, 
> ideally just not appear at all, but I'd settle for appearing at 0...
> 
> Any ideas?
> 
> cheers,
> 
> Chris
> 

import numpy as np
a = ['','','',1.1,2.2]
mask_a = [i == '' for i in a]
b = np.ma.MaskedArray(a, mask=mask_a)
Chris Withers wrote:
> Eric Firing wrote:
> 
>> Chris,
>>
>> Use masked arrays. See masked_demo.py in the mpl examples subdirectory.
>> 
>
> Hi Eric,
>
> I took a look at that, but it uses:
>
> import matplotlib.numerix.npyma as ma
>
> ...and matplotlib.numerix isn't listed in the API reference. Where are 
> the docs for this?
>
> Specifically, what I have is an array like so:
>
> ['','','',1.1,2.2]
>
> I want to mask the strings out so I don't get ValueErrors raised when I 
> call plot functions with that array.
>
> How should I do that?
>
> cheers,
>
> Chris
>
> 
-- 
gi...@gi...
http://www.cafelamarck.it

Hi All,
Zachary Pincus wrote:
>> Can you tell me where you specified the -Os option to gcc to escape 
>> the problem?
> 
> So the compile that command that failed is printed right above the 
> error message it generated. (The long line that starts with 
> 'gcc' ...). I just copied this command, edited the -O3 to an -Os, and 
> pasted that command-line back into the terminal. Total low-tech hack, 
> as I didn't want to much with the setup.py file to fix compile flags 
> on a per-file basis.
> 
> After that file is compiled manually, you can re-run 'python setup.py 
> build', and it will start up at the next step after the error.
> 
> I got the same error in another step, which was a bit trickier to fix, 
> because for some reason, src/_image.cpp gets copied to src/image.cpp 
> on a temporary basis, and then compiled. (I presume the file isn't 
> also modified?) But after the compile errors out, the copy is deleted, 
> so just pasting in the offending gcc command doesn't work. So I had to 
> manually copy src/_image.cpp to scr/image.cpp, and then paste in the 
> modified gcc command.
> 
> Ugh! I'd really love some help reducing this to a test case that I can 
> send to Apple.
I've got the same error(s) in the same situation (10.5.2). I haven't 
seen it any other context nor have had any success in reducing to a test 
case, alas. Could this have to do with picking up libraries (from fink 
or elsewhere) and/or different compiler versions? I've got XCode 3 and 
gcc 4.0. (I've actually got the apple 4.2 preview release as well but 
that craps out even earlier, I assume due to library version mismatches...)
Andrew
> 
> Zach
> 
> 
> On Mar 13, 2008, at 12:16 PM, Stephane Raynaud wrote:
> 
>> Hi,
>>
>> I got the same problem.
>> Can you tell me where you specified the -Os option to gcc to escape 
>> the problem?
>>
>>
>> On Mon, Mar 10, 2008 at 4:35 AM, Zachary Pincus <zac...@pu... 
>>> wrote:
>>> Hello,
>>>
>>> I just tried to compile the SVN head of matplotlib (r4994) from 
>>> source
>>> on OS X 10.5.2 (with source builds of python 2.5.2 and the SVN head 
>>> of
>>> numpy), and ran into an "internal compiler error" in the agg code.
>>> (pkgconfig 0.23 and wxPython 2.8.7.1 also present and accounted for.)
>>>
>>> Here's the compile line and error:
>>>> building 'matplotlib.backends._backend_agg' extension
>>>> gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno- 
>>>> fused-
>>>> madd -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-
>>>> prototypes -I/Library/Frameworks/Python.framework/Versions/2.5/lib/
>>>> python2.5/site-packages/numpy/core/include -I/usr/X11/include/
>>>> libpng12 -I/usr/local/include -I/usr/include -I/usr/X11R6/include -
>>>> I. -I/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
>>>> python2.5/
>>>> site-packages/numpy/core/include -Isrc -Iagg24/include -I. -I/usr/
>>>> X11/include/freetype2 -I/usr/X11/include -I/usr/local/include -I/ 
>>>> usr/
>>>> include -I/usr/X11R6/include -I. -I/Library/Frameworks/
>>>> Python.framework/Versions/2.5/include/python2.5 -c src/_image.cpp -o
>>>> build/temp.macosx-10.4-i386-2.5/src/_image.o
>>>> cc1plus: warning: command line option "-Wstrict-prototypes" is valid
>>>> for C/ObjC but not for C++
>>>> src/_image.cpp: In member function 'Py::Object
>>>> _image_module::from_images(const Py::Tuple&)':
>>>> src/_image.cpp:842: error: insn does not satisfy its constraints:
>>>> (insn 2573 1070 2574 126 agg24/include/agg_color_rgba.h:268 (set
>>>> (mem:QI (plus:SI (reg/f:SI 6 bp)
>>>> (const_int -280 [0xfffffffffffffee8])) [0 SR.2969+0
>>>> S1 A8])
>>>> (reg:QI 5 di)) 56 {*movqi_1} (nil)
>>>> (nil))
>>>> src/_image.cpp:842: internal compiler error: in
>>>> reload_cse_simplify_operands, at postreload.c:391
>>>> Please submit a full bug report, with preprocessed source if
>>>> appropriate.
>>>> See <URL:http://developer.apple.com/bugreporter> for instructions.
>>> This seems to be an agg and OS X error; it's cropped up here:
>>> http://trac.osgeo.org/mapserver/ticket/2368
>>> and John Hunter reported it on the agg list here:
>>> http://article.gmane.org/gmane.comp.graphics.agg/3963
>>>
>>> Unfortunately, the error appears to either not have been fixed by the
>>> 10.5.1 update, as suggested in the email thread cited above, or the
>>> error re-appeared in 10.5.2.

All,
 Alright I've made some progress here improving upon the example. 
(Codes at the bottom). So it looks like I've started a writing a 
wrapper class around the plot command that continuously updates it's 
data by itself without having to write extra code. To me, using the 
subplot commands like set_xdata and set_ydata, should automatically 
update the graph, as I really don't like dealing with that myself. So 
what's happening below is that I'm starting two threads along with the 
Tkinter user thread. The first thread watches for changes in the data 
and the second actually induces changes forever. I know that the way 
I'm doing all this is a) quick and dirty b) really bad c) un-pythonic 
and d) it closes off all the current methods to plot etc, which if I 
need to continue developing this, I'll open them up as well the best I 
can.
So that brings me to my next question. Is all this necessary? Is there 
a simpler way to make auto-updating graphs without all of the lines of 
"outside" code?
One last question, if anyone runs this, you'll notice that the graph 
stops updating whenever you use the menu, or move the tkinter window, 
does anyone have a clue to why this is?
Thank you to everyone for your time.
Regards,
Kenneth Miller
~~~~~~~~~~~START CODE~~~~~~~~~~~~
import sys
import pylab as p
import numpy as npy
import time
import Tkinter as Tk
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg, 
NavigationToolbar2TkAgg
import threading
class SimplePlot:
 def __init__(self,root):
 f = matplotlib.figure.Figure(figsize=(5,4),dpi=100)
 self.ax = f.add_subplot(111)
 self.canvas = self.ax.figure.canvas
 # create the initial line
 canvas = FigureCanvasTkAgg(f, master=root)
 canvas.show()
 canvas.get_tk_widget().pack(side=Tk.TOP, fill=Tk.BOTH, expand=1)
 self.canvas = canvas
 toolbar = NavigationToolbar2TkAgg( canvas, root )
 toolbar.update()
 canvas._tkcanvas.pack(side=Tk.TOP, fill=Tk.BOTH, expand=1)
 manager = p.get_current_fig_manager()
 manager.window.after(100, self.run)
 def plot(self,x,y):
 line, = p.plot(x,y,animated=True,lw=2)
 self.x = x
 self.y = y
 self.line = line
 def run(self,*args):
 class MyThread(threading.Thread):
 def __init__(self,simplePlot):
 self.simplePlot = simplePlot
 print dir(self)
 threading.Thread.__init__(self)
 def run(self):
 background = 
self.simplePlot.canvas.copy_from_bbox(self.simplePlot.ax.bbox)
 # for profiling
 tstart = time.time()
 self.cnt = 0
 while 1:
 # restore the clean slate background
 self.simplePlot.canvas.restore_region(background)
 # update the data
 self.simplePlot.line.set_ydata(self.simplePlot.y)
 # just draw the animated artist
 self.simplePlot.ax.draw_artist(self.simplePlot.line)
 # just redraw the axes rectangle
 self.simplePlot.canvas.blit(self.simplePlot.ax.bbox)
 if self.cnt==100:
 # print the timing info and quit
 print 'FPS:' , 100/(time.time()-tstart)
 self.cnt=0
 tstart = time.time()
 self.cnt += 1
 mt = MyThread(self)
 mt.start()
class DataThread(threading.Thread):
 def run(self):
 import time
 i = 0.0
 while 1:
 s.x = x
 s.y = npy.sin(x+i/10.0)
 time.sleep(0.01)
 i += 1.0
root = Tk.Tk()
root.wm_title("Embedding")
s = SimplePlot(root)
#some data points
x = npy.arange(0,2*npy.pi,0.01)
y = npy.sin(x)
s.plot(x,y)
dt = DataThread()
dt.start()
Tk.mainloop()
dt.join()
~~~~~~~~~~~~~~~~~~end code~~~~~~~~~~~~~~~~~~~~~
On Mar 14, 2008, at 12:46 PM, Kenneth Miller wrote:
> All,
>
> I've seen the examples for embedding matplot lib in Tk and the 
> Tk animation example. However I've not yet been successful with 
> creating an example where i can both animate data and stay in 
> control of Tk. (The animation in tk example seems to lock the 
> mainloop.) Does anyone have any advice or a quick example of a Tk 
> app with an animated graph that doesn't lock the user out of Tk 
> control?
>
> Regards,
> Kenneth Miller

I don't see the character in the plot you sent. So at least that's 
consistent. ;)
However, I still can't get things to break locally (on Linux, at least), 
with all permutations of ps.fonttype, ps.useafm, ps.distiller, and 
mathtext.fontset.
Can you send your entire matplotlibrc file? Perhaps there is some other 
obscure setting that's interacting in a negative way.
Mike
Mark Bakker wrote:
> Sorry, John, but here is my output, and it still doesn't work.
>
> >>> from pylab import *
> >>> rcParams['mathtext.fontset']
> 'cm'
> >>> rcParams['mathtext.fallback_to_cm']
> True
> >>> rcParams['ps.useafm']
> False
> >>> rcParams['ps.fonttype']
> 3
> >>> plot([1,2,3])
> [<matplotlib.lines.Line2D instance at 0x029F0120>]
> >>> text(1,1.5,r'$\chi$')
> <matplotlib.text.Text instance at 0x029F6968>
> >>> savefig('c:/temp/test.eps')
>
> On the same machine, I get the correct eps file with 0.90.1.
> So it really isn't my installation of GsView.
>
> In the eps file created with 0.91.2, the cm fonts are not included, 
> which I think is causing the problem.
>
> What happens when you guys read the attached eps file (created with 
> commands above)?
> Do you see the chi symbol on the screen?
>
> Thanks for looking into this,
>
> Mark
>
>
> On Wed, Mar 19, 2008 at 2:18 PM, John Hunter <jd...@gm... 
> <mailto:jd...@gm...>> wrote:
>
> On Wed, Mar 19, 2008 at 7:43 AM, Mark Bakker <ma...@gm...
> <mailto:ma...@gm...>> wrote:
> > I have confirmed that it is a bug in (at least the windows
> version) of mpl
> > 0.91.2.
> > When saving eps files, and using mathtext, the cm fonts don't
> get saved, and
> > the
> > greek symbols (and others I presume) don't show up in the eps file.
> >
> > This works in mpl 0.90.1, where the eps file does store the fonts.
> > %%BeginFont: Cmmi10
> >
> > When running the same problem with 0.91.2, the fonts are not stored.
> > Either using ps.fonttype 3 or 42.
> >
> > Anybody who can fix this?
>
> My guess is that you are picking up an rc file where useafm is set to
> True. Michael suggested checking this rc setting but I did not see
> any response on this on list. Have you checked it? In the script
> that is causing you trouble, print out the value
>
> import matplotlib
>
> print 'afm setting', matplotlib.rcParams['ps.useafm']
>
> If this is True, then you need to find your matplotlibrc file and set
> it to False.
>
> I can't imagine a windows vs other platform issue that could cause
> this since we do not use only matplotlib tools in our font conversion
> pipeline
>
> JDH
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Wed, Mar 19, 2008 at 7:43 AM, Mark Bakker <ma...@gm...> wrote:
> I have confirmed that it is a bug in (at least the windows version) of mpl
> 0.91.2.
> When saving eps files, and using mathtext, the cm fonts don't get saved, and
> the
> greek symbols (and others I presume) don't show up in the eps file.
>
> This works in mpl 0.90.1, where the eps file does store the fonts.
> %%BeginFont: Cmmi10
>
> When running the same problem with 0.91.2, the fonts are not stored.
> Either using ps.fonttype 3 or 42.
>
> Anybody who can fix this?
My guess is that you are picking up an rc file where useafm is set to
True. Michael suggested checking this rc setting but I did not see
any response on this on list. Have you checked it? In the script
that is causing you trouble, print out the value
import matplotlib
print 'afm setting', matplotlib.rcParams['ps.useafm']
If this is True, then you need to find your matplotlibrc file and set
it to False.
I can't imagine a windows vs other platform issue that could cause
this since we do not use only matplotlib tools in our font conversion
pipeline
JDH

On Wed, Mar 19, 2008 at 4:40 AM, Chris Withers <ch...@si...> wrote:
> That's a shame :-(
> So, no gradient filled patches in MPL?
It's on the wish-list. You can hack a solution using matplotlib
images: http://matplotlib.sf.net/examples/gradient_bar.py .. The
postscript backend has support for hatches see the set_hatch method
for http://matplotlib.sourceforge.net/matplotlib.patches.html#Patch
but this hasn't been ported to any other backend AFAIK.

Unfortunately, I'm still unable to reproduce the problem myself. Have 
you tried installing the CM fonts (copying them to C:\Windows\Fonts)? 
Maybe GS is trying to re-embed them and can't find them.
Cheers,
Mike
Mark Bakker wrote:
> I have confirmed that it is a bug in (at least the windows version) of 
> mpl 0.91.2.
> When saving eps files, and using mathtext, the cm fonts don't get 
> saved, and the
> greek symbols (and others I presume) don't show up in the eps file.
>
> This works in mpl 0.90.1, where the eps file does store the fonts.
> %%BeginFont: Cmmi10
>
> When running the same problem with 0.91.2, the fonts are not stored.
> Either using ps.fonttype 3 or 42.
>
> Anybody who can fix this?
>
> Thanks, Mark
>
> On Wed, Mar 19, 2008 at 11:21 AM, Bernhard Voigt 
> <Ber...@de... <mailto:Ber...@de...>> wrote:
>
> Hi Mark!
>
> The problem seems to be that the computer modern font (cm) is not
> included in the eps file. The snipped of the eps file I sent before
> defines the font cmmi10:
>
> %!PS-Adobe-3.0 Resource-Font
> %%Title: cmmi10
> %%Copyright: Copyright (C) 1994, Basil K. Malyshev. All Rights
> Reserved.012BaKoMa Fonts Colle
> ction, Level-B.
> %%Creator: Converted from TrueType by PPR
> .....
> /FontName /Cmmi10 def
>
> And later, when the \chi glyph should be drawn, the font is
> changed to:
> /Cmmi10 findfont
> 16.0 scalefont
> setfont
> 0.000000 4.921875 moveto
> /chi glyphshow
>
> Which is the same in your file, but your file only contains the
> Bitstreem Vera Sans font for the axis ticks. Cmmi10 is missing :-(
>
> Your pdf, however, does contain the cmmi10 font, you can check via
> file->properties->fonts.
>
> You should have the following in your matplotlibrc file (well, you
> said you have it, but let me repeat):
> mathtext.fontset : cm
> mathtext.fallback_to_cm : True
> ps.useafm : False
> ps.fonttype : 3
>
> Check the settings using the interpreter prompt:
>
> In [10]: p.rcParams['mathtext.fontset']
> Out[10]: 'cm'
> etc...
>
> Well, if they are all correctly set, it's probably a bug in the ps
> backend not including the mathtext font.
>
> A workaround would be to convert the pdf file to ps (either use
> command line options of acroread or print to file), edit the ps file
> to be a eps by changing the header to %!PS-Adobe-2.0 EPSF-2.0 and make
> sure the bounding box is specified (see
> http://www.postscript.org/FAQs/language/node82.html for details)
>
> Bernhard
>
>
> On Wed, Mar 19, 2008 at 10:22 AM, Mark Bakker <ma...@gm...
> <mailto:ma...@gm...>> wrote:
> > Hello Mike -
> >
> > Thanks for taking a look at this.
> > Easy example:
> >
> > from pylab import *
> > plot([1,2,3])
> > text(1,1.5,r'$\chi$')
> > savefig('d:/temp/test.eps')
> >
> > There shoud now be a line and the symbol chi.
> > Works great in the pdf file, not in the eps file.
> > Both are attached.
> >
> > Strangely enough at the end of the eps file there are statements:
> >
> > 0.000000 3.703125 moveto
> > /chi glyphshow
> >
> > Which looks to me like writing chi.
> > I have now tried this on 4 windows machines, with different
> installations of gsview, but it doesn't work on any.
> >
> > It works fine under mpl vs. 0.90.1. That has the same statement
> for chi, but defines chi internally inside the eps file (which is
> much bigger).
> >
> > Thanks, Mark
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 18, 2008 at 7:09 PM, mdroe <md...@st...
> <mailto:md...@st...>> wrote:
> >
> > > It looks like it may be Windows-specific. I can create .eps
> files with
> > > math on mpl-0.91.2, Python 2.5, gs-7.07 on Linux without problems.
> > > Someone with a Windows installation may need to look at this.
> > >
> > > Just so I can have a deeper look -- can you please attach
> > >
> > > a) the Python source of a minimal plot that causes this problem
> > > b) your .eps file output (so I can compare it against mine).
> > >
> > > Mike
> > >
> >
> >
>
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I have confirmed that it is a bug in (at least the windows version) of mpl
0.91.2.
When saving eps files, and using mathtext, the cm fonts don't get saved, and
the
greek symbols (and others I presume) don't show up in the eps file.
This works in mpl 0.90.1, where the eps file does store the fonts.
%%BeginFont: Cmmi10
When running the same problem with 0.91.2, the fonts are not stored.
Either using ps.fonttype 3 or 42.
Anybody who can fix this?
Thanks, Mark
On Wed, Mar 19, 2008 at 11:21 AM, Bernhard Voigt <Ber...@de...>
wrote:
> Hi Mark!
>
> The problem seems to be that the computer modern font (cm) is not
> included in the eps file. The snipped of the eps file I sent before
> defines the font cmmi10:
>
> %!PS-Adobe-3.0 Resource-Font
> %%Title: cmmi10
> %%Copyright: Copyright (C) 1994, Basil K. Malyshev. All Rights
> Reserved.012BaKoMa Fonts Colle
> ction, Level-B.
> %%Creator: Converted from TrueType by PPR
> .....
> /FontName /Cmmi10 def
>
> And later, when the \chi glyph should be drawn, the font is changed to:
> /Cmmi10 findfont
> 16.0 scalefont
> setfont
> 0.000000 4.921875 moveto
> /chi glyphshow
>
> Which is the same in your file, but your file only contains the
> Bitstreem Vera Sans font for the axis ticks. Cmmi10 is missing :-(
>
> Your pdf, however, does contain the cmmi10 font, you can check via
> file->properties->fonts.
>
> You should have the following in your matplotlibrc file (well, you
> said you have it, but let me repeat):
> mathtext.fontset : cm
> mathtext.fallback_to_cm : True
> ps.useafm : False
> ps.fonttype : 3
>
> Check the settings using the interpreter prompt:
>
> In [10]: p.rcParams['mathtext.fontset']
> Out[10]: 'cm'
> etc...
>
> Well, if they are all correctly set, it's probably a bug in the ps
> backend not including the mathtext font.
>
> A workaround would be to convert the pdf file to ps (either use
> command line options of acroread or print to file), edit the ps file
> to be a eps by changing the header to %!PS-Adobe-2.0 EPSF-2.0 and make
> sure the bounding box is specified (see
> http://www.postscript.org/FAQs/language/node82.html for details)
>
> Bernhard
>
>
> On Wed, Mar 19, 2008 at 10:22 AM, Mark Bakker <ma...@gm...> wrote:
> > Hello Mike -
> >
> > Thanks for taking a look at this.
> > Easy example:
> >
> > from pylab import *
> > plot([1,2,3])
> > text(1,1.5,r'$\chi$')
> > savefig('d:/temp/test.eps')
> >
> > There shoud now be a line and the symbol chi.
> > Works great in the pdf file, not in the eps file.
> > Both are attached.
> >
> > Strangely enough at the end of the eps file there are statements:
> >
> > 0.000000 3.703125 moveto
> > /chi glyphshow
> >
> > Which looks to me like writing chi.
> > I have now tried this on 4 windows machines, with different
> installations of gsview, but it doesn't work on any.
> >
> > It works fine under mpl vs. 0.90.1. That has the same statement for chi,
> but defines chi internally inside the eps file (which is much bigger).
> >
> > Thanks, Mark
> >
> >
> >
> >
> >
> >
> >
> > On Tue, Mar 18, 2008 at 7:09 PM, mdroe <md...@st...> wrote:
> >
> > > It looks like it may be Windows-specific. I can create .eps files
> with
> > > math on mpl-0.91.2, Python 2.5, gs-7.07 on Linux without problems.
> > > Someone with a Windows installation may need to look at this.
> > >
> > > Just so I can have a deeper look -- can you please attach
> > >
> > > a) the Python source of a minimal plot that causes this problem
> > > b) your .eps file output (so I can compare it against mine).
> > >
> > > Mike
> > >
> >
> >
>

Eric Firing wrote:
> In general, I don't think mpl is threadsafe at all; it uses global 
> variables, such as all the rc parameters, that could easily be 
> modified by one thread while being used by another. I think that 
> great care would be needed if one wanted to have multiple threads 
> making plots. Having one plotting thread and any number of threads 
> doing other things, however, should be OK.
Oh yes -- I didn't think of the rcParams.
>
> Michael Droettboom wrote:
>> At least the Agg backend *looks* to be reasonably threadsafe -- there 
>> are no obvious gotchas like global variables etc. Note, though, that 
>> multithreading may not gain much in the way of performance since the 
>> global interpreter lock is never released around long-running C blocks.
>
> Possibly this could be changed. The danger would be accidentally 
> modifying or deleting an array that is being used by C extension code.
Modifying may be problematic, but deleting would not be likely -- the C 
function holds a reference to each of the arrays as they are using them.
>
>>
>> However, I can't speak about this from any experience -- so, maybe it 
>> needs some trying. Any patches to help with thread safety and 
>> performance are of course welcome ;)
>
> At the very least, I think we would have to take all the global state 
> information and put it in a class instance, so there could be multiple 
> plotting machines. Pyplot would then instantiate and use one of 
> these; the OO API would allow one to instantiate any number of them. 
> I have not thought about how easy or hard this would be.
Ditto that. Having just come back from PyCon, I'll parrot the standard 
Python answer to this question which is: "Don't use threads, use 
multiple processes", which would seem to solve all these issues -- but, 
I understand that it not always the best solution.
Mike
>
> Eric
>
>>
>> Cheers,
>> Mike
>>
>> Chris Withers wrote:
>>> Hi All,
>>>
>>> I'm wondering what work people have done with matplotlib in 
>>> multi-threaded environments such as your average python web framework.
>>>
>>> Is matplotlib threadsafe?
>>>
>>> How have people gone about safely using it in a multi-threaded 
>>> environment?
>>>
>>> cheers,
>>>
>>> Chris
>>>
>>> 
>>
>>
>> ------------------------------------------------------------------------- 
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Eric Firing wrote:
> This is not doing what you think it is,
Indeed, I guess I was seeing nans being treated as missing values rather 
than being masked...
> You should use numpy.masked_where(numpy.isnan(aa), aa).
I am now ;-)
However, I'm still running into problems when I try and plot the gappy 
data on a filled line as follows:
dates = *an array of datetimes*
values = *an array containing data values and a few nans*
values = numpy.ma.masked_where(numpy.isnan(values),values)
xs,ys = mlab.poly_between(dates,0,values)
pylab.fill(xs,ys,'r')
For starters, I get this warning:
numpy\core\ma.py:609: UserWarning: Cannot automatically convert masked 
array to numeric because data is masked in one or more locations.
...and wherever a NaN occurs in the data, the line is plotted off the 
top of the axes. I want it to appear at 0 if there's no data. Well, 
ideally just not appear at all, but I'd settle for appearing at 0...
Any ideas?
cheers,
Chris
-- 
Simplistix - Content Management, Zope & Python Consulting
 - http://www.simplistix.co.uk

Pierre GM wrote:
> Could you send me an example of the kind of data you're using ?
It's basically performance and volume data for a high-volume website.
Unfortunately, the data is gappy in places due to data collection errors 
in the past...
(it's important the gaps are shown, rather than trying to interpolate 
them away, however)
> As it seems you're dealing with series indexed in time, you may want to try 
> scikits.timeseries, a package Matt Knox and myself implemented for that very 
> reason.
How would this help me here and where can I find out about it?
cheers,
Chris
-- 
Simplistix - Content Management, Zope & Python Consulting
 - http://www.simplistix.co.uk

Eric Firing wrote:
> Short of laboriously putting an image in each bar, no.
That's a shame :-(
So, no gradient filled patches in MPL?
Chris
-- 
Simplistix - Content Management, Zope & Python Consulting
 - http://www.simplistix.co.uk

Hello Mike -
Thanks for taking a look at this.
Easy example:
from pylab import *
plot([1,2,3])
text(1,1.5,r'$\chi$')
savefig('d:/temp/test.eps')
There shoud now be a line and the symbol chi.
Works great in the pdf file, not in the eps file.
Both are attached.
Strangely enough at the end of the eps file there are statements:
0.000000 3.703125 moveto
/chi glyphshow
Which looks to me like writing chi.
I have now tried this on 4 windows machines, with different installations of
gsview, but it doesn't work on any.
It works fine under mpl vs. 0.90.1. That has the same statement for chi, but
defines chi internally inside the eps file (which is much bigger).
Thanks, Mark
On Tue, Mar 18, 2008 at 7:09 PM, mdroe <md...@st...> wrote:
> It looks like it may be Windows-specific. I can create .eps files with
> math on mpl-0.91.2, Python 2.5, gs-7.07 on Linux without problems.
> Someone with a Windows installation may need to look at this.
>
> Just so I can have a deeper look -- can you please attach
>
> a) the Python source of a minimal plot that causes this problem
> b) your .eps file output (so I can compare it against mine).
>
> Mike
>

In general, I don't think mpl is threadsafe at all; it uses global 
variables, such as all the rc parameters, that could easily be modified 
by one thread while being used by another. I think that great care 
would be needed if one wanted to have multiple threads making plots. 
Having one plotting thread and any number of threads doing other things, 
however, should be OK.
Michael Droettboom wrote:
> At least the Agg backend *looks* to be reasonably threadsafe -- there 
> are no obvious gotchas like global variables etc. Note, though, that 
> multithreading may not gain much in the way of performance since the 
> global interpreter lock is never released around long-running C blocks.
Possibly this could be changed. The danger would be accidentally 
modifying or deleting an array that is being used by C extension code.
> 
> However, I can't speak about this from any experience -- so, maybe it 
> needs some trying. Any patches to help with thread safety and 
> performance are of course welcome ;)
At the very least, I think we would have to take all the global state 
information and put it in a class instance, so there could be multiple 
plotting machines. Pyplot would then instantiate and use one of these; 
the OO API would allow one to instantiate any number of them. I have 
not thought about how easy or hard this would be.
Eric
> 
> Cheers,
> Mike
> 
> Chris Withers wrote:
>> Hi All,
>>
>> I'm wondering what work people have done with matplotlib in 
>> multi-threaded environments such as your average python web framework.
>>
>> Is matplotlib threadsafe?
>>
>> How have people gone about safely using it in a multi-threaded environment?
>>
>> cheers,
>>
>> Chris
>>
>> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users