You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
1
(13) |
2
(12) |
3
(3) |
4
(13) |
5
(13) |
6
(2) |
7
(5) |
8
(17) |
9
(9) |
10
(10) |
11
(16) |
12
(8) |
13
(10) |
14
(1) |
15
(5) |
16
(5) |
17
(7) |
18
(13) |
19
(9) |
20
|
21
|
22
(2) |
23
(3) |
24
(5) |
25
(5) |
26
(14) |
27
(1) |
28
(2) |
29
(18) |
30
(5) |
31
(22) |
|
|
|
Here's some (incomplete) code snippets I used to place an extra x-axis below the normal one. I hope this helps. I agree that more axes can always be added at an arbitrary offset, although I did not try that. import numpy as N import matplotlib matplotlib.use("TkAgg") import pylab as PLT from matplotlib.font_manager import FontProperties # For setting legend font props. f1 = PLT.figure(1, figsize=(7.5,4.0)) ax1 = f1.add_axes([0.2, 0.25, 0.6, 0.6]) # This is "normal" axis PLT.hold(False) ax1.set_autoscale_on(False) # So that I can turn off autoscaling PLT.plot(lt, drift, '-', linewidth=3, label=legtext) # This axis is LT. Set the ticks manually. xticks = N.array([5.0, 8.0, 11.0, 14.0, 17.0, 20.0]) ax1.set_xticks(xticks.tolist()) ax1.set_autoscale_on(False) # So that I can turn off autoscaling # Now manually create the second axis (UT) slightly below PLT.hold(False) ax2 = f1.add_axes([0.2, 0.15, 0.6, 0.6], frameon=False) ax2.set_yticks([]) # Apply offset to get UT scale for second axis ax2.set_xlim([xticks[0]+offset, xticks[len(xticks)-1]+offset]) ax2.set_xticks((xticks+offset).tolist()) # Make tick lines invisible xtl = PLT.getp(ax2, 'xticklines') PLT.setp(xtl, 'visible', False) # Label the X ticks for first (LT) and second (UT) axes PLT.text(1.1, -0.1, 'LT', transform=ax1.transAxes) PLT.text(1.1, -0.25, 'UT', transform=ax1.transAxes) -Tony -- Tony Mannucci Supervisor, Ionospheric and Atmospheric Remote Sensing Group Mail-Stop 138-308, Tel > (818) 354-1699 Jet Propulsion Laboratory, Fax > (818) 393-5115 California Institute of Technology, Email > Ton...@jp... 4800 Oak Grove Drive, http://genesis.jpl.nasa.gov Pasadena, CA 91109
> On 10/5/07, James Boyle <bo...@ll...> wrote: > > I wish to plot 3 lines on a single graph - each line requires a=20 > > separate y scaling but shares a common x. > > The case for 2 such lines is handled by twinx as in the=20 > two_scales.py=20 > > example. > > > > I have not found an example of 3 lines ( or greater). In=20 > the case of=20 > > more than 2 scales the y axis scale would have to float, to=20 > the right=20 > > or left of the y axes defined for the first 2 lines. >=20 > This is on the wish list, but is currently unsupported. >=20 > JDH Hmmm, unsupported, but working. See attached. Maybe I've misunderstood, though. Anyway, I'm not complete sure of your context, but this plot was generated in code, rather than using pylab. I don't use pylab and I don't know if there's an analogue to what I'll describe below. Unfortunately the code used to generate this particular chart is much more than what you're looking for (our current matplotlib based "plot" object is currently 1500 lines of code on top of MPL). It does, however, allow me to plot a line on any of 4 independent "y" axes, and 2 "x" axes (and a bunch of other bells and whistles). The underlying structure creates a "master" figure (X1Y1) and then subsequent figures overlaid on top (ie in the same location by using axes.get_position()). Each subsequent figure uses an appropriate "sharex=3D" in the call figure.add_axes(...). Also significant are to turn the frame off (frameon=3DFalse), and assign a label to each figure (label=3D'myLabel') so that MPL doesn't try to combine figures for you. In principle, I don't see why this can't be done for an arbitrary number of subfigures, but practically, the plot start getting cluttered and confusing pretty quickly. I can't post the code, but if you have some more questions, I can try to help! Cheers, Anthony.
> On 10/5/07, James Boyle <bo...@ll...> wrote: >> I wish to plot 3 lines on a single graph - each line requires a >> separate y scaling but shares a common x. I have not >> found an example of 3 lines ( or greater). On Fri, 5 Oct 2007, John Hunter wrote: > This is on the wish list, but is currently unsupported. If you just need an EPS or PDF, you can use PyX: http://pyx.sourceforge.net/gallery/graphs/manyaxes.html hth, Alan Isaac
On 10/5/07, James Boyle <bo...@ll...> wrote: > I wish to plot 3 lines on a single graph - each line requires a > separate y scaling but shares a common x. > The case for 2 such lines is handled by twinx as in the two_scales.py > example. > > I have not found an example of 3 lines ( or greater). In the case of > more than 2 scales the y axis scale would have to float, to the right > or left of the y axes defined for the first 2 lines. This is on the wish list, but is currently unsupported. JDH
I wish to plot 3 lines on a single graph - each line requires a separate y scaling but shares a common x. The case for 2 such lines is handled by twinx as in the two_scales.py example. I have not found an example of 3 lines ( or greater). In the case of more than 2 scales the y axis scale would have to float, to the right or left of the y axes defined for the first 2 lines. Thanks for any help. ---Jim
The short answer to your two messages is that pcolor and contour required gridded data in 2D arrays, and it looks like you are supplying 1D arrays. Look at the differences between what you have below and what is in the pcolor_demo that you started with. Meshgrid is generating 2D arrays for X and Y so that Z is also 2D. There are other ways of doing it, and for a Cartesian grid, X and Y don't actually have to be 2D--although I find that there is now a bug in svn such that 1D x and y don't work. I will fix that. But in any case, Z *must* be a 2D array. If the data you really want to plot are not already on a grid, then you will need to use a gridding routine, which is not included in mpl. Eric yadin Bocuma Rivas wrote: > I i have tree lists of values > list x of 100... values > list y of 100.. values > list mag of 100.. values > list x and y are coordiantes of points > and list Mag is magnitude of something at that point > > how can i plot this quantities using pcolor > > from __future__ import division > from matplotlib.patches import Patch > from pylab import * > > def func3(x,y): > return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2) > > > # make these smaller to increase the resolution > dx, dy = 0.5, 0.5 > > X = arange(-3.0, 3.0001, dx) > > Y = arange(-3.0, 3.0001, dy) > > Mag= X**2+Y**2 > > pcolor(X, Y, Mag, shading='flat') > colorbar() > axis([-3,3,-3,3]) > savefig('pcolor_demo') > show() > > > ------------------------------------------------------------------------ > > ¡Sé un mejor ambientalista! > Encuentra consejos para cuidar el lugar donde vivimos en: > http://telemundo.yahoo.com/promos/mejorambientalista.html > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi, I just encountered something odd. I have (with import numpy as n and import pylab as pl) : >>> x = n.arange(0, 2*n.pi, n.pi/30) >>> z = n.array([n.cos(x), n.sin(x)]).T If I draw a boxplot on z : >>> pl.boxplot(z) the values z are modified. Is this a feature or a bug ? Matthieu
I i have tree lists of values=0Alist x of 100... values=0Alist y of 100.. v= alues=0Alist mag of 100.. values=0Alist x and y are coordiantes of points = =0Aand list Mag is magnitude of something at that point=0A=0Ahow can i plot= this quantities using pcolor=0A=0Afrom __future__ import division=0Afrom m= atplotlib.patches import Patch=0Afrom pylab import *=0A=0Adef func3(x,y):= =0A return (1- x/2 + x**5 + y**3)*exp(-x**2-y**2)=0A=0A=0A# make these s= maller to increase the resolution=0Adx, dy =3D 0.5, 0.5=0A=0AX =3D arange(-= 3.0, 3.0001, dx)=0A=0AY =3D arange(-3.0, 3.0001, dy)=0A=0AMag=3D X**2+Y**2= =0A=0Apcolor(X, Y, Mag, shading=3D'flat')=0Acolorbar()=0Aaxis([-3,3,-3,3])= =0Asavefig('pcolor_demo')=0Ashow()=0A=0A=0A=0A=0A ____________________= ________________________________________________________________=0A=A1S=E9 = un mejor besador!=0AComparte todo lo que sabes sobre besos. = =0Ahttp://telemundo.yahoo.com/promos/mejorbesador.html
hi i have been trying to use pcolor and/or contour to make a contor map or intensity map i want to do an intensity or contour map of an electric field i have an array (or list) of points [x,y] and for each point i have the respective value of the electric field (in another list) i have tried the examples in matplotlib but they are different because they use meshgrid and from the points calculated in the mesh get values and plot... in my case i want to plot directly...each poin (x,z) its magnitude(E_fiel_Mag) i do not think i need to use meshgrid any more how can i do my plot? below is my code...pls help me!!! #!/usr/bin/env python # This example demonstrates how to use a constraint polygon in # Delaunay triangulation. from scipy import* from pylab import* read_file= open ('W:/Serio/necfile.out','r') L =read_file.readlines() fieldlist =[] f = 0 for line in L: f=f+1 if 'NEAR ELECTRIC FIELDS'in line: rpoints = 3 phipoints = 3 tetapoints = 1 for line in range (f+3,f+4+rpoints*phipoints*tetapoints): fieldlist.append(L[line]) Ex = [];Ey = [];Ez = [] x1 =[];y1=[];z1=[] Exphase=[]; Eyphase=[]; Ezphase=[] for i in range(len(fieldlist)-1): splitlines= fieldlist[i].split() x1.append(float(splitlines[0])) #here we pick up the x,y,x coordinates of the points y1.append(float(splitlines[1])) #where the manitude has been calculated z1.append(float(splitlines[2])) Ex.append(float(splitlines[3])) #pick up the e-filed magnitudes Ey.append(float(splitlines[5])) #u append as floats instead os string for later calculations Ez.append(float(splitlines[7])) Exphase.append(float(splitlines[4])) # pick up the phases just in case they are needed Eyphase.append(float(splitlines[6])) Ezphase.append(float(splitlines[8])) read_file.close() # i want to see if i can calculate the magnitude of the electric field E_field_Mag = [] for i in range(len(Ex)): E_Magnitude = sqrt((Ex[i])**2 + (Ey[i])**2+(Ez[i])**2) E_field_Mag.append(E_Magnitude) #E_field_Mag = array(E_field_Mag) #y values are zero #X,Z = meshgrid(x1, z1) pcolor(x1,y1,E_field_Mag) ----- Mensaje original ---- De: "mat...@li..." <mat...@li...> Para: mat...@li... Enviado: domingo, 30 de septiembre, 2007 12:53:11 Asunto: Matplotlib-users Digest, Vol 16, Issue 32 Send Matplotlib-users mailing list submissions to mat...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/matplotlib-users or, via email, send a message with subject or body 'help' to mat...@li... You can reach the person managing the list at mat...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Matplotlib-users digest..." Today's Topics: 1. Re: NameError: global name '__loader__' is not defined (Eric Firing) 2. Re: plot cdf (Alan G Isaac) 3. Re: edgecolor with usetex=True, usedistiller='pdf' (Darren Dale) 4. Re: Problem with tick labels in scripts (John Hunter) 5. Using special characters (David Loyall) 6. Re: matplotlib - representation of nan values in 2D (Dirk Zickermann) ---------------------------------------------------------------------- Message: 1 Date: 2007年9月27日 14:46:13 -1000 From: Eric Firing <ef...@ha...> Subject: Re: [Matplotlib-users] NameError: global name '__loader__' is not defined To: Hal Huntley <ha...@so...> Cc: mat...@li... Message-ID: <46F...@ha...> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hal Huntley wrote: > Thanks to Eric Firing and Christopher Barker for input on trying to > resolve the problem. Christopher said: > %%% > You might try just: > > easy_install numpy > > easy_install matplotlib. > %%% > > > I did that and now the problem moved and I get: > === >>>> from pylab import * > Traceback (most recent call last): > File "<stdin>", line 1, in ? > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/pylab.py", line 1, in ? > from matplotlib.pylab import * > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/pylab.py", line 222, in ? > new_figure_manager, draw_if_interactive, show = pylab_setup() > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/__init__.py", line 24, in pylab_setup > globals(),locals(),[backend_name]) > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gtkagg.py", line 10, in ? > from matplotlib.backends.backend_gtk import gtk, FigureManagerGTK, > FigureCanvasGTK,\ > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gtk.py", line 21, in ? > from matplotlib.backends.backend_gdk import RendererGDK, FigureCanvasGDK > File > "/usr/lib/python2.4/site-packages/matplotlib-0.90.1-py2.4-linux-i686.egg/matplotlib/backends/backend_gdk.py", line 35, in ? > from matplotlib.backends._ns_backend_gdk import pixbuf_get_pixels_array > ImportError: No module named _ns_backend_gdkd4 > === Is it a rotten egg? > > Googling around has indicated that the X11 stuff wasn't available when the > numpy and matplotlib were made. The gtk files and "-devel" seem to be there > when I do an "rpm -qa". I went and got a new numpy from source and did > "python setup.py install". It is interesting that when I get in to python > now, I can do: > >>>> import gtk >>>> import numpy >>>> import matplotlib > > and they all just return the prompt, indicating, I thought, that the > programs were installed ok. > > Here is the naive question -> Is there something wrong, then with a > "from pylab import *"? The user is trying to do that. No, that should work fine. I don't know how the egg-based matplotlib/pylab should work with the installed-from-source numpy, though. If the versions are compatible, then I expect it would work. You gave a traceback resulting from "from pylab import *" after installing the two eggs, correct? If so, what was the result after you installed numpy from source? I would expect no difference, because the problem reported in the traceback is a missing matplotlib module, not a missing numpy module. Or did you mean that you installed matplotlib from source? That would make more sense, and certainly should work if all the right header files and libraries are present. If you installed matplotlib from source, what do you get from ls /usr/lib/python2.4/site-packages/matplotlib/backends/*.so Another diagnostic would be to delete the build directory from the matplotlib source tree (assuming you are now building matplotlib from source), and save the output from the "python setup.py build" command. This should make it clear whether the necessary headers really were found. Eric ------------------------------ Message: 2 Date: 2007年9月28日 00:18:13 -0400 From: Alan G Isaac <ai...@am...> Subject: Re: [Matplotlib-users] plot cdf To: mat...@li... Message-ID: <Mah...@am...> Content-Type: TEXT/PLAIN; CHARSET=UTF-8 After thinking it over, I did not go for Robert or David's cool numpy tricks, but I'll append a simple object in case someone else wants to do more. Cheers, Alan Isaac class EmpiricalCDF(object): '''Empirical cdf. First point will be (xmin,0). Last point will be (xmax,1). ''' def __init__(self, data, sortdata=True): if sortdata: data = N.sort(data) self.data = data self.nobs = len(data) def gen_xp(self): data, nobs = self.data, self.nobs prob = N.linspace(0, 1, nobs+1) xsteps = ( data[(idx)//2] for idx in xrange(2*nobs) ) psteps = ( prob[(idx+1)//2] for idx in xrange(2*nobs) ) return xsteps, psteps def get_steps(self): '''Return: 2-tuple of arrays, the data values and corresponding cumulative probabilities. ''' xsteps, psteps = self.gen_xp() return N.fromiter(xsteps,'f'), N.fromiter(psteps,'f') ------------------------------ Message: 3 Date: 2007年9月28日 08:23:17 -0400 From: Darren Dale <dd...@co...> Subject: Re: [Matplotlib-users] edgecolor with usetex=True, usedistiller='pdf' To: "John Hunter" <jd...@gm...> Cc: matplotlib-users <mat...@li...>, Eric Firing <ef...@ha...> Message-ID: <200...@co...> Content-Type: text/plain; charset="iso-8859-1" On Friday 28 September 2007 07:36:23 am John Hunter wrote: > On 9/27/07, Darren Dale <dd...@co...> wrote: > > Hi Eric, John, > > > > Have either of you been following this thread? > > I am now :-) > > As Eric suggests, None is overloaded vis-a-vis color handling, because > for mpl properties it generally means do the default as defined by rc. > For colors people often want to use None for "no color" which is why > we added support for the string "None". Does this work in your use > case Tom? The above exchange was off-list, we're back on now. I think that would be what Tom is looking for, but it doesnt work: In [1]: plot([1,2]) Out[1]: [<matplotlib.lines.Line2D instance at 0x710cb0>] In [2]: savefig('dsd.png', facecolor='None', edgecolor='None') --------------------------------------------------------------------------- ValueError Traceback (most recent call last) /home/darren/<ipython console> in <module>() /usr/lib64/python2.5/site-packages/matplotlib/pyplot.py in savefig(*args, **kwargs) 272 def savefig(*args, **kwargs): 273 fig = gcf() --> 274 return fig.savefig(*args, **kwargs) 275 if Figure.savefig.__doc__ is not None: 276 savefig.__doc__ = dedent(Figure.savefig.__doc__) /usr/lib64/python2.5/site-packages/matplotlib/figure.py in savefig(self, *args, **kwargs) 768 kwargs[key] = rcParams['savefig.%s'%key] 769 --> 770 self.canvas.print_figure(*args, **kwargs) 771 772 def colorbar(self, mappable, cax=None, **kw): /usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py in print_figure(self, *args, **kwargs) 153 self.update(l, self.renderer.height-t, w, h) 154 155 def print_figure(self, *args, **kwargs): --> 156 FigureCanvasAgg.print_figure(self, *args, **kwargs) 157 self.draw() /usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in print_figure(self, filename, dpi, facecolor, edgecolor, orientation, format, **kwargs) 1194 edgecolor=edgecolor, 1195 orientation=orientation, -> 1196 **kwargs) 1197 finally: 1198 self.figure.dpi.set(origDPI) /usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in print_png(self, filename, *args, **kwargs) 415 416 def print_png(self, filename, *args, **kwargs): --> 417 self.draw() 418 self.get_renderer()._renderer.write_png(str(filename)) 419 /usr/lib64/python2.5/site-packages/matplotlib/backends/backend_qt4agg.py in draw(self) 140 if DEBUG: print "FigureCanvasQtAgg.draw", self 141 self.replot = True --> 142 FigureCanvasAgg.draw(self) 143 self.update() 144 /usr/lib64/python2.5/site-packages/matplotlib/backends/backend_agg.py in draw(self) 377 378 self.renderer = self.get_renderer() --> 379 self.figure.draw(self.renderer) 380 381 def get_renderer(self): /usr/lib64/python2.5/site-packages/matplotlib/figure.py in draw(self, renderer) 586 self.transFigure.freeze() # eval the lazy objects 587 --> 588 if self.frameon: self.figurePatch.draw(renderer) 589 590 for p in self.patches: p.draw(renderer) /usr/lib64/python2.5/site-packages/matplotlib/patches.py in draw(self, renderer) 198 #renderer.open_group('patch') 199 gc = renderer.new_gc() --> 200 gc.set_foreground(self._edgecolor) 201 gc.set_linewidth(self._linewidth) 202 gc.set_alpha(self._alpha) /usr/lib64/python2.5/site-packages/matplotlib/backend_bases.py in set_foreground(self, fg, isRGB) 617 self._rgb = fg 618 else: --> 619 self._rgb = colors.colorConverter.to_rgb(fg) 620 621 def set_graylevel(self, frac): /usr/lib64/python2.5/site-packages/matplotlib/colors.py in to_rgb(self, arg) 277 278 except (KeyError, ValueError, TypeError), exc: --> 279 raise ValueError('to_rgb: Invalid rgb arg "%s"\n%s' % (str(arg), exc)) 280 # Error messages could be improved by handling TypeError 281 # separately; but this should be rare and not too hard ValueError: to_rgb: Invalid rgb arg "None" invalid literal for float(): None ------------------------------ Message: 4 Date: 2007年9月28日 07:41:35 -0500 From: "John Hunter" <jd...@gm...> Subject: Re: [Matplotlib-users] Problem with tick labels in scripts To: "Charles Seaton" <cs...@st...> Cc: mat...@li... Message-ID: <88e...@ma...> Content-Type: text/plain; charset=ISO-8859-1 On 9/27/07, Charles Seaton <cs...@st...> wrote: > I am having the same problem as Eugen, and the suggested solution of using > a.xaxis.get_major_locator().refresh() > to force the creation of the full set of ticklabels doesn't seem to work for > me. matplotlib creates a prototypical tick (the prototick) and then creates new ones on as as needed basis, copying properties from the prototick. Of course, position is one of the properties that cannot be copied, which is why you are having trouble in your example. Fortunately, there is an easy solution. Call ax.xaxis.get_major_ticks() and access the label attribute: for tick in ax.xaxis.get_major_ticks(): label = tick.label1 Axis.get_major_ticks will force a call to the locator and update the tick list. The Axes methods like get_xticklabels are just working on the existing tick list rather than calling the get_major_ticks method which is why you are not getting the full list. This is a bug. I just made changes in svn so that all the accessor methods (ax.get_xticklines, ax.get_yticklabels, and friends) all trigger a call to axis.get_major_ticks rather so they should give the same results going forward. JDH FYI, the Tick attributes are: tick1line : a Line2D instance tick2line : a Line2D instance gridline : a Line2D instance label1 : a Text instance label2 : a Text instance gridOn : a boolean which determines whether to draw the tickline tick1On : a boolean which determines whether to draw the 1st tickline tick2On : a boolean which determines whether to draw the 2nd tickline label1On : a boolean which determines whether to draw tick label label2On : a boolean which determines whether to draw tick label ------------------------------ Message: 5 Date: 2007年9月29日 21:50:02 -0500 From: "David Loyall" <dav...@th...> Subject: [Matplotlib-users] Using special characters To: mat...@li... Message-ID: <957...@ma...> Content-Type: text/plain; charset=UTF-8 Hello. I've been having trouble getting Unicode characters to render. I just get a box in the title of my figure, rather than the character I need. Here is my code: #!/usr/bin/env python from pylab import * plot([1,2,3,4]) title(u"\u0251") savefig("test.eps") savefig("test.png") show() That character is LATIN SMALL LETTER ALPHA. It's used in the International Phonetic Alphabet. I'm on Linux and I'm using matplotlib 0.90.1-2 (debian package version). I have a few TTF fonts in my system that contain that glyph. One is 'Arial Unicode MS', which I copied from my windows machine. As you can see, I will need to generate an EPS that renders the character... That EPS file will be imported into MS Word on a Windows PC and printed. I will happily use any solution that allows me to use that character in the final product... :) It doesn't have to be unicode.. I believe that my fonts are configured correctly on this Linux system--I can use the Arial Unicode MS font in Open Office. However, I'm not sure that MPL is finding them. When I point the TTFPATH environment variable a directory that only contains ARIALUNI.TTF, I get gibberish for all characters in my figure. When I use ~/.matplotlib/matplotlibrc to list Arial Unicode MS as the only font in the san-serif family, I don't observe any change in the text in the figure. ...I did successfully instantiate an FT2FONT object out of my ARIALUNI.TTF file, but, I didn't know what to do with it at that point. Help? Cheers, --Dave Loyall Omaha, Nebraska, USA ------------------------------ Message: 6 Date: 2007年9月30日 12:53:06 +0200 From: "Dirk Zickermann" <dir...@go...> Subject: Re: [Matplotlib-users] matplotlib - representation of nan values in 2D To: Mat...@li... Message-ID: <511...@ma...> Content-Type: text/plain; charset="iso-8859-1" Dear all, thanks for your help. this is what I was looking for! Dirk 2007年9月26日, Eric Firing <ef...@ha...>: > > David Huard wrote: > > Hi Dirk, > > > > If you haven't already done so, look at the numpy.ma <http://numpy.ma/> > > module. It provides a masked array object that deals gracefully with > > missing values. To the best of my knowledge, most matplotlib functions > > understand masked arrays and deal with it accordingly, exception made of > > those requiring a full matrix (such as contour). Take a look at > > contour handles masked arrays correctly, as far as I know; contourf has > some bugs in its masked array handling, but depending on the type and > distribution of voids, it may still be good enough. > > pcolor and image have no problems with masked arrays. > > Eric > > > examples/image_masked.py. Also, in the Basemap toolkit, there is at > > least one example showing how to plot a masked array on a map. > > > > Cheers, > > > > David > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > -------------- next part -------------- An HTML attachment was scrubbed... ------------------------------ ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ------------------------------ _______________________________________________ Matplotlib-users mailing list Mat...@li... https://lists.sourceforge.net/lists/listinfo/matplotlib-users End of Matplotlib-users Digest, Vol 16, Issue 32 ************************************************ ____________________________________________________________________________________ ¡Sé un mejor asador! Aprende todo sobre asados. http://telemundo.yahoo.com/promos/mejorasador.html
gr...@bi... wrote: > Thanks again Eric, > > Your examples are exactly what I was after. Glad to hear it! > My colleague was hypothesizing that there's probably a less-than instead of a less-than-or-equal somewhere, if it is a bug. > That was part of it, but it was a little more subtle. I have tweaked the automatic level generation routine so that it now does what one might reasonably expect. Specifying levels explicitly is still better when you can do it; the number-of-levels method is really only for quick and dirty exploratory work, when you don't care too much which levels are chosen and you don't know in advance what the data interval will be. Eric
Thanks again Eric, Your examples are exactly what I was after. My colleague was hypothesizing that there's probably a less-than instead of a less-than-or-equal somewhere, if it is a bug. regards, Gary ---- Eric Firing <ef...@ha...> wrote: > gr...@bi... wrote: > > Thanks Eric. > > > > However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour? > > > Now I see the problem; this is something of a corner case, but it may be > pointing to a bug. > > Where do you really want the line to fall? > > Do you need to specify the number of contours instead of specifying the > actual levels (boundaries)? Are you actually dealing with zeros and > ones as in the example? If so, you probably want > > contour(a, [0.5]) > contourf(a, [-1, 0.5, 2], colors=('w', 'k'), extend='neither') > > or > > contourf(a, [0.5, 2], colors=('k',), extend='neither') > In this case you are saying "color everything between 0.5 and 2, and > nothing else". > > Specifying one contour instead of giving the levels is yielding 0.6; > this is a consequence of using the MaxNLocator by default to auto-select > the levels. > > > For the moment, a suitable workaround seems to be to do > > > > contourf(a,1,colors=('w','k')) > > > > where the background colour is white. This generates what I'm after. > > > > I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring. > > I will fix the docstring. Thanks. > > Eric > > > > thanks again, > > Gary > > > > ---- Eric Firing <ef...@ha...> wrote: > >> Gary Ruben wrote: > >>> I'm notice that contourf behaves differently to contour by default in > >>> where it decides to position contours. For example, using pylab, if you try > >>> > >>> a=tri(10) > >>> contourf(a,0) > >>> contour(a,1) > >>> > >>> I'd have expected the contours to line up, but they don't. Is there a > >>> way to get contourf to place its contours at the same position as contour? > >> Specify the same number of levels: > >> > >> contourf(a,1) > >> contour(a,1) > >> > >> > >> That takes care of this simple case. There are other cases, however, > >> where contour and contourf simply don't agree; contouring is ambiguous, > >> and only part of the algorithm is shared between contour and contourf. > >> For well-behaved datasets this is normally not a problem, but it becomes > >> obvious if you contour a random array. > >> > >> Eric > > >
gr...@bi... wrote: > Thanks Eric. > > However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour? > Now I see the problem; this is something of a corner case, but it may be pointing to a bug. Where do you really want the line to fall? Do you need to specify the number of contours instead of specifying the actual levels (boundaries)? Are you actually dealing with zeros and ones as in the example? If so, you probably want contour(a, [0.5]) contourf(a, [-1, 0.5, 2], colors=('w', 'k'), extend='neither') or contourf(a, [0.5, 2], colors=('k',), extend='neither') In this case you are saying "color everything between 0.5 and 2, and nothing else". Specifying one contour instead of giving the levels is yielding 0.6; this is a consequence of using the MaxNLocator by default to auto-select the levels. > For the moment, a suitable workaround seems to be to do > > contourf(a,1,colors=('w','k')) > > where the background colour is white. This generates what I'm after. > > I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring. I will fix the docstring. Thanks. Eric > > thanks again, > Gary > > ---- Eric Firing <ef...@ha...> wrote: >> Gary Ruben wrote: >>> I'm notice that contourf behaves differently to contour by default in >>> where it decides to position contours. For example, using pylab, if you try >>> >>> a=tri(10) >>> contourf(a,0) >>> contour(a,1) >>> >>> I'd have expected the contours to line up, but they don't. Is there a >>> way to get contourf to place its contours at the same position as contour? >> Specify the same number of levels: >> >> contourf(a,1) >> contour(a,1) >> >> >> That takes care of this simple case. There are other cases, however, >> where contour and contourf simply don't agree; contouring is ambiguous, >> and only part of the algorithm is shared between contour and contourf. >> For well-behaved datasets this is normally not a problem, but it becomes >> obvious if you contour a random array. >> >> Eric >
Thanks Eric. However, when I specify the same number of levels as suggested, contourf divides this example into three regions, with a diagonal 'stripe' instead of a clean boundary, so I guess I'm asking whether it's possible to trick contourf into generating a single boundary between the two regions such that it matches that found by contour? For the moment, a suitable workaround seems to be to do contourf(a,1,colors=('w','k')) where the background colour is white. This generates what I'm after. I notice also that linewidths is mentioned in the docstring under Obsolete:, but it seems to do nothing, so it should probably be removed from the docstring. thanks again, Gary ---- Eric Firing <ef...@ha...> wrote: > Gary Ruben wrote: > > I'm notice that contourf behaves differently to contour by default in > > where it decides to position contours. For example, using pylab, if you try > > > > a=tri(10) > > contourf(a,0) > > contour(a,1) > > > > I'd have expected the contours to line up, but they don't. Is there a > > way to get contourf to place its contours at the same position as contour? > > Specify the same number of levels: > > contourf(a,1) > contour(a,1) > > > That takes care of this simple case. There are other cases, however, > where contour and contourf simply don't agree; contouring is ambiguous, > and only part of the algorithm is shared between contour and contourf. > For well-behaved datasets this is normally not a problem, but it becomes > obvious if you contour a random array. > > Eric