matplotlib-users Mailing List for matplotlib (Page 4)

On 2013年03月20日 8:57 AM, Jonathan Slavin wrote:
> Hi all,
>
> I've run across a minor but annoying bug. It can be demonstrated pretty
> simply:
>
> fig, ax = plt.subplots(2,1,sharex=True,figsize=(7.,7.))
> fig.subplots_adjust(hspace=0.0)
> x = 4.25*(np.arange(6.) - 2.5)/10.
> y = 0.6*x/max(x)
> ax[0].plot(x,y)
> ax[0].set_xlim(-1.2,1.2)
> ax[0].set_aspect('equal')
> ax[1].plot(x,y)
> ax[0].set_ylim(-0.6,0.6)
> ax[1].set_ylim(-0.6,0.6)
> ax[1].set_aspect('equal')
> plt.show()
>
> The problem is that the y limits on the two plots are slightly different
> from those set:
I think the problem is that you are trying to specify too many things: 
you are specifying the box dimensions when you make the axes, then you 
are specifying xlim, and then you are specifying ylim, but then you are 
asking for a 1:1 aspect ratio. Something has to give! The aspect ratio 
handling is designed to provide the specified aspect ratio under a wide 
range of circumstances, including zooming and panning, and to do that, 
it has to be able to change something. You can choose to let the box 
dimensions be changeable, or the data limits.
If you want to fix the data limits, then you have to make the box 
adjustable. This can cause problems with shared axes, but you can try 
it with ax[0].set_aspect('equal', adjustable='box-forced').
Eric
> ax[1].get_ylim()
> (-0.61935483870967734, 0.61935483870967734)
> and doing a set_ylim doesn't have any effect. This seems to be caused
> by the set_aspect('equal'), since removing it results in plots with the
> correct limits -- but aspect that is not quite equal. It is affected by
> the figsize parameter in the call to subplots. It seems I can get the
> correct y limits and aspect if I keep the set_aspect('equal') and fiddle
> with the figsize. But that certainly doesn't seem to be a desirable
> behavior. Ideally, the set_ylim (or set_xlim) would be respected as
> well as the apect ratio and extra blank space around the figure would be
> added as needed to fit the figsize.
>
> By the way, using no figsize argument to subplots results in y limits
> even smaller than the data limits. Also, this problem does not occur
> for single (non-stacked) plots and the use of subplots_adjust also does
> not seem to affect the problem. I'm using matplotlib 1.2.0
>
> I did notice that this issue is similar to that discussed in this
> thread:
> http://www.mail-archive.com/mat...@li.../msg05783.html
>
> Regards,
> Jon
>

Hi all,
I've run across a minor but annoying bug. It can be demonstrated pretty
simply:
fig, ax = plt.subplots(2,1,sharex=True,figsize=(7.,7.))
fig.subplots_adjust(hspace=0.0)
x = 4.25*(np.arange(6.) - 2.5)/10.
y = 0.6*x/max(x)
ax[0].plot(x,y)
ax[0].set_xlim(-1.2,1.2)
ax[0].set_aspect('equal')
ax[1].plot(x,y)
ax[0].set_ylim(-0.6,0.6)
ax[1].set_ylim(-0.6,0.6)
ax[1].set_aspect('equal')
plt.show()
The problem is that the y limits on the two plots are slightly different
from those set:
ax[1].get_ylim()
(-0.61935483870967734, 0.61935483870967734)
and doing a set_ylim doesn't have any effect. This seems to be caused
by the set_aspect('equal'), since removing it results in plots with the
correct limits -- but aspect that is not quite equal. It is affected by
the figsize parameter in the call to subplots. It seems I can get the
correct y limits and aspect if I keep the set_aspect('equal') and fiddle
with the figsize. But that certainly doesn't seem to be a desirable
behavior. Ideally, the set_ylim (or set_xlim) would be respected as
well as the apect ratio and extra blank space around the figure would be
added as needed to fit the figsize.
By the way, using no figsize argument to subplots results in y limits
even smaller than the data limits. Also, this problem does not occur
for single (non-stacked) plots and the use of subplots_adjust also does
not seem to affect the problem. I'm using matplotlib 1.2.0
I did notice that this issue is similar to that discussed in this
thread:
http://www.mail-archive.com/mat...@li.../msg05783.html
Regards,
Jon
-- 
______________________________________________________________
Jonathan D. Slavin Harvard-Smithsonian CfA
js...@cf... 60 Garden Street, MS 83
phone: (617) 496-7981 Cambridge, MA 02138-1516
 cell: (781) 363-0035 USA
______________________________________________________________

On Wed, Mar 13, 2013 at 2:17 AM, Andrew Dawson <da...@at...> wrote:
> You should see that the circle is no longer circular, and also there are
> weird line width issues. What I want it basically exactly like the attached
> without_clipping.png but with paths inside the circle removed.
The reason that circle is no more circle is that simply inverting the
vertices does not always results in a correctly inverted path.
Instead of following line.
interior.vertices = interior.vertices[::-1]
You should use something like below.
interior = mpath.Path(np.concatenate([interior.vertices[-2::-1],
 interior.vertices[-1:]]),
 interior.codes)
