matplotlib-users Mailing List for matplotlib

Hi all,
i have a simple scatter plot, where the x axis and y axis are on different
scales starting from 0. the x axis here ranges from 0 to 300 and the y axis
from 0 to 1. i plot it as follows:
my_fig = plt.figure(figsize=(6,5), dpi=100)
x = rand(100)*300
y = rand(100)
plt.scatter(x, y)
plt.rcParams['xtick.direction'] = 'out'
plt.rcParams['ytick.direction'] = 'out'
plt.xlim([-0.05, 300.05])
plt.ylim([-0.05, 1.05])
plt.show()
i'd like to leave a bit of space between the origin and the x-axis 0 and
between the origin and y-axis 0, which is why i added 0.05 to the end points
of each axis. however, i'd like the space between 0 and the origin on either
axis to be the same. since 0.05 on a scale from 0 to 300 is not the same
amount of space as 0.05 on a scale from 0 to 1, this is not the effect i
get. the yaxis looks good but the xaxis does not. how can i fix this?
second, how can i remove the upper x axis ticks and the right y axis ticks?
these ticks are really not informative to the plot. ideally i would like to
remove those axes altogether, and just have one x axis and one y axis -- but
i don't want to manually plot the axes. is there a way to do this?
if that is not possible i'd like to at least remove those tick marks from
the duplicate axes. any thoughts on this will be greatly appreciated.
thank you

Denis-B wrote:
>
> Jeff Whitaker wrote:
> 
>> Denis: I have added an 'interp' keyword to griddata (svn revision 7287) 
>> so you can choose the faster linear interpolation with interp='linear'. 
>>
>>
>> 
>
> Thanks Jeff,
> that was quick. Do you also see linear waaaay faster than NN, factor 100
> ?!
> (Fwiw, a quick run of the Mac Shark profiler shows lots of time in
> NaturalNeighbors::interpolate_one
> which uses stdlib stacks heavily -- overkill for tiny stacks.)
> 
Denis: I see more like a factor of 3 or 4, not 100.
> Did my last question on Ntri -> Ngrid -> Npix make any sense at all ?
> 
Not really, but I haven't had the time to think about it very hard.
-Jeff
> It would be nice if one could go straight from a triangulation to pixels --
> will ask AGG.
>
> cheers
> -- denis
>
>
> 
-- 
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

Jeff Whitaker wrote:
> 
> 
> Denis: I have added an 'interp' keyword to griddata (svn revision 7287) 
> so you can choose the faster linear interpolation with interp='linear'. 
> 
> 
Thanks Jeff,
 that was quick. Do you also see linear waaaay faster than NN, factor 100
?!
(Fwiw, a quick run of the Mac Shark profiler shows lots of time in
NaturalNeighbors::interpolate_one
which uses stdlib stacks heavily -- overkill for tiny stacks.)
Did my last question on Ntri -> Ngrid -> Npix make any sense at all ?
It would be nice if one could go straight from a triangulation to pixels --
will ask AGG.
cheers
 -- denis
-- 
View this message in context: http://www.nabble.com/speeding-up-griddata%28%29-tp24467055p24646383.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi,
I'm having strange problems with contourf plots. The plotting routine 
is rather elaborate, so I don't have an easy way to reproduce the 
problem (unfortunately). The problem should be evident from the 
attachments. As you can see, the contourf routine doesn't color the 
whole plot area. Also, after some editing in Adobe Illustrator, it is 
also easy to see that some contours are drawn on top of others. This 
must surely be a bug?
I would like to note that this happened on the TkAgg (using show()), 
Agg (png format), ps (eps format), macosx (using show()) and pdf 
backends. Also, for some data sets, the plot turns out just fine - I 
get this problem only for some data sets. I have no idea how to debug 
this, so I'd appreciate any hints you might provide.
The file original.pdf shows the matplotlib result. The file edited.pdf 
shows that you have contours on top of each other. The file 
gnuplot.png gives an idea of what the end result should be: a lot of 
bumps around 3.5 eV, but some of this structure is missing from the 
contourf plots. The gnuplot plot was generated from the same data 
(ASCII text) file.
Best regards,
Paul.

