matplotlib-users Mailing List for matplotlib (Page 5)

The axes_grid toolkit is base on use cases for images of aspect 1, and
I haven't carefully considered cases where the aspect is different
from 1. And I guess this is one of such cases I overlooked.

Please try to add below lines in your code (I couldn't try your code
because of the missing data file, but it works with the the scatter
example you referred).


ax.set_aspect("auto")
divider.set_aspect(True)
divider.get_horizontal()[0]._aspect=0.5

The interface should be improved but I guess this will work.

Regards,

-JJ


On Fri, Jul 24, 2009 at 1:19 PM, Jeff Thomas<jef...@gm...> wrote:
> Currently, I am trying to plot a 2D array with imshow and two 1D arrays
> on separate plots attached to the top and right of the imshow image. I got
> it to work, however when I change the aspect of the image (which I want to
> do) white space and unusual scalings appear. I want to get rid of it and
> have the scales that match the aspect.
> Basically, I want to do the same thing shown in the
> example http://matplotlib.sourceforge.net/examples/axes_grid/scatter_hist.html
> attached is the result with out the aspect change.
> also attached is the result with aspect change attempt.
> here is the code that produces the result above:
> import numpy as np
> import tables
> from matplotlib.pyplot import *
> import matplotlib as mpl
> import matplotlib.cm as cm
>
>
> fig = figure(figsize=[12.5,7.5])
> from mpl_toolkits.axes_grid import make_axes_locatable
> #get 3D array from hdf5 file
> a =
> tables.openFile("/Users/magoo/vorpal-data-2/unl-1mm-3d_ElecMultiField_25.h5")
> b = a.root.ElecMultiField[ : , : , : ,1]
> ax = fig.add_subplot(111)
> ax.set_autoscale_on(False)
> divider = make_axes_locatable(ax)
> axLOutx = divider.new_vertical(1, pad=0.3, sharex=ax)
> fig.add_axes(axLOutx)
> #plot line above
> axLOutx.plot(b[365,:,75])
> axLOutx.set_xlim( (0,145))
> axLOuty = divider.new_horizontal(2, pad=0.5, sharey=ax)
> fig.add_axes(axLOuty)
> #plot line on right
> yarr = np.arange(0, np.shape(b[:, 75, 75])[0], 1)
> axLOuty.plot(b[:,75,75], yarr)
> axLOuty.set_ylim( (769,0))
> # plot image/2D array
> im = ax.imshow(b[:,:,75], extent=[0,145,769,0],cmap=cm.jet)  # when I add
> (aspect = .5) as another argument I get what is shown in the second attached
> image
> cb = colorbar(im, fraction=0.015)
>
> plt.draw()
> plt.show()
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi,
I am trying to use matplotlib to visually explore certain different
representation of images. I have the core functionality done. This allows to
explore one image that appears on two subplots w/ the possibility to highlight
regions on either subplot and see the corresponding one on the other. 
What I have left to do is to provide some mean to select the image one wants to
explore. I tried to follow some advice given on this list, but it seems gui
dialogs (file selection in this case) don't get along well with the thread
tricks done by ipython to maintain interactivity while using matplotlib (ipython
started w/ -gthread or -pylab option). If I start ipython without options, the
dialogs do respond, but then I loose the ipython shell. Am I trying to do
something out of normal with matplotlib? I would appreciate any advice or
pointers that would allow me overcome these limitations.


Jorge

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 Thu, 23 Jul 2009 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.

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
>
>

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

Nils Wagner wrote:
> Hi all,
>
> I am confused by the build requirements for matplotlib.
> I cannot find freetype 1.4
>
> http://matplotlib.sourceforge.net/users/installing.html
>
> The latest version is freetype 1.3.1
>
>   http://sourceforge.net/projects/freetype/files/
>
> Any comments ?
>
>             Nils
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Hi all,

I am confused by the build requirements for matplotlib.
I cannot find freetype 1.4

http://matplotlib.sourceforge.net/users/installing.html

The latest version is freetype 1.3.1

  http://sourceforge.net/projects/freetype/files/

Any comments ?

            Nils

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

On Wed, Jul 22, 2009 at 6:36 AM, Alexander Baker
<bak...@gm...>wrote:

>
>
> Ralph,
>
> Perhaps time to migrate to Chaco API from Enthought? not sure if there is
> Ubuntu support yet however.


Alex, I assume you did not mean to send this to the list...

Anyway, matplotlib is a central part of my application and is not going
anywhere. The next step to try to fix this issue is compiling from trunk and
seeing if anything changes. Unfortunately I do not have too much time at the
moment so it may take a while to find the problem.

Cheers,
Ralf