It would be good if we have a method to invert a path.
This will give you a circle. But the weird line width issue remains. This
seems to be an Agg issue, and the line width seems to depend on the dpi.
I guess @mdboom nay have some insight on this.
Regards,
-JJ

Thank you Paul,
             I think the font issue is the mischief of Yahoo. I think I should send mail in text mode rather than html then the issue will not be there I hope. The signature is in normal text mode I saved. Please revert back if my mail shows font issues again so that I can try some thing different. However when I see it in Yahoo there is no issues though..
with best regards,
Sudheer
 
***************************************************************
Sudheer Joseph 
Indian National Centre for Ocean Information Services
Ministry of Earth Sciences, Govt. of India
POST BOX NO: 21, IDA Jeedeemetla P.O.
Via Pragathi Nagar,Kukatpally, Hyderabad; Pin:5000 55
Tel:+91-40-23886047(O),Fax:+91-40-23895011(O),
Tel:+91-40-23044600(R),Tel:+91-40-9440832534(Mobile)
E-mail:sjo...@gm...;sud...@ya...
Web- http://oppamthadathil.tripod.com
***************************************************************
>________________________________
> From: Paul Hobson <pmh...@gm...>
>To: Sudheer Joseph <sud...@ya...> 
>Cc: "mat...@li..." <mat...@li...> 
>Sent: Tuesday, 19 March 2013 11:30 PM
>Subject: Re: [Matplotlib-users] windrose
> 
>
>On Tue, Mar 19, 2013 at 2:22 AM, Sudheer Joseph <sud...@ya...> wrote:
>
>Dear users,
>>             Attached is a windrose diagram created by using https://sourceforge.net/project/showfiles.php?group_id=239240&package_id=290902 . Can any one tell me if the numbers displayed in the attached plot is % of wind directions in each category? or are they represent some other numbers?
>>
>>
>>http://3.bp.blogspot.com/_4ZlrnfU7IT8/TPxpftZGzfI/AAAAAAAAADA/uq9cF3PTpR8/s1600/Wind_rose_plot.jpg
>> 
>
>
>Sudheer, 
>
>
>That's correct. The total length of the bars is the percentage of time that the wind is blowing *from* that direction. 
>See my implementation here: https://github.com/phobson/python-metar/blob/master/metar/graphics.py#L135
>
>
>Side note, you're emails are consistently formatted pretty strangely and can be difficult to read. Perhaps stick with the same font that is in your email signature?
>
>

Just a thought:
Shouldn't the bars terminate with a arc rather then a straight line? What value should one reading this diagram look at? The one at the center of the "bar" or the "corners" these values can be quite different. 
Sent from my iPhone
On Mar 19, 2013, at 8:00 PM, Paul Hobson <pmh...@gm...> wrote:
> On Tue, Mar 19, 2013 at 2:22 AM, Sudheer Joseph <sud...@ya...> wrote:
>> Dear users,
>> Attached is a windrose diagram created by using https://sourceforge.net/project/showfiles.php?group_id=239240&package_id=290902 . Can any one tell me if the numbers displayed in the attached plot is % of wind directions in each category? or are they represent some other numbers?
>> 
>> http://3.bp.blogspot.com/_4ZlrnfU7IT8/TPxpftZGzfI/AAAAAAAAADA/uq9cF3PTpR8/s1600/Wind_rose_plot.jpg
> 
> Sudheer, 
> 
> That's correct. The total length of the bars is the percentage of time that the wind is blowing *from* that direction. 
> See my implementation here: https://github.com/phobson/python-metar/blob/master/metar/graphics.py#L135
> 
> Side note, you're emails are consistently formatted pretty strangely and can be difficult to read. Perhaps stick with the same font that is in your email signature?
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Tue, Mar 19, 2013 at 11:30 AM, Paul Hobson <pmh...@gm...> wrote:
> On Mon, Mar 18, 2013 at 8:34 PM, Mark Lawrence <bre...@ya...>wrote:
>
>> Matplotlib 1.2.0, Windows Vista, Python 3.3.0. I want the first major
>> xtick label aligned with the first date that's plotted. This never
>> happens with the value of day below set in the range zero to six. The
>> first major tick label actually occurs as follows.
>>
>> Day Label date
>> 0 25/03/2013
>> 1 02/04/2013
>> 2 10/04/2013
>> 3 21/03/2013
>> 4 29/03/2013
>> 5 06/04/2013
>> 6 17/03/2013
>>
>> What am I doing wrong?
>>
>> If day is set to seven then no xticks are displayed but labels for
>> 14/03/2013 and 13/03/2014 are displayed. I expected a ValueError or
>> similar using this number. Could you explain this behaviour please?
>>
>> import matplotlib.pyplot as plt
>> from matplotlib.ticker import FormatStrFormatter, MultipleLocator
>> from matplotlib.dates import DateFormatter, WeekdayLocator
>> import datetime
>>
>> dates = [datetime.date(2013, 3, 14), datetime.date(2014, 3, 13)]
>> values = [0, 1]
>> plt.ylabel('Balance')
>> plt.grid()
>> ax = plt.subplot(111)
>> plt.plot_date(dates, values, fmt = 'rx-')
>> plt.axis(xmin=dates[0], xmax=dates[-1])
>> day = ?
>> ax.xaxis.set_major_locator(WeekdayLocator(byweekday=day, interval=4))
>> ax.xaxis.set_minor_locator(WeekdayLocator(byweekday=day))
>> ax.xaxis.set_major_formatter(DateFormatter('%d/%m/%y'))
>> ax.yaxis.set_major_formatter(FormatStrFormatter('£%0.2f'))
>> ax.yaxis.set_minor_locator(MultipleLocator(5))
>> plt.setp(plt.gca().get_xticklabels(), rotation = 45, fontsize = 10)
>> plt.setp(plt.gca().get_yticklabels(), fontsize = 10)
>> plt.show()
>>
>>
> Mark,
>
> I've found that rotation_mode='anchor' works best when rotation != 0
>
> So that makes it:
> plt.setp(plt.gca().get_xticklabels(), rotation = 45, fontsize = 10,
> rotation_mode='anchor' )
>
> HTH,
> -paul
>
I misread your question. Try setting your x-axis limits after defining the
locators and formatters.
-p