kbkb wrote:
> 
> Hi
> This should be so simple, but I have been struggling for a long time
> trying to create a square plot of exact dimensions (so a series of them
> can be overlaid later), with x and y axis limits identical and set by me
> (preferably without the plot limits updating automatically as I add or
> delete data, but that is a separate issue), while working interactively on
> a single plot using pyplot in ipython on OS X using the current enthought
> distribution.
> 
> with pyplot imported as plt,
> typical of what I have tried are many variations on 
> 
> plt.plot(*args) with args a list of
> x,y sets
> fig = plt.gcf()
> fig.set_size_inches(6,6,forward='True') to force a redraw
> ax = plt.gca()
> ax.grid(True)
> plt.axis([1.0,10.0,1.0,10.0])
> plt.draw()
> 
> Sometimes the x axis is set correctly, but the y axis is not, and is
> typically showing more range (approximately 0.8-10.1 for example),
> possibly because the plot is not square, though it is close, or because
> the scales are not equal.
> 
> I have tried adding 'equal' to the plt.axis command, 
> and entering the values as
> plt.axis(xmin=1.0,xmax=10.0,ymin=1.0,ymax=10.0)
> and entering just the first three and then
> plt.axis('equal')
> and I have tried working with 
> ax.set_aspect('equal')
> 
> But, I am truly lost as I try to sort out which elements are in control.
> Any help or leads would be greatly appreciated. 
> Scanning old archives and googling has not yet got me there. 
> 
> kersey
> 
Hi kersey,
maybe it helps if you set the figure size already while you inilialise it.
I use e.g.
--CODE--
fig = figure(1, figsize=(20,7), dpi = 80)
--CODE--
to generate non squared plots. To make a square plot figsize have to be e.g
figsize=(10,10). But I do not know if this really works, maybe only the
figure has an equal aspect ratio and the real plot not. 
Otherwise you can set the plot aspect ratio = equal with
matplotlib.axes.Axes.set_aspect
Details can be found here:
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.set_aspect
Andreas
 
-- 
View this message in context: http://www.nabble.com/square-plots-with-linear-equal-axes-----help-tp24638812p24644304.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Nils Wagner wrote:
> On 2009年7月23日 16:15:27 -0400
> Michael Droettboom <md...@st...> wrote:
>> The latest version I see there is 2.3.9. Is this another instance of 
>> the sourceforge file display bug that haunted matplotlib recently?
>>
>> Mike
>>
>
> Is it possible to install matplotlib with freetype 1.3.1 ?
I suspect the statement of "at least version 1.4" is true, but that 
requirement was created before I joined the project. However, version 
1.3.1 is almost 10 years old -- it's worthwhile using something more 
recent if only for the quality of the rendering, if not outright API 
incompatibilities.
Cheers,
Mike
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hello,
I am looking for a way to get interactive plotting in wing ide to run
(preferably matplotlib). I have tried to thread the show() method of
matplotlib with a Timer from the threading module. This was suggested
in the wingware how-tos pdf. Unfortunately, it does not work for me.
The show() method does not return and the shell freezes. Has anyone
experience with interactive plotting in wing? Thanks in advance.
With kind regards,
Daniel

Jorge Scandaliaris <jorgesmbox-ml@...> writes:
> 
> <jorgesmbox-ml@...> writes:
> 
> > 
> > Hi,
> > I have a strange problem. It seems to me it is related to 
> > mpl.axes.Axes.add_collection(), but I am too lost to be sure. 
> 
> Well, I haven't solved this problem yet, but it seems that the add_collection()
> method is not the one at fault. It looks like the lasso widget I am using to
> selct the regions is returning for the fourth region the same vertices than for
> the third one. 
Well, definitely I was wrong at my initial guess. It turns out the problem was a
race condition in the LassoManager class handling the Lasso widget. Putting a
few print statements here and there revealed the problem: I had two callback
functions competing against each other, one called by the lasso widget and the
other connected to mouse release event. One of them was setting a variable used
by the other. My guess is I (mis)used an old version of the lasso_demo, because
when I re visited the example section yesterday, I realized the lasso_demo had
no callback connected to the mouse release event.
I write this as a reference, hoping it can help someboby in the future.
Jorge

