matplotlib-users Mailing List for matplotlib

Thanks for the thorough investigation.
Michiel: can you look into why the macosx backend is drawing the strokes 
around the polygons? Probably as simple as inadvertently ignoring an 
argument.
I'll look into the path simplification-related issues.
Cheers,
Mike
On 06/15/2009 03:29 PM, Zane Selvans wrote:
> Yes. By far the worst of these behaviors is the macosx GUI output. I
> could see the other ones just being the way it's supposed to look.
> Here's a summary:
>
> backend: macosx; path.simplify: (false|true) GUI => black borders to
> drawn polygons (incl. contour region crossing lines, very bad)
> http://zaneselvans.org/dropbox/contourf_backendmacosx.png
>
> backend: agg (PNG output) path.simplify: (true|false) => somewhat
> visible borders between polygons (esp. adjacent to contrasting colors)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.png
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.png
>
> backend: pdf (PDF output) path.simplify: true => reliably visible
> irregularities (but probably this is somewhat expected with SVG
> output)
> http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf
>
> backend: pdf (PDF output) path.simplify: false => infinitessimally
> thin lines of background color visible between contour filled regions.
> http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf
>
> And here's what I used to generate them:
>
> def broken_contourf():
> """
> Simple demonstration that filled contour plots are broken.
>
> Looking at the PDF and PNG output using the macosx backend, everything is
> fine. It's only the GUI output which is for some reason outlining the
> polygons in the filled contours.
>
> """
> from numpy.random import uniform, seed
> from matplotlib.mlab import griddata
> import matplotlib.pyplot as plt
> import numpy as np
> # make up data.
> #npts = int(raw_input('enter # of random points to plot:'))
> seed(-1)
> npts = 200
> x = uniform(-2,2,npts)
> y = uniform(-2,2,npts)
> z = x*np.exp(-x**2-y**2)
> # define grid.
> xi = np.linspace(-2.1,2.1,100)
> yi = np.linspace(-2.1,2.1,100)
> # grid the data.
> zi = griddata(x,y,z,xi,yi)
> # contour the gridded data, plotting dots at the nonuniform data points.
> CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
> # plot data points.
> plt.title('griddata() and contourf() test')
> plt.savefig('broken_contourf.pdf')
> plt.savefig('broken_contourf.png')
>
> On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...> wrote:
> 
>> I switched back to using the macosx backend, and it turns out that the
>> thin black lines surrounding the polygons (including crossing the
>> filled contour regions from one closed contour to another) only get
>> displayed in the GUI. PDF and PNG output look fine.
>>
>> Zane
>>
>> On Fri, Jun 12, 2009 at 2:27 PM, Zane Selvans<za...@id...> wrote:
>> 
>>> If I set path.simplify: False, the shape of the gaps between the
>>> filled polygons does change. Instead of being irregular, it becomes
>>> an infinitessimally thin gap of uniform width, allowing the (in this
>>> case white) background to show through.
>>>
>>> In both of these cases (path.simplify: True|False), the PNG version of
>>> the same figures also show representations of these gaps which are
>>> identical to those which appear in the PDF (though obviously
>>> pixelated), so I don't think it's something that's wrong in the vector
>>> graphics code per se.
>>>
>>> Zane
>>>
>>> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
>>> 
>>>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>>>> False? There have been recent changes to that code.
>>>>
>>>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>>>> the savefig() command and provide a filename, rather than using show().
>>>>
>>>> Cheers,
>>>> Mike
>>>>
>>>> Zane Selvans wrote:
>>>> 
>>>>> Um, yeah. So my response got bounced because of the attachment. Take 2:
>>>>>
>>>>> For some reason my script bombed when I switched to the Agg backend,
>>>>> trying to display to the screen (it said Figure has no method show())
>>>>>
>>>>> So I output the plot as both a PDF and a PNG (still having backend:
>>>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>>>> visible between the polygons making up the filled contours. This
>>>>> wasn't the case with my previously installed setup. It looks as if
>>>>> for some reason the vertices of the filled polygons are being
>>>>> calculated differently from different sides of the same contour,
>>>>> leading to overlap in some places, and gaps in others. You can download
>>>>> the PDF version (in which the exact geometry is much clearer).
>>>>> from:
>>>>>
>>>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>>>
>>>>> Zane
>>>>>
>>>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>>>> wrote:
>>>>>
>>>>> 
>>>>>> So you see this behavior if you switch to the Agg backend? That's the
>>>>>> backend used to generate the images in the gallery. If there's a
>>>>>> difference
>>>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>>>> (which
>>>>>> is still relatively new) is in order.
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> Zane Selvans wrote:
>>>>>>
>>>>>> 
>>>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>>>> the filled contours. Additionally, there is always a single vertical
>>>>>>> line crossing from each contour boundary to the next. I'm guessing
>>>>>>> that these are the edges of the filled polygons which are getting
>>>>>>> drawn. This behavior doesn't seem to be consistent with the
>>>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>>>> doesn't come out looking like the picture in the documentation/example
>>>>>>> gallery...
>>>>>>>
>>>>>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>>>>>> force the edges of the polygons not to get drawn?
>>>>>>>
>>>>>>> This is on Mac OS X 10.5.7, with
>>>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>>>> matplotlib.__version__ = 0.98.6svn
>>>>>>> numpy.__version__=1.4.0.dev6728
>>>>>>>
>>>>>>> As installed by superpack_2009年03月28日.sh
>>>>>>> from http://macinscience.org/?page_id=6
>>>>>>>
>>>>>>> using:
>>>>>>> backend: macosx
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Zane
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 
>>>>>> --
>>>>>> Michael Droettboom
>>>>>> Science Software Branch
>>>>>> Operations and Engineering Division
>>>>>> Space Telescope Science Institute
>>>>>> Operated by AURA for NASA
>>>>>>
>>>>>>
>>>>>>
>>>>>> 
>>>>>
>>>>>
>>>>> 
>>>> --
>>>> Michael Droettboom
>>>> Science Software Branch
>>>> Operations and Engineering Division
>>>> Space Telescope Science Institute
>>>> Operated by AURA for NASA
>>>>
>>>>
>>>> 
>>>
>>> --
>>> Zane A. Selvans
>>> Amateur Earthling
>>> http://zaneselvans.org
>>> +1 303 815 6866
>>>
>>> 
>>
>> --
>> Zane A. Selvans
>> Amateur Earthling
>> http://zaneselvans.org
>> +1 303 815 6866
>>
>> 
>
>
>
> 

JPKay wrote:
> Hello, 
>
> Now that I have correctly imported the NetCDF file and set up the kind of
> projection I am interested in having the data displayed over I am having
> trouble plotting my data with the quiver function. I am interested in
> plotting the principal vectors of the stress field onto a Mercator
> projection. 
> My netcdf file is telling me the following after "ncdump -h"
> dimensions:
> 	nsr_delta = 20 ;
> 	time = 24 ;
> 	latitude = 37 ;
> 	longitude = 73 ;
> variables:
> 	float nsr_delta(nsr_delta) ;
> 		nsr_delta:units = "" ;
> 		nsr_delta:long_name = "NSR Surface Delta (mu/(eta*omega))" ;
> 	float time(time) ;
> 		time:units = "degrees" ;
> 		time:long_name = "degrees after periapse" ;
> 	float latitude(latitude) ;
> 		latitude:units = "degrees_north" ;
> 		latitude:long_name = "latitude" ;
> 	float longitude(longitude) ;
> 		longitude:units = "degrees_east" ;
> 		longitude:long_name = "longitude" ;
> 	float Ttt_D(time, latitude, longitude) ;
> 		Ttt_D:units = "Pa" ;
> 		Ttt_D:long_name = "north-south component stress of Diurnal stresses" ;
> 	float Tpt_D(time, latitude, longitude) ;
> 		Tpt_D:units = "Pa" ;
> 		Tpt_D:long_name = "shear component of Diurnal stresses" ;
> 	float Tpp_D(time, latitude, longitude) ;
> 		Tpp_D:units = "Pa" ;
> 		Tpp_D:long_name = "east-west component of Diurnal stresses" ;
> 	float Ttt_N(nsr_delta, latitude, longitude) ;
> 		Ttt_N:units = "Pa" ;
> 		Ttt_N:long_name = "north-south component of NSR stresses" ;
> 	float Tpt_N(nsr_delta, latitude, longitude) ;
> 		Tpt_N:units = "Pa" ;
> 		Tpt_N:long_name = "shear component of NSR stresses" ;
> 	float Tpp_N(nsr_delta, latitude, longitude) ;
> 		Tpp_N:units = "Pa" ;
> 		Tpp_N:long_name = "east-west component of NSR stresses" ;
>
> // global attributes:
> 		:description = "Testing pySatStress on a regular grid" ;
> 		:history = "Created: Mon Jun 15 12:46:13 2009 using pySatStress" ;
> 		:Conventions = "COARDS" ;
> However, when I am strugglingto use the quiver_demo.py as a guide to making
> my quiver plot. 
> Thanks for any help you can offer. 
> Jon 
>
> 
Jon: Have you looked the quiver_demo.py in the basemap examples? If 
so, what problems did you have adopting that code? 
As always, a simple script demonstrating your problem is most helpful.
-Jeff
-- 
Jeffrey S. Whitaker Phone : (303)497-6313
Meteorologist FAX : (303)497-6449
NOAA/OAR/PSD R/PSD1 Email : Jef...@no...
325 Broadway Office : Skaggs Research Cntr 1D-113
Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg

Hello, 
Now that I have correctly imported the NetCDF file and set up the kind of
projection I am interested in having the data displayed over I am having
trouble plotting my data with the quiver function. I am interested in
plotting the principal vectors of the stress field onto a Mercator
projection. 
My netcdf file is telling me the following after "ncdump -h"
dimensions:
	nsr_delta = 20 ;
	time = 24 ;
	latitude = 37 ;
	longitude = 73 ;
variables:
	float nsr_delta(nsr_delta) ;
		nsr_delta:units = "" ;
		nsr_delta:long_name = "NSR Surface Delta (mu/(eta*omega))" ;
	float time(time) ;
		time:units = "degrees" ;
		time:long_name = "degrees after periapse" ;
	float latitude(latitude) ;
		latitude:units = "degrees_north" ;
		latitude:long_name = "latitude" ;
	float longitude(longitude) ;
		longitude:units = "degrees_east" ;
		longitude:long_name = "longitude" ;
	float Ttt_D(time, latitude, longitude) ;
		Ttt_D:units = "Pa" ;
		Ttt_D:long_name = "north-south component stress of Diurnal stresses" ;
	float Tpt_D(time, latitude, longitude) ;
		Tpt_D:units = "Pa" ;
		Tpt_D:long_name = "shear component of Diurnal stresses" ;
	float Tpp_D(time, latitude, longitude) ;
		Tpp_D:units = "Pa" ;
		Tpp_D:long_name = "east-west component of Diurnal stresses" ;
	float Ttt_N(nsr_delta, latitude, longitude) ;
		Ttt_N:units = "Pa" ;
		Ttt_N:long_name = "north-south component of NSR stresses" ;
	float Tpt_N(nsr_delta, latitude, longitude) ;
		Tpt_N:units = "Pa" ;
		Tpt_N:long_name = "shear component of NSR stresses" ;
	float Tpp_N(nsr_delta, latitude, longitude) ;
		Tpp_N:units = "Pa" ;
		Tpp_N:long_name = "east-west component of NSR stresses" ;
// global attributes:
		:description = "Testing pySatStress on a regular grid" ;
		:history = "Created: Mon Jun 15 12:46:13 2009 using pySatStress" ;
		:Conventions = "COARDS" ;
However, when I am strugglingto use the quiver_demo.py as a guide to making
my quiver plot. 
Thanks for any help you can offer. 
Jon 
-- 
View this message in context: http://www.nabble.com/Quiver-plot-of-a-netcdf-file-tp23986313p24041837.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Yes. By far the worst of these behaviors is the macosx GUI output. I
could see the other ones just being the way it's supposed to look.
Here's a summary:
backend: macosx; path.simplify: (false|true) GUI => black borders to
drawn polygons (incl. contour region crossing lines, very bad)
http://zaneselvans.org/dropbox/contourf_backendmacosx.png
backend: agg (PNG output) path.simplify: (true|false) => somewhat
visible borders between polygons (esp. adjacent to contrasting colors)
http://zaneselvans.org/dropbox/contourf_simplifytrue.png
http://zaneselvans.org/dropbox/contourf_simplifyfalse.png
backend: pdf (PDF output) path.simplify: true => reliably visible
irregularities (but probably this is somewhat expected with SVG
output)
http://zaneselvans.org/dropbox/contourf_simplifytrue.pdf
backend: pdf (PDF output) path.simplify: false => infinitessimally
thin lines of background color visible between contour filled regions.
http://zaneselvans.org/dropbox/contourf_simplifyfalse.pdf
And here's what I used to generate them:
def broken_contourf():
 """
 Simple demonstration that filled contour plots are broken.
 Looking at the PDF and PNG output using the macosx backend, everything is
 fine. It's only the GUI output which is for some reason outlining the
 polygons in the filled contours.
 """
 from numpy.random import uniform, seed
 from matplotlib.mlab import griddata
 import matplotlib.pyplot as plt
 import numpy as np
 # make up data.
 #npts = int(raw_input('enter # of random points to plot:'))
 seed(-1)
 npts = 200
 x = uniform(-2,2,npts)
 y = uniform(-2,2,npts)
 z = x*np.exp(-x**2-y**2)
 # define grid.
 xi = np.linspace(-2.1,2.1,100)
 yi = np.linspace(-2.1,2.1,100)
 # grid the data.
 zi = griddata(x,y,z,xi,yi)
 # contour the gridded data, plotting dots at the nonuniform data points.
 CS = plt.contourf(xi,yi,zi,15,cmap=plt.cm.jet)
 # plot data points.
 plt.title('griddata() and contourf() test')
 plt.savefig('broken_contourf.pdf')
 plt.savefig('broken_contourf.png')
On Fri, Jun 12, 2009 at 3:02 PM, Zane Selvans<za...@id...> wrote:
> I switched back to using the macosx backend, and it turns out that the
> thin black lines surrounding the polygons (including crossing the
> filled contour regions from one closed contour to another) only get
> displayed in the GUI. PDF and PNG output look fine.
>
> Zane
>
> On Fri, Jun 12, 2009 at 2:27 PM, Zane Selvans<za...@id...> wrote:
>> If I set path.simplify: False, the shape of the gaps between the
>> filled polygons does change. Instead of being irregular, it becomes
>> an infinitessimally thin gap of uniform width, allowing the (in this
>> case white) background to show through.
>>
>> In both of these cases (path.simplify: True|False), the PNG version of
>> the same figures also show representations of these gaps which are
>> identical to those which appear in the PDF (though obviously
>> pixelated), so I don't think it's something that's wrong in the vector
>> graphics code per se.
>>
>> Zane
>>
>> On Fri, Jun 12, 2009 at 11:46 AM, Michael Droettboom<md...@st...> wrote:
>>> Shot in the dark here, but what if you set the rcParam "path.simplify" to
>>> False? There have been recent changes to that code.
>>>
>>> Also, since the Agg backend doesn't have an associated GUI, you need to use
>>> the savefig() command and provide a filename, rather than using show().
>>>
>>> Cheers,
>>> Mike
>>>
>>> Zane Selvans wrote:
>>>>
>>>> Um, yeah. So my response got bounced because of the attachment. Take 2:
>>>>
>>>> For some reason my script bombed when I switched to the Agg backend,
>>>> trying to display to the screen (it said Figure has no method show())
>>>>
>>>> So I output the plot as both a PDF and a PNG (still having backend:
>>>> agg in my rcfile) and in both of those cases, irregular gaps are
>>>> visible between the polygons making up the filled contours. This
>>>> wasn't the case with my previously installed setup. It looks as if
>>>> for some reason the vertices of the filled polygons are being
>>>> calculated differently from different sides of the same contour,
>>>> leading to overlap in some places, and gaps in others. You can download
>>>> the PDF version (in which the exact geometry is much clearer).
>>>> from:
>>>>
>>>> http://zaneselvans.org/dropbox/LinDensity_Grid.pdf
>>>>
>>>> Zane
>>>>
>>>> On Fri, Jun 12, 2009 at 5:51 AM, Michael Droettboom<md...@st...>
>>>> wrote:
>>>>
>>>>>
>>>>> So you see this behavior if you switch to the Agg backend? That's the
>>>>> backend used to generate the images in the gallery. If there's a
>>>>> difference
>>>>> there, that would seem to suggest some tweaking of the macosx backend
>>>>> (which
>>>>> is still relatively new) is in order.
>>>>>
>>>>> Mike
>>>>>
>>>>> Zane Selvans wrote:
>>>>>
>>>>>>
>>>>>> I just installed the latest SciPy Superpack in order to get access to
>>>>>> the scipy.spatial.KDTree class, and discovered that for some reason
>>>>>> now when I use contourf() lines get drawn at the boundaries between
>>>>>> the filled contours. Additionally, there is always a single vertical
>>>>>> line crossing from each contour boundary to the next. I'm guessing
>>>>>> that these are the edges of the filled polygons which are getting
>>>>>> drawn. This behavior doesn't seem to be consistent with the
>>>>>> contourf() documentation and when I run code in griddata_demo.py it
>>>>>> doesn't come out looking like the picture in the documentation/example
>>>>>> gallery...
>>>>>>
>>>>>> Is anyone else seeing this behavior? Is there a keyword I can use to
>>>>>> force the edges of the polygons not to get drawn?
>>>>>>
>>>>>> This is on Mac OS X 10.5.7, with
>>>>>> scipy.__version__ = 0.8.0.dev5635
>>>>>> matplotlib.__version__ = 0.98.6svn
>>>>>> numpy.__version__=1.4.0.dev6728
>>>>>>
>>>>>> As installed by superpack_2009年03月28日.sh
>>>>>> from http://macinscience.org/?page_id=6
>>>>>>
>>>>>> using:
>>>>>> backend: macosx
>>>>>>
>>>>>> Cheers,
>>>>>> Zane
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Michael Droettboom
>>>>> Science Software Branch
>>>>> Operations and Engineering Division
>>>>> Space Telescope Science Institute
>>>>> Operated by AURA for NASA
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>
>>
>>
>> --
>> Zane A. Selvans
>> Amateur Earthling
>> http://zaneselvans.org
>> +1 303 815 6866
>>
>
>
>
> --
> Zane A. Selvans
> Amateur Earthling
> http://zaneselvans.org
> +1 303 815 6866
>
-- 
Zane A. Selvans
Amateur Earthling
http://zaneselvans.org
+1 303 815 6866

On Mon, Jun 15, 2009 at 10:31 AM, Christoph Gohlke<cg...@uc...> wrote:
> Hi John,
>
> I rebuilt the installer and egg and confirmed that the distributed
> matplotlibrc file contains "backend: TkAgg".
>
> <http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3.win32-py2.6.exe.zip>
>
> <http://www.lfd.uci.edu/~gohlke/download/matplotlib-0.98.5.3_r0-py2.6-win32.egg.zip>
Great -- thanks a lot. I have uploaded these to the sf site and
tested both the egg and exe and both are working out-of-the-box on my
system at least.
JDH

On Mon, Jun 15, 2009 at 10:12 AM, CaseyWeb<niw...@ho...> wrote:
>
> I do have wxPython 2.8 installed so I don't know why this would have caused
> the problem in the first place, but I changed the matplotlibrc to backend :
> TkAgg and I still get the windows crash. Just to be clear, this isn't an
> import error or simple python exit; I'm actually getting the Windows crash
> dialog box whenever I import pylab. Importing matplotlib doesn't seem to
> cause any problems, but I haven't tried to do anything with it yet.
make sure you have a clean installation by removing
site-packages/matplotlib and any associated eggs. I tried the exe
installer and got the wxpython traceback. I switched to tkagg and was
able to make plots, save pngs, etc.
JDH

I do have wxPython 2.8 installed so I don't know why this would have caused
the problem in the first place, but I changed the matplotlibrc to backend :
TkAgg and I still get the windows crash. Just to be clear, this isn't an
import error or simple python exit; I'm actually getting the Windows crash
dialog box whenever I import pylab. Importing matplotlib doesn't seem to
cause any problems, but I haven't tried to do anything with it yet.
John Hunter-4 wrote:
> 
> Apparently the binaries are fine but the default matplotlib rc is
> setting the backend to wxagg. site-packages/matplotlib/mpl-data and
> set
> 
> backend : TkAgg
> 
> See also http://matplotlib.sourceforge.net/users/customizing.html
> 
-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24036525.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On Mon, Jun 15, 2009 at 16:36, TP<par...@fr...> wrote:
> Hi everybody,
>
> I want to modify a matplotlib.lines.Line2D and update the plot.
> I have used Line2D._y member to modify the line. It works. But by doing
> canvas.draw() (see example below), the line is not updated on the plot. To
> update it, I have to do autoscale_view(). But I do not want the x and y
> ranges of the plot to be changed.
I think you want the 'line.set_ydata' method, where you pass the new Y
data for your plot (there are also set_xdata and set_data to set,
respectively, the X data and the whole set of X/Y); then call a draw
on the canvas.
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

On Mon, Jun 15, 2009 at 9:36 AM, TP<par...@fr...> wrote:
> Hi everybody,
>
> I want to modify a matplotlib.lines.Line2D and update the plot.
> I have used Line2D._y member to modify the line. It works. But by doing
> canvas.draw() (see example below), the line is not updated on the plot. To
> update it, I have to do autoscale_view(). But I do not want the x and y
> ranges of the plot to be changed.
Turn autoscaling off with
 ax.set_autoscale_on(False)
update the line with
 line.set_ydata(newdata)
draw the canvas with
 fig.canvas.draw()
JDH

Hi everybody,
I want to modify a matplotlib.lines.Line2D and update the plot.
I have used Line2D._y member to modify the line. It works. But by doing
canvas.draw() (see example below), the line is not updated on the plot. To
update it, I have to do autoscale_view(). But I do not want the x and y
ranges of the plot to be changed.
How to do this?
Thanks in advance,
Julien
###################
from pylab import *
import matplotlib
ion()
f = figure()
s = f.add_subplot("111")
X1 = arange( 0.0, 5.0, 0.1 )
# print X1, X1**2
line = matplotlib.lines.Line2D( X1, X1**2 )
s.add_line( line )
draw()
raw_input("\npress a key to transform y in y+10")
line._y += 10
raw_input("\npress a key to do canvas.draw()")
s.figure.canvas.draw()
draw()
print "The line y has not been updated in y+10"
raw_input("\npress a key to do relim, autoscale and canvas.draw()")
s.relim()
s.autoscale_view()
s.figure.canvas.draw()
draw()
print "The line y has been updated in y+10"
print "But the subplot x and y range has changed"
print "I want the line to be updated without changing x and y ranges"
raw_input("\npress a key to quit")
#################
-- 
python -c "print ''.join([chr(154 - ord(c)) for c in '*9(9&(18%.\
9&1+,\'Z4(55l4('])"
"When a distinguished but elderly scientist states that something is
possible, he is almost certainly right. When he states that something is
impossible, he is very probably wrong." (first law of AC Clarke)

On Mon, Jun 15, 2009 at 7:38 AM, CaseyWeb<niw...@ho...> wrote:
> I installed this on python 2.6.2 using the windows installer (the .exe) but
> it crashes even on something as
> simple as importing pylab from the interactive prompt. To make sure it
> wasn't a conflict with other packages, I created a clean virtualenv
> directory and installed matplotlib from the 2.6 egg, but the results are the
> same. Trying to run any matplotlib example immediately creates a windows
> exception dialog.
Apparently the binaries are fine but the default matplotlib rc is
setting the backend to wxagg. site-packages/matplotlib/mpl-data and
set
backend : TkAgg
See also http://matplotlib.sourceforge.net/users/customizing.html
Christoph, would you be able to rebuild the installers using TkAgg as
the default backend? Basically, at build time, you need to copy
setup.cfg.template to setup.cfg and set the line
backend = TkAgg
There are additional details at
 http://matplotlib.sourceforge.net/devel/release_guide.html#packaging
and
 http://matplotlib.sourceforge.net/faq/installing_faq.html#backends
Thanks!
JDH

It seems that default backend for Windows binaries is TkAgg in Python 2.5 but
WXAgg in Python 2.6 (files from matplotlib/mpl-data in eggs are
different).So without WxPython (what is quite common) there is ImportError
with simple "from pylab import *".
It could be solved very simply and then everything is ok including saving of
png files.
Thank you,
Petr Marhoun
John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
> 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> for python2.5 and 2.6 (if you need 2.4 please respond here). Sorry
> for the delay, but we hit a nasty python2.6/libpng/mingw that held us
> up. Thanks to Christoph Gohlke
> for the visual studio builds and Charlie Moad for the MingW framework.
> 
> Please let us know if you have any troubles.
> 
> JDH
> 
-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24035403.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

John,
I installed this on python 2.6.2 using the windows installer (the .exe) but
it crashes even on something as 
simple as importing pylab from the interactive prompt. To make sure it
wasn't a conflict with other packages, I created a clean virtualenv
directory and installed matplotlib from the 2.6 egg, but the results are the
same. Trying to run any matplotlib example immediately creates a windows
exception dialog.
Casey
John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
> 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> Please let us know if you have any troubles.
> 
> JDH
> 
-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24033870.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

I installed the binaries using the .exe file on Python 2.6.2 but it throws a
windows exception when I try to do anything with matplotlib, even just
typing 'import pylab' in the python command interpreter. To rule out any
conflicts, I created a python virtualenv directory and installed matplotlib
from the .egg file, but it still throws an exception every time.
Casey
John Hunter-4 wrote:
> 
> The windows binaries for the latest matplotlib release are now
> available for download at
> 
> 
> https://sourceforge.net/project/showfiles.php?group_id=80706&package_id=278194
> 
> for python2.5 and 2.6.
> 
-- 
View this message in context: http://www.nabble.com/matplotlib-0.98.5.3-windows-binaries-available-tp24023736p24033941.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi all,
In order to proceed with contacting speakers, we'd now like to get
some feedback from you. This Doodle poll should take no more than a
couple of minutes to fill out (no password or registration required):
http://doodle.com/hb5bea6fivm3b5bk
So please let us know which topics you are most interested in, and
we'll do our best to accommodate everyone. Keep in mind that speaker
availability and balancing out the topics means that the actual
tutorials offered probably won't be exactly the list of top 8 voted
topics, but the feedback will certainly help us steer the decision
process.
Thanks for your time,
Dave Peterson and Fernando Perez
On Mon, Jun 1, 2009 at 10:21 PM, Fernando Perez<fpe...@gm...> wrote:
> Hi all,
>
> The time for the Scipy'09 conference is rapidly approaching, and we
> would like to both announce the plan for tutorials and solicit
> feedback from everyone on topics of interest.
>
> Broadly speaking, the plan is something along the lines of what we
> had last year: one continuous 2-day tutorial aimed at introductory
> users, starting from the very basics, and in parallel a set of
> 'advanced' tutorials, consisting of a series of 2-hour sessions on
> specific topics.
>
> We will request that the presenters for the advanced tutorials keep
> the 'tutorial' word very much in mind, so that the sessions really
> contain hands-on learning work and not simply a 2-hour long slide
> presentation. We will thus require that all the tutorials will be
> based on tools that the attendees can install at least 2 weeks in
> advance on all platforms (no "I released it last night" software).
>
> With that in mind, we'd like feedback from all of you on possible
> topics for the advanced tutorials. We have space for 8 slots total,
> and here are in no particular order some possible topics. At this
> point there are no guarantees yet that we can get presentations for
> these, but we'd like to establish a first list of preferred topics to
> try and secure the presentations as soon as possible.
>
> This is simply a list of candiate topics that various people have
> informally suggested so far:
>
> - Mayavi/TVTK
> - Advanced topics in matplotlib
> - Statistics with Scipy
> - The TimeSeries scikit
> - Designing scientific interfaces with Traits
> - Advanced numpy
> - Sparse Linear Algebra with Scipy
> - Structured and record arrays in numpy
> - Cython
> - Sage - general tutorial
> - Sage - specific topics, suggestions welcome
> - Using GPUs with PyCUDA
> - Testing strategies for scientific codes
> - Parallel processing and mpi4py
> - Graph theory with Networkx
> - Design patterns for efficient iterator-based scientific codes.
> - Symbolic computing with sympy
>
> We'd like to hear from any ideas on other possible topics of interest,
> and we'll then run a doodle poll to gather quantitative feedback with
> the final list of candidates.
>
> Many thanks,
>
> f
>