On Mon, Mar 18, 2013 at 8:34 PM, Mark Lawrence <bre...@ya...>wrote:
> Matplotlib 1.2.0, Windows Vista, Python 3.3.0. I want the first major
> xtick label aligned with the first date that's plotted. This never
> happens with the value of day below set in the range zero to six. The
> first major tick label actually occurs as follows.
>
> Day Label date
> 0 25/03/2013
> 1 02/04/2013
> 2 10/04/2013
> 3 21/03/2013
> 4 29/03/2013
> 5 06/04/2013
> 6 17/03/2013
>
> What am I doing wrong?
>
> If day is set to seven then no xticks are displayed but labels for
> 14/03/2013 and 13/03/2014 are displayed. I expected a ValueError or
> similar using this number. Could you explain this behaviour please?
>
> import matplotlib.pyplot as plt
> from matplotlib.ticker import FormatStrFormatter, MultipleLocator
> from matplotlib.dates import DateFormatter, WeekdayLocator
> import datetime
>
> dates = [datetime.date(2013, 3, 14), datetime.date(2014, 3, 13)]
> values = [0, 1]
> plt.ylabel('Balance')
> plt.grid()
> ax = plt.subplot(111)
> plt.plot_date(dates, values, fmt = 'rx-')
> plt.axis(xmin=dates[0], xmax=dates[-1])
> day = ?
> ax.xaxis.set_major_locator(WeekdayLocator(byweekday=day, interval=4))
> ax.xaxis.set_minor_locator(WeekdayLocator(byweekday=day))
> ax.xaxis.set_major_formatter(DateFormatter('%d/%m/%y'))
> ax.yaxis.set_major_formatter(FormatStrFormatter('£%0.2f'))
> ax.yaxis.set_minor_locator(MultipleLocator(5))
> plt.setp(plt.gca().get_xticklabels(), rotation = 45, fontsize = 10)
> plt.setp(plt.gca().get_yticklabels(), fontsize = 10)
> plt.show()
>
>
Mark,
I've found that rotation_mode='anchor' works best when rotation != 0
So that makes it:
plt.setp(plt.gca().get_xticklabels(), rotation = 45, fontsize = 10,
 rotation_mode='anchor' )
HTH,
-paul

On Tue, Mar 19, 2013 at 2:22 AM, Sudheer Joseph <sud...@ya...>wrote:
> Dear users,
> Attached is a windrose diagram created by using
> https://sourceforge.net/project/showfiles.php?group_id=239240&package_id=290902. Can any one tell me if the numbers displayed in the attached plot is % of
> wind directions in each category? or are they represent some other numbers?
>
>
> http://3.bp.blogspot.com/_4ZlrnfU7IT8/TPxpftZGzfI/AAAAAAAAADA/uq9cF3PTpR8/s1600/Wind_rose_plot.jpg
>
>
Sudheer,
That's correct. The total length of the bars is the percentage of time that
the wind is blowing *from* that direction.
See my implementation here:
https://github.com/phobson/python-metar/blob/master/metar/graphics.py#L135
Side note, you're emails are consistently formatted pretty strangely and
can be difficult to read. Perhaps stick with the same font that is in your
email signature?