Thanks Jae-Joon, it's working now. And thanks for pointing me to "spine",
that's exactly what I was looking for!
Cheers,
N
On Thu, Jul 23, 2009 at 6:40 PM, Jae-Joon Lee <lee...@gm...> wrote:
> Hi,
>
> Thanks for reporting this.
> The axes class in axes_grid toolkits uses different artists to render
> ticks and ticklabels. And some of the features in the original
> matplotlib won't work correctly, and the "tick direction" turned out
> to be one of them.
>
> However, I just committed a fix for this to the svn (r7292), so it
> should work now.
> So, please install mpl from the current svn again, and test it.
> Unfortunately, while the ticks are rotated, the pad for tick labels
> are not automatically adjusted.
> Therefore, you may want to adjust it manually. e.g.,
>
> ax.axis["left"].major_tick_pad = 10
>
> I'll try to improve this in the future.
>
> On the other hand, you may take a look at the recently added "spine"
> support in the main matplotlib.
>
>
> http://matplotlib.sourceforge.net/examples/pylab_examples/spine_placement_demo.html
>
> If you use spine, than all the ticks & ticklabels feature in mpl will work.
>
> Regards,
>
> -JJ
>
>
> On Thu, Jul 23, 2009 at 3:23 PM, Nicolas Pinto<nic...@gm...>
> wrote:
> > Hello,
> >
> > I'm trying to get the ticks "out" in the following scripts using
> matplotlib
> > svn version. Any reason why it's not working ? Should I dig deeper in
> > mpl_toolkits ?
> >
> > # -- Script 1
> > # modified from
> >
> http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline3.html
> > import matplotlib.pyplot as plt
> > from mpl_toolkits.axes_grid.axislines import Subplot
> >
> > plt.rc("xtick", direction="out")
> > plt.rc("ytick", direction="out")
> >
> > fig = plt.figure(1, (3,3))
> >
> > ax = Subplot(fig, 111)
> > fig.add_subplot(ax)
> >
> > ax.axis["right"].set_visible(False)
> > ax.axis["top"].set_visible(False)
> >
> > plt.show()
> >
> > # -- EOF
> >
> > # -- Script 2
> > # modified from
> >
> http://matplotlib.sourceforge.net/examples/axes_grid/simple_axisline2.html
> >
> > import matplotlib.pyplot as plt
> > from mpl_toolkits.axes_grid.axislines import SubplotZero
> > import numpy as np
> >
> > plt.rc("xtick", direction="out")
> > plt.rc("ytick", direction="out")
> >
> > fig = plt.figure(1, (4,3))
> >
> > # a subplot with two additiona axis, "xzero" and "yzero". "xzero" is
> > # y=0 line, and "yzero" is x=0 line.
> > ax = SubplotZero(fig, 1, 1, 1)
> > fig.add_subplot(ax)
> >
> > # make xzero axis (horizontal axis line through y=0) visible.
> > ax.axis["xzero"].set_visible(True)
> > ax.axis["xzero"].label.set_text("Axis Zero")
> >
> > # make other axis (bottom, top, right) invisible.
> > for n in ["bottom", "top", "right"]:
> > ax.axis[n].set_visible(False)
> >
> > xx = np.arange(0, 2*np.pi, 0.01)
> > ax.plot(xx, np.sin(xx))
> >
> > plt.show()
> >
> > # -- EOF
> >
> > Thanks for your help.
> >
> > Best regards,
> >
> > --
> > Nicolas Pinto
> > Ph.D. Candidate, Brain & Computer Sciences
> > Massachusetts Institute of Technology, USA
> > http://web.mit.edu/pinto
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
>
-- 
Nicolas Pinto
Ph.D. Candidate, Brain & Computer Sciences
Massachusetts Institute of Technology, USA
http://web.mit.edu/pinto

Hi
This should be so simple, but I have been struggling for a long time trying
to create a square plot of exact dimensions (so a series of them can be
overlaid later), with x and y axis limits identical and set by me
(preferably without the plot limits updating automatically as I add or
delete data, but that is a separate issue), while working interactively on a
single plot using pyplot in ipython on OS X using the current enthought
distribution.
with pyplot imported as plt,
typical of what I have tried are many variations on 
plt.plot(*args) with args a list of x,y
sets
fig = plt.gcf()
fig.set_size_inches(6,6,forward='True') to force a redraw
ax = plt.gca()
ax.grid(True)
plt.axis([1.0,10.0,1.0,10.0])
plt.draw()
Sometimes the x axis is set correctly, but the y axis is not, and is
typically showing more range (approximately 0.8-10.1 for example), possibly
because the plot is not square, though it is close, or because the scales
are not equal.
I have tried adding 'equal' to the plt.axis command, 
and entering the values as
plt.axis(xmin=1.0,xmax=10.0,ymin=1.0,ymax=10.0)
and entering just the first three and then
plt.axis('equal')
and I have tried working with 
ax.set_aspect('equal')
But, I am truly lost as I try to sort out which elements are in control.
Any help or leads would be greatly appreciated. 
Scanning old archives and googling has not yet got me there. 
kersey
-- 
View this message in context: http://www.nabble.com/square-plots-with-linear-equal-axes-----help-tp24638812p24638812.html
Sent from the matplotlib - users mailing list archive at Nabble.com.