>
> Alex Baker
>
> http://code.enthought.com/chaco/
>
>
> Ralf Gommers-2 wrote:
> >
> > Hi,
> >
> > I am working on a PyQt4 application with some embedded MPL figures, and
> am
> > also trying to save some figures as png's without displaying them. I am
> > observing huge memory increases (10s or 100s of Mb) the moment I try to
> > save
> > a png. I reproduced the issue by combining two mpl examples,
> >
> http://matplotlib.sourceforge.net/examples/user_interfaces/embedding_in_qt4.htmland
> > http://matplotlib.sourceforge.net/examples/api/agg_oo.html. Full code is
> > attached. When pressing the "save figure" button, memory usage shoots up,
> > multiple clicks keep sending it higher (although not monotonically).
>
>

 <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. That's why I saw nothing for the fourth region when I was
actually passing the add_collection() method a valid PolyCollection. I'll keep
on looking... but why the fourth?

Jorge

I'm not able to reproduce this problem here.  Can you provide a 
standalone script that illustrates it?  Also, what version of matplotlib 
are you using?

Mike

Barnette, Daniel W wrote:
> I've written a python gui to matplotlib which allows the user to plot either cartesian, semi-log, or log-log plots. Log plots can be generated for typical base values except for base 2. Is this a bug, or is there some reason that matplotlib does not do log plots using base 2?
>
> Using base 2, the log-log plot error is:
>
> ------ begin snippet -----
> Exception in Tkinter callback
> Traceback (most recent call last):
>   File "C:\python251_102507\lib\lib-tk\Tkinter.py", line 1403, in __call__
>     return self.func(*args)
>   File "C:\python251_102507\lib\site-packages\matplotlib\backends\backend_tkagg.
> py", line 211, in resize
>     self.show()
>   File "C:\python251_102507\lib\site-packages\matplotlib\backends\backend_tkagg.
> py", line 214, in draw
>     FigureCanvasAgg.draw(self)
>   File "C:\python251_102507\lib\site-packages\matplotlib\backends\backend_agg.py
> ", line 261, in draw
>     self.figure.draw(self.renderer)
>   File "C:\python251_102507\lib\site-packages\matplotlib\figure.py", line 759, i
> n draw
>     for a in self.axes: a.draw(renderer)
>   File "C:\python251_102507\lib\site-packages\matplotlib\axes.py", line 1523, in
>  draw
>     a.draw(renderer)
>   File "C:\python251_102507\lib\site-packages\matplotlib\axis.py", line 712, in
> draw
>     for tick, loc, label in self.iter_ticks():
>   File "C:\python251_102507\lib\site-packages\matplotlib\axis.py", line 659, in
> iter_ticks
>     minorLocs = self.minor.locator()
>   File "C:\python251_102507\lib\site-packages\matplotlib\ticker.py", line 1026,
> in __call__
>     if len(subs) > 1 or subs[0] != 1.0:
> IndexError: index out of bounds
>
> ----- end snippet -----
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>   

-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

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. I have a 
script for visualizing certain aspects of images, built upon many bits 
and pieces I found on the matplotlib example section. It basically lets 
me view an image from two different perspectives, that is, its usual 
representation and another one, for example a scatter plot of red versus 
green. That part is working, but I added later on the possibility to 
select a group of points in either representation and see them 
highlighted in both with the same color. That part works OK, up to the 
third selected region, but when I select the fourth something strange 
happens, as I don't see this region in any of the subplots. I represent 
the regions as collections, and add them to subplot with 
add_collection() method. The collections themselves are created ok, and 
the get_children() method even report having them, but they are not 
visible. What surprises me the most is that it is always the fourth 
selected region the one showing this problem, no matter how big or small 
are the previous ones.I tried to make a scaled down version of the 
script exhibiting the problem, but it works ok then. I could post the 
code here, but then I'll force you to go through a 300 lines script. How 
do you go about debugging these sort of problems?
As a side note, the doc tells that add_collection() returns the 
collection, when it actually returns a NoneType object.
BTW, I am using the gtk backend, ipython is started with ipython 
-gthread -pylab. Matplotlib version is 0.98.5.3

Regards,

Jorge

Denis-B wrote:
> Robert C, Robert K, folks,
>
>   messing with the nice delaunay/testfuncs.py to time
> linear_interpolate_grid nn_interpolate_grid and nn_interpolate_unstructured
> in _delaunay, I see linear ~ 100 times faster than the nn_ s:
>
> # from: trigrid Ntri=1000 Ngrid=100  run: 21 Jul 2009 17:33  mac 10.4.11 ppc
>
> time: 0.027 sec trigrid: build Triangulation 1000
> time: 0.0059 sec trigrid 100 "linear"  corners: 0 1 2 1
> time: 0.5 sec trigrid 100 "nn_grid"  corners: 0 1 2 1
> time: 0.49 sec trigrid 100 "nn_unstruct"  corners: 0 1 2 1
>
> Correct me: if all 3 methods do gridpoint-to-triangle in the same way, 
> then the huge diff is in find-neighboring-triangles (6 on average ?), not in
> gridpoint-to-triangle ?
>
> This is with the _delaunay.so that comes with the mac 98.5.3 egg,
> however that was compiled (-O3 ?)
>
>
> What to do ?
>
> 1) does it matter, how many people care ? (all who believe in telekinesis,
> raise my right hand)
>
> 2) natgrid ? don't see it in matplotlib.sf.net
>
> 3) stick with fast linear, smooth the triangle planes a la 3t^2 - 2t^3  or
> fancier smoothing
>
> In any case, add griddata( ... method = "linear" / "nn" ... ) so users have
> a choice.
>   