It would be easier if there were some code to reproduce the problem - it
wouldn't have to be the actual data you are using.
I wasn't able to reproduce the problem with the following code:
import mpl_toolkits.basemap as bm
import matplotlib.pyplot as plt
# Geotiff from http://earthobservatory.nasa.gov/IOTD/view.php?id=49687
# FROM gdalinfo
#Corner Coordinates:
#Upper Left ( -11.1339000, 55.8714000) ( 11d 8' 2.04"W, 55d52'17.04"N)
#Lower Left ( -11.1339000, 50.9251367) ( 11d 8' 2.04"W, 50d55'30.49"N)
#Upper Right ( -4.8622296, 55.8714000) ( 4d51'44.03"W, 55d52'17.04"N)
#Lower Right ( -4.8622296, 50.9251367) ( 4d51'44.03"W, 50d55'30.49"N)
#Center ( -7.9980648, 53.3982684) ( 7d59'53.03"W, 53d23'53.77"N)
im = plt.imread('ireland_amo_2010284_geo.tif')
# extent = [left, right, bottom, top]
extent = [-11.1339000, -4.8622296, 50.9251367, 55.8714000]
m = bm.Basemap(projection='cyl',
 llcrnrlon=extent[0], urcrnrlon=extent[1],
 llcrnrlat=extent[2], urcrnrlat=extent[3],
 resolution='i')
plt.imshow(im, extent=extent)
m.drawcoastlines()
plt.show()
[image: Inline images 1]
Your data appears to be a long way off. Are you certain of the bounds that
you are setting? Are you using plt.imshow or doing some other operation to
draw (e.g. contour)?
Cheers,
On 12 March 2013 15:00, Hearne, Mike <mh...@us...> wrote:
> The relevant code is:
> It's kind of hard to post code that's reproducible (lots of
> dependencies on code and data), but I'll attach an image at high
> latitudes that demonstrates the problem.
>
> The image is a shaded relief of topography, and the coastlines are
> drawn in black.
>
> The topography is cut from a large ESRI format BIL (Band Interleaved
> by Line) file, and it's bounds define the boundaries of the map. The
> image data is NOT projected (it's in lat/lon).
>
> --Mike
>
> On Tue, Mar 12, 2013 at 3:46 AM, Phil Elson <pel...@gm...> wrote:
> > Hi Mike,
> >
> > Do you have any code or an image to show the problem?
> >
> > Cheers,
> >
> >
> > On 11 March 2013 20:44, Hearne, Mike <mh...@us...> wrote:
> >>
> >> I have an issue with basemap.imshow() at higher latitudes - namely the
> >> image (high-res topography, in this case) becomes distorted with
> >> respect to the coastlines the higher I go. I assume it has to do
> >> with the image pixels becoming more non-square the higher I go in
> >> latitude.
> >>
> >> I found this discussion:
> >> http://matplotlib.1069221.n5.nabble.com/Basemap-and-imshow-td14115.html
> >>
> >> where Jeff indicates that the user is using a non-rectangular map
> >> projection. I'm thinking that is perhaps my problem (I'm using
> >> Transverse Mercator), but I'm not sure which projections Basemap
> >> supports that *are* rectangular.
> >>
> >> Or perhaps it's something else entirely.
> >>
> >> Any hints?
> >>
> >> Thanks,
> >>
> >> Mike Hearne
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
> >> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
> >> endpoint security space. For insight on selecting the right partner to
> >> tackle endpoint security challenges, access the full report.
> >> http://p.sf.net/sfu/symantec-dev2dev
> >> _______________________________________________
> >> Matplotlib-users mailing list
> >> Mat...@li...
> >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>

That's really weird. @mdboom, do you have any idea what the difference is
when drawing a Path which has a clip path? (I've looked at anti-aliasing &
snapping without success)
On 12 March 2013 17:17, Andrew Dawson <da...@at...> wrote:
> I tried this and although it sort-of works, it doesn't really do what I
> need. I tried using this:
>
> import matplotlib.pyplot as plt
> import matplotlib.path as mpath
> import numpy as np
> import copy
>
> # create figure and axes
> fig = plt.figure(figsize=(6, 6))
> ax = fig.add_axes([.1, .1, .8, .8])
> ax.set_xlim([-3, 3])
> ax.set_ylim([-3, 3])
>
> # a circle at the origin with radius 1
> circle = plt.Circle((0, 0), 1, transform=ax.transData,
> edgecolor='k', facecolor='none')
>
> # from Phil's example
> exterior = mpath.Path.unit_rectangle()
> interior = circle.get_path()
> exterior = mpath.Path(copy.deepcopy(exterior.vertices),
> copy.deepcopy(exterior.codes[:]))
> interior.vertices = interior.vertices[::-1]
> exterior.vertices *= 6
> exterior.vertices -= 3
> clip_path = mpath.Path(vertices=np.concatenate([exterior.vertices,
> interior.vertices]),
> codes=np.concatenate([exterior.codes,
> interior.codes]))
>
> # lines from the origin dividing the axes into 8 sectors
> end_coords = [(3, 0), (3, 3), (0, 3), (-3, 3),
> (-3, 0), (-3, -3), (0, -3), (3, -3)]
> for x, y in end_coords:
> line, = ax.plot((x, 0), (y, 0), color='k')
> line.set_clip_path(clip_path, ax.transData)
>
> ax.add_artist(circle)
>
> plt.show()
>
> and the result is the attached image with_clipping.png. You should see
> that the circle is no longer circular, and also there are weird line width
> issues. What I want it basically exactly like the attached
> without_clipping.png but with paths inside the circle removed.
>
> Thanks
>
>
>
> On 12 March 2013 16:43, Phil Elson <pel...@gm...> wrote:
>
>> You could just use paths which have holes in them, making the exterior so
>> broad that you wouldn't notice the edge of the clipping. I've put together
>> an example of doing just that:
>>
>> import matplotlib.pyplot as plt
>> import matplotlib.path as mpath
>> import matplotlib.collections as mcol
>> import numpy as np
>> import copy
>>
>>
>> exterior = mpath.Path.unit_rectangle()
>> exterior = mpath.Path(copy.deepcopy(exterior.vertices),
>> copy.deepcopy(exterior.codes[:]))
>> exterior.vertices *= 4
>> exterior.vertices -= 2
>> interior = mpath.Path.unit_circle()
>> interior.vertices = interior.vertices[::-1]
>> clip_path = mpath.Path(vertices=np.concatenate([exterior.vertices,
>> interior.vertices]),
>> codes=np.concatenate([exterior.codes,
>> interior.codes]))
>>
>> star = mpath.Path.unit_regular_star(6)
>> star.vertices *= 2.6
>>
>>
>> ax = plt.subplot(321)
>> col = mcol.PathCollection([clip_path], facecolor='yellow')
>> ax.add_collection(col)
>> ax.set_title('Clip path')
>> ax.set_xlim([-3, 3])
>> ax.set_ylim([-3, 3])
>>
>>
>> ax = plt.subplot(322)
>> col = mcol.PathCollection([star], facecolor='red')
>> ax.add_collection(col)
>> ax.set_title('Target polygon')
>> ax.set_xlim([-3, 3])
>> ax.set_ylim([-3, 3])
>>
>>
>> ax = plt.subplot2grid((3, 2), (1, 0), colspan=2, rowspan=2)
>> col = mcol.PathCollection([star])
>> col.set_clip_path(clip_path, ax.transData)
>> ax.add_collection(col)
>>
>> ax.set_title('Target polygon clipped by clip_path')
>> ax.set_xlim([-3, 3])
>> ax.set_ylim([-3, 3])
>>
>> plt.tight_layout()
>>
>> plt.show()
>>
>> [image: Inline images 1]
>>
>>
>>
>> There are other options if this doesn't cut the mustard.
>>
>> HTH,
>>
>>
>>
>>
>>
>>
>>
>> On 12 March 2013 15:37, Andrew Dawson <da...@at...> wrote:
>>
>>> Hi
>>>
>>> I'd like to be able to clip a line so that the portion of it lying
>>> outside of a given polygon remains visible and the part that lies inside of
>>> the polygon is not visible. What I want is basically the opposite of:
>>>
>>> line.set_clip_path(polygon)
>>>
>>> which leaves only the part of the line inside the polygon visible. Is
>>> this possible?
>>>
>>> I know I can just fill the polygon with the background color or
>>> something but this gets messy when there are other lines on the plot that
>>> don't need to be clipped.
>>>
>>> Thanks,
>>> Andrew
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
>>> Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
>>> endpoint security space. For insight on selecting the right partner to
>>> tackle endpoint security challenges, access the full report.
>>> http://p.sf.net/sfu/symantec-dev2dev
>>> _______________________________________________
>>> Matplotlib-users mailing list
>>> Mat...@li...
>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>
>>>
>>
>
>
> --
> Dr Andrew Dawson
> Atmospheric, Oceanic & Planetary Physics
> Clarendon Laboratory
> Parks Road
> Oxford OX1 3PU, UK
> Tel: +44 (0)1865 282438
> Email: da...@at...
> Web Site: http://www2.physics.ox.ac.uk/contacts/people/dawson
>

Dear users,
             Attached is a windrose diagram created by using https://sourceforge.net/project/showfiles.php?group_id=239240&package_id=290902 . Can any one tell me if the numbers displayed in the attached plot is % of wind directions in each category? or are they represent some other numbers?
http://3.bp.blogspot.com/_4ZlrnfU7IT8/TPxpftZGzfI/AAAAAAAAADA/uq9cF3PTpR8/s1600/Wind_rose_plot.jpg
 
***************************************************************
Sudheer Joseph 
Indian National Centre for Ocean Information Services
Ministry of Earth Sciences, Govt. of India
POST BOX NO: 21, IDA Jeedeemetla P.O.
Via Pragathi Nagar,Kukatpally, Hyderabad; Pin:5000 55
Tel:+91-40-23886047(O),Fax:+91-40-23895011(O),
Tel:+91-40-23044600(R),Tel:+91-40-9440832534(Mobile)
E-mail:sjo...@gm...;sud...@ya...
Web- http://oppamthadathil.tripod.com
***************************************************************