Denis:  I have added an 'interp' keyword to griddata (svn revision 7287) 
so you can choose the faster linear interpolation with interp='linear'.  
However, for linear interpolation the output grid is assumed to be 
regular with constant dx and dy (and this is *not* checked for by griddata).

The natgrid toolkit is on the sf site under 'Files', then 
'matplotlib-toolkits'.  It is in fact slower than the Delaunay package 
included in matplotlib, but a little bit more robust for pathological cases.

-Jeff
> Can a real user or two tell us about the flow,
> with some rough numbers for Ntri Ngrid Npix --
>     Ntri = nr original sample points, say 1000
>     Ngrid 100 x 100
>     Npix 800 x 600 ?
> (Ntri -> Ngrid slowly and accurately,
> then Ngrid -> Npix w fast inaccurate image interpolation ? hmm.)
>
> cheers
>   -- denis
>
>   

2009/7/23 Angus McMorland <am...@gm...>:
> 2009/7/23 Nicolas <nic...@gm...>:
>> Hi all
>>
>> I was wondering if anyone managed to find / install Basemap on a i386
>> machine running ubuntu 9.04 (Jaunty Jackalope) ...
>>
>> I've installed the debs through synaptic, and I've tried without
>> success to compile
>> Basemap (0.99), with failure at the libgeos compilation. Trying to
>> install "old" .deb (python-basemap_0.99-0ads1_i386.deb) complains
>> about python 2.6
>>
>> do I have to redo all the installation (numpy etc) using an older python (2.5) ?
>
> No. I have basemap 0.99.3 working with python 2.6 under Jaunty. What's
> the compilation error you're getting? I can't immediately remember how
> I did it (although it was not that long ago), but we can rework it
> out.

Found it, I think. I followed some instructions here [1], which are
copied below:

$ sudo apt-get install python-matplotlib python-numpy libgeos-dev
python-httplib2 python-imaging python-dev
$ tar xvfz basemap-0.99.2.tar.gz
$ cd basemap-0.99.2/
$ sudo checkinstall sudo python setup.py install

I hope that helps,

Angus.
-- 
AJC McMorland
Post-doctoral research fellow
Neurobiology, University of Pittsburgh

2009/7/23 Nicolas <nic...@gm...>:
> Hi all
>
> I was wondering if anyone managed to find / install Basemap on a i386
> machine running ubuntu 9.04 (Jaunty Jackalope) ...
>
> I've installed the debs through synaptic, and I've tried without
> success to compile
> Basemap (0.99), with failure at the libgeos compilation. Trying to
> install "old" .deb (python-basemap_0.99-0ads1_i386.deb) complains
> about python 2.6
>
> do I have to redo all the installation (numpy etc) using an older python (2.5) ?

No. I have basemap 0.99.3 working with python 2.6 under Jaunty. What's
the compilation error you're getting? I can't immediately remember how
I did it (although it was not that long ago), but we can rework it
out.

Angus.
-- 
AJC McMorland
Post-doctoral research fellow
Neurobiology, University of Pittsburgh

Hi all

I was wondering if anyone managed to find / install Basemap on a i386
machine running ubuntu 9.04 (Jaunty Jackalope) ...

I've installed the debs through synaptic, and I've tried without
success to compile
Basemap (0.99), with failure at the libgeos compilation. Trying to
install "old" .deb (python-basemap_0.99-0ads1_i386.deb) complains
about python 2.6

do I have to redo all the installation (numpy etc) using an older python (2.5) ?

thanks for any advice


-- 
_/\/¯¯¯¯¯¯\/\_ 33º49'45.24"S & 18º28'45.60"E
Dr. Nicolas Fauchereau
Senior Researcher
CSIR - NRE
Research Group: Ocean systems and climate
15 Lower Hope street, Rosebank 7700
South Africa
_/\/¯¯¯¯¯¯\/\_ 33º49'45.24"S & 18º28'45.60"E

-- 
_/\/¯¯¯¯¯¯\/\_ 33º49'45.24"S & 18º28'45.60"E
Dr. Nicolas Fauchereau
Senior Researcher
CSIR - NRE
Research Group: Ocean systems and climate
15 Lower Hope street, Rosebank 7700
South Africa
_/\/¯¯¯¯¯¯\/\_ 33º49'45.24"S & 18º28'45.60"E