Matplotlib 1.2.0, Windows Vista, Python 3.3.0. I want the first major 
xtick label aligned with the first date that's plotted. This never 
happens with the value of day below set in the range zero to six. The 
first major tick label actually occurs as follows.
Day	Label date
0	25/03/2013
1	02/04/2013
2	10/04/2013
3	21/03/2013
4	29/03/2013
5	06/04/2013
6	17/03/2013
What am I doing wrong?
If day is set to seven then no xticks are displayed but labels for 
14/03/2013 and 13/03/2014 are displayed. I expected a ValueError or 
similar using this number. Could you explain this behaviour please?
import matplotlib.pyplot as plt
from matplotlib.ticker import FormatStrFormatter, MultipleLocator
from matplotlib.dates import DateFormatter, WeekdayLocator
import datetime
dates = [datetime.date(2013, 3, 14), datetime.date(2014, 3, 13)]
values = [0, 1]
plt.ylabel('Balance')
plt.grid()
ax = plt.subplot(111)
plt.plot_date(dates, values, fmt = 'rx-')
plt.axis(xmin=dates[0], xmax=dates[-1])
day = ?
ax.xaxis.set_major_locator(WeekdayLocator(byweekday=day, interval=4))
ax.xaxis.set_minor_locator(WeekdayLocator(byweekday=day))
ax.xaxis.set_major_formatter(DateFormatter('%d/%m/%y'))
ax.yaxis.set_major_formatter(FormatStrFormatter('£%0.2f'))
ax.yaxis.set_minor_locator(MultipleLocator(5))
plt.setp(plt.gca().get_xticklabels(), rotation = 45, fontsize = 10)
plt.setp(plt.gca().get_yticklabels(), fontsize = 10)
plt.show()
-- 
Cheers.
Mark Lawrence

Hi David and Ben and everybody reading along,
Apparently I did not phrase my question too well.
To clarify:
I would like to have some 'subplots' with a width proportional to
the amount of (equally spaced) data points.
It seems to me that gridspec (http://matplotlib.org/users/gridspec.html)
is just the tool I need - with this I only need to calculate the
relative sizes of my subplots, but that's easy. Alas, I did not discover
it until tonight.
Thanks a lot for your help!
Christian

On Fri, Mar 15, 2013 at 12:41 PM, Christian Meesters <mee...@gm...>wrote:
> Hi,
>
> It is quite some time ago since I was intensively using MPL. Perhaps I
> will not get the terminology right anymore. And now I hope to get some
> pointer for this particular problem:
>
> I would like to arange some line plots using a grid from left to right in
> a single plot / figure instance. Each of these plots is created from
> vectors (numpy arrays) of a different length. If I would place subplots of
> equal size to place these individual plots from left to right, all will
> appear with a different "stretch/squeeze".
>
> My question now is: Is there a way to place different subplots of
> different sizes automatically? For all my plots I will encounter different
> number of individual line plots of different size.
>
> My approach so far (pseudocode):
>
> from mpl_toolkits.axes_grid1 import Grid
> import pylab as plt
>
> fig = plt.figure(1, (5.5, 3.5))
> grid = Grid(fig, 111, # similar to subplot(111)
> nrows_ncols = (1, number_of_subplots),
> axes_pad = 0.1,
> add_all=True,
> label_mode = "L",
> )
>
> for index in xrange(number_of_subplots):
> grid[index].???
>
> And now I just do not know how to get any further? How will I get the
> necessary extension for each subfigure/plot? Which is the most efficient
> way to accomplish all this? Should I import a different class, other than
> Grid?
>
>
So, are you wanting them to all have the same x and y coordinates, or maybe
you want the aspect ratio to be the same?
I am not exactly quite sure what you mean by "extension".
Ben Root

On 2013年03月15日 08:19, Paul Hobson wrote:> On Fri, Mar 15, 2013 at 8:01 
AM, Christophe BAL <pro...@gm...> wrote:
 >
 >> Hello,
 >> I really appreciate the work done by matplotlib but I really think 
that
 >> the interface must evolve. Here is a small example.
 >>
 >> * object.set_something(...)*
 >> * object.get_something()*
 >>
 >> It could be easier to use a jQuery like style as in the following 
lines.
 >>
 >> * object(...)*
 >> * object()*
 > Interesting thoughts, Christophe. There is currently a MEP to do 
something
 > similar:
 > https://github.com/matplotlib/matplotlib/wiki/MEP13
	I think the current situation is better than this jQuery style, and 
the MEP is better than the current situation. Using lots of verbose 
getters and setters is unpythonic, but calling objects directly in 
that catch-all way is even more unpythonic. There are lots of things 
you might want to do to an MPL object, and we shouldn't elevate 
attribute get/set as the "main one" that should be accessed by the 
call syntax.
	That MEP would be great, though!
-- 
Brendan Barnwell
"Do not follow where the path may lead. Go, instead, where there is 
no path, and leave a trail."
 --author unknown

On Mar 15, 2013 10:01 AM, "Christophe BAL" <pro...@gm...> wrote:
>
> Hello,
> I really appreciate the work done by matplotlib but I really think that
> the interface must evolve. Here is a small example.
>
> object.set_something(...)
> object.get_something()
>
> It could be easier to use a jQuery like style as in the following lines.
>
> object(...)
> object()
>
> This will considerably simplify things.
>
>
> Here is a more realistic example.
>
> fig = pylab.figure()
> ax = fig.add_subplot(1,1,1)
>
> ax.set_xlabel("xLabel")
> ax.set_ylabel("yLabel")
>
> The a jQuery like style would be as in the following lines.
>
> fig = pylab.figure()
> ax = fig.add_subplot(1,1,1)
>
> ax(xlabel = "xLabel", ylabel = "yLabel")
>
Just fyi: you can always do
 ax.set(xlabel="something", ylabel="something")
> I don't know enough matplotlib to propose other examples
> but I really think that there is a lot of things that could make
> matplotlib much more Pythonicly easy to use.
>
> Christophe BAL
>
>
------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,<br/></div><div><br/></div><div>It is quite some time ago since I was intensively using MPL. Perhaps I will not get the terminology right anymore. And now I hope to get some pointer for this particular problem:<br/></div><div><br/></div><div>I would like to arange some line plots using a grid from left to right in a single plot / figure instance. Each of these plots is created from vectors (numpy arrays) of a different length. If I would place subplots of equal size to place these individual plots from left to right, all will appear with a different &quot;stretch/squeeze&quot;.<br/></div><div><br/></div><div>My question now is: Is there a way to place different subplots of different sizes automatically? For all my plots I will encounter different number of individual line plots of different size.<br/></div><div><br/></div><div>My approach so far (pseudocode):<br/></div><div><br/></div><div>from mpl_toolkits.axes_grid1 import Grid<br/>import pylab as plt<br/></div><div><br/></div><div>fig&nbsp; = plt.figure(1, (5.5, 3.5))<br/>grid = Grid(fig, 111, # similar to subplot(111)<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; nrows_ncols = (1, number_of_subplots),<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; axes_pad = 0.1,<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; add_all=True,<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; label_mode = &quot;L&quot;,<br/>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; )<br/></div><div><br/></div><div>for index in xrange(number_of_subplots):<br/></div><div>&nbsp;&nbsp;&nbsp; grid[index].???<br/></div><div><br/></div><div>And now I just do not know how to get any further? How will I get the necessary extension for each subfigure/plot? Which is the most efficient way to accomplish all this? Should I import a different class, other than Grid?<br/></div><div><br/></div><div>TIA<br/></div><div>Regards,<br/></div><div>Christian<br/></div><div><br/></div><div><br/></div></div></body></html>

Christophe BAL:
> I really appreciate the work done by matplotlib but I really think that
> the interface must evolve. Here is a small example.
>
> * object.set_something(...)*
> *object.get_something()*
>
> It could be easier to use a jQuery like style as in the following lines.
>
> *object(...)*
> *object()*
>
> This will considerably simplify things.
>
>
> Here is a more realistic example.
>
> *fig = pylab.figure()*
> *ax = fig.add_subplot(1,1,1)*
> *
> *
> *ax.set_xlabel(*"xLabel"*)*
> *ax.set_ylabel(*"yLabel"*)*
>
> The a jQuery like style would be as in the following lines.
>
> *fig = pylab.figure()*
> *ax = fig.add_subplot(1,1,1)*
> *
> *
> * ax(xlabel = *"xLabel"*, ylabel = *"yLabel"*)*
> *
> *
> I don't know enough matplotlib to propose other examples
> but I really think that *there is a lot **of things that could make *
> *matplotlib much more Pythonicly easy to use.*
I am afraid I disagree a little bit. The call: object(...) [if object 
is an instance, not a class, otherwise ths would be a constructor] -
- means object.call(...).
Now, in principle one can throw inside a generic "call" plenty of 
attribute changes, but just imagine the parsing of all the possible 
argument combination. And, BTW, what would it mean: xxx= ax() ? In 
general case this is not practical.
The methods in Python called.through.the.dot.notation are there to stay, 
I think.
Jerzy Karczmarczuk
Caen, France.

On Mar 15, 2013 4:01 PM, "Christophe BAL" <pro...@gm...> wrote:
>
> Hello,
> I really appreciate the work done by matplotlib but I really think that
> the interface must evolve. Here is a small example.
>
> object.set_something(...)
> object.get_something()
>
> It could be easier to use a jQuery like style as in the following lines.
>
> object(...)
> object()
>
> This will considerably simplify things.
>
>
> Here is a more realistic example.
>
> fig = pylab.figure()
> ax = fig.add_subplot(1,1,1)
>
> ax.set_xlabel("xLabel")
> ax.set_ylabel("yLabel")
>
> The a jQuery like style would be as in the following lines.
>
> fig = pylab.figure()
> ax = fig.add_subplot(1,1,1)
>
> ax(xlabel = "xLabel", ylabel = "yLabel")
>
> I don't know enough matplotlib to propose other examples
> but I really think that there is a lot of things that could make
> matplotlib much more Pythonicly easy to use.
>
> Christophe BAL
>
I don't personally like this approach. Python has very clear separation
between the initialization of methods, which acts like a function that
returns an instance, and the modification of existing instances, which uses
attributes. This syntax muddies the distinction, having something that
should behave like an instance instead behaving as a function.
Is there any precedence for using this sort of syntax in python? I have
not seen it anywhere else. You mention jQuery, but that is JavaScript not
python. As far as I have seen

On Fri, Mar 15, 2013 at 8:01 AM, Christophe BAL <pro...@gm...> wrote:
> Hello,
> I really appreciate the work done by matplotlib but I really think that
> the interface must evolve. Here is a small example.
>
> * object.set_something(...)*
> * object.get_something()*
>
> It could be easier to use a jQuery like style as in the following lines.
>
> * object(...)*
> * object()*
>
> This will considerably simplify things.
>
>
> Here is a more realistic example.
>
> * fig = pylab.figure()*
> * ax = fig.add_subplot(1,1,1)*
> *
> *
> * ax.set_xlabel(*"xLabel"*)*
> * ax.set_ylabel(*"yLabel"*)*
>
> The a jQuery like style would be as in the following lines.
>
> * fig = pylab.figure()*
> * ax = fig.add_subplot(1,1,1)*
> *
> *
> * ax(xlabel = *"xLabel"*, ylabel = *"yLabel"*)*
> *
> *
> I don't know enough matplotlib to propose other examples
> but I really think that there is a lot of things that could make
> matplotlib much more Pythonicly easy to use.
>
>
Interesting thoughts, Christophe. There is currently a MEP to do something
similar:
https://github.com/matplotlib/matplotlib/wiki/MEP13

Hello,
I really appreciate the work done by matplotlib but I really think that
the interface must evolve. Here is a small example.
* object.set_something(...)*
* object.get_something()*
It could be easier to use a jQuery like style as in the following lines.
* object(...)*
* object()*
This will considerably simplify things.
Here is a more realistic example.
* fig = pylab.figure()*
* ax = fig.add_subplot(1,1,1)*
*
*
* ax.set_xlabel(*"xLabel"*)*
* ax.set_ylabel(*"yLabel"*)*
The a jQuery like style would be as in the following lines.
* fig = pylab.figure()*
* ax = fig.add_subplot(1,1,1)*
*
*
* ax(xlabel = *"xLabel"*, ylabel = *"yLabel"*)*
*
*
I don't know enough matplotlib to propose other examples
but I really think that there is a lot of things that could make
matplotlib much more Pythonicly easy to use.
Christophe BAL

http://www.nomer-edno.com/jk/hdde.htm 

it also works for me for 1.2.0
In [1]: mat.__version__
Out[1]: '1.2.0'
In [2]: plot(np.arange(5),'ro')
Out[2]: [<matplotlib.lines.Line2D at 0xc88262c>]
In [3]: ax = gca()
In [4]: ax.set_xticklabels('abcdefghij')
Out[4]: 
[<matplotlib.text.Text at 0xbbb048c>,
 <matplotlib.text.Text at 0xbbb0c8c>,
 <matplotlib.text.Text at 0xc88780c>,
 <matplotlib.text.Text at 0xc887e2c>,
 <matplotlib.text.Text at 0xc88b4cc>,
 <matplotlib.text.Text at 0xc88bb4c>,
 <matplotlib.text.Text at 0xc8911ec>,
 <matplotlib.text.Text at 0xc89186c>,
 <matplotlib.text.Text at 0xc891eec>]
In [5]: [t.get_text() for t in ax.get_xticklabels()]
Out[5]: ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i']
--
View this message in context: http://matplotlib.1069221.n5.nabble.com/ticklabels-tp40656p40663.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

2013年3月14日 Andrew H. Jaffe <a.h...@gm...>:
> Dear all,
>
> None of the obvious ways for changing ticklabels seem to work for the current version of Matplotlib (1.2.0 for me). At present, ax.yaxis.get_ticklabels().get_text() returns empty strings, as does ax.get_yticklabels(), and the equivalent set_* functions don't seem to have any effect.
It seems to be working for me. I'm using a development version but I
don't thing this has changed.
In [1]: import matplotlib.pyplot as plt
In [2]: plt.get_backend()
Out[2]: 'TkAgg'
In [3]: plt.plot([1, 2])
Out[3]: [<matplotlib.lines.Line2D at 0x424c310>]
In [4]: plt.draw()
In [5]: labels = plt.gca().get_yticklabels()
In [6]: map(lambda x: x.get_text(), labels)
Out[6]: [u'1.0', u'1.2', u'1.4', u'1.6', u'1.8', u'2.0', u'2.2', '']
In [7]: plt.gca().set_yticklabels(['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h'])
Out[7]:
[<matplotlib.text.Text at 0x3e97bd0>,
 <matplotlib.text.Text at 0x3ea2390>,
 <matplotlib.text.Text at 0x42bed90>,
 <matplotlib.text.Text at 0x42c0390>,
 <matplotlib.text.Text at 0x42c05d0>,
 <matplotlib.text.Text at 0x42c0c50>,
 <matplotlib.text.Text at 0x42c1310>,
 <matplotlib.text.Text at 0x42c1990>]
In [8]: map(lambda x: x.get_text(), labels)
Out[8]: ['a', 'b', 'c', 'd', 'e', 'f', 'g', 'h']
Goyo

> You must set the desired backend from the very begining and before
> importing pylab o pyplot.
That did it - I made the change in my .matplotlibrc file and it no longer crashes.
Thanks!
Oliver