matplotlib-users Mailing List for matplotlib (Page 2)

Hi,

I have been using the event "draw_event" for a while with the old matplotlib 0.8. I have tested my program with newer versions but it seems the function connected to "draw_event" is never called.

You can find an example of this there: https://gist.github.com/1901504

With an old version the image color scale is rescaled when you zoom in. With matplotlib 1.x, no change is made on on the color scale.

Have I missed something?

Thanks in advance for your help.

Antoine

On Tue, Feb 28, 2012 at 12:45 PM, Federico Ariza
<ari...@gm...>wrote:

> Hello everybody
>
> This is my first post to the list.
>

Welcome.

>
> To the point.
> I want to access the all the axes located  where a mouse event occurred.
>
> My first try is with button_release_event
> The event will include inaxes, so I know the axes where the mouse event
> occurred.
> This is fine if at that location I have only one axes.
>
> If I have a twinx or twiny I only get the axes with the biggest zorder.
>
> The example:
>
> import matplotlib.pyplot as plt
> fig = plt.figure()
> ax = fig.add_subplot(111)
> ax.plot(range(100),range(100))
> ax1 = ax.twinx()
> plt.show()
>


You can get all the x-axes shares with "ax1" (not including ax1) with the
following:

    sharedx = [ax for ax in ax1.get_shared_x_axes().get_siblings(ax1) if ax
is not ax1]

sharedx is a list of axes who share the x-axis with ax1



>
> The question
> Having either ax or ax1 is it possible to find the other?
> In other words, from a given axes instance, is it possible to know which
> other axes
> "share" the same xaxis or yaxis?

In article 
<CAC...@ma...>,
 William Jennings <wil...@gm...> 
 wrote:

>  Hello mat plot lib users!
> I feel quite embarrassed that I've gone through 2 days of trying to get to
> get numpy, scipy and matplotlib all to work nice with each other. I've
> scraped through forums, stackoverflow and all the links that can bide me
> some type of logic. Yet, alas I still fail wildly with this set of errors:
> 
> *my current status is: just did a fresh install of my lion os and haven't
> installed Xcode yet. I'm a little lost and have found only macports,
> homebrew guides online only to be a slower failure. I really need to use
> this software but I'm finding it difficult keeping straight what order and
> what I need to install. 

I recommend:
- Install python.org 64-bit Python 2.7 (the one labelled as being for 
MacOS X 10.6 and later)
- Install numpy, scipy and matplotlib Mac binary with "macosx10.6" in 
their names. These are available from the web sites maintained by those 
projects.

Or if you want better backward compatibility (e.g. if you plan to 
distribute applications) then instead you should use the 32-bit 
python.org python (marked as for MacOS X 10.3 and later) and the numpy, 
scipy and matplotlib Mac binary installers with "macosx10.3" in their 
names.

-- Russell

Am Di 28 Feb 2012 19:23:14 CET schrieb Eric Firing:
> On 02/28/2012 08:08 AM, Andreas H. wrote:
>> Am 28.02.2012 18:56, schrieb Eric Firing:
>>> On 02/28/2012 06:28 AM, Andreas H. wrote:
>>>>>> On Tuesday, February 28, 2012, Andreas H. wrote:
>>>>>>
>>>>>>> Good morning,
>>>>>>>
>>>>>>> I'm creating the attached plot using pcolormesh(). What I would like to
>>>>>>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>>>>>>
>>>>>>> The problem is that when I use contour(), the lines drawn do not follow
>>>>>>> the grid edges but seem to be interpolated somehow.
>>>>>>>
>>>>>>> Do you have an idea how to draw the contour lines following the grid
>>>>>>> edges?
>>>>>>>
>>>>>>> Your insight is very much appreciated :)
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Andreas.
>>>>>>>
>>>>>>
>>>>>> This is because of a subtle difference in how pcolor-like functions and
>>>>>> contour-like functions work.  I always forget which is which, but one
>>>>>> assumes that the z value lies on the vertices of the grid while the
>>>>>> other
>>>>>> assumes that it lies in the middle of each grid point.  This is why you
>>>>>> see
>>>>>> them slightly offset from each other.
>>>>>
>>>>> Thanks, Ben!
>>>>>
>>>>> To `pcolormesh`, I pass the *edges* of the grid:
>>>>>
>>>>>       xbin = linspace(0, 12, nxbin + 1)
>>>>>       ybin = np.linspace(-90, 90, nybin + 1)
>>>>>
>>>>>       pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
>>>>>                       vmin=-5, vmax=20)
>>>>>
>>>>> `contour`, however, wants the coordinates themselves. So I do
>>>>>
>>>>>       spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
>>>>> [-2.5, 2.5])
>>>>>
>>>>> Still, the outcome is, well, unexpected to me. Actually, no matter if
>>>>> contour wants centres or edges, the actual behaviour seems strange. There
>>>>> is some interpolation going on, apparently. The input `pdata` has shape
>>>>> (12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
>>>>> movement in the x-direction.
>>>>>
>>>>> Any ideas?
>>>>
>>>> Okay, after some diving into matplotlib sources, I guess the interpolation
>>>> comes within the function `QuadContourSet._get_allsegs_and_allkinds`. So
>>>> there seems to be no way to accomplish what I actually want with the
>>>> current matplotlib API. Correct?
>>>>
>>>> If I wanted to do something about this, I would need to
>>>>
>>>> * implement a class `GriddedContourSet`, derived from `ContourSet`, where
>>>> I implement the `_get_allsegs_and_allkinds` method appropriately.
>>>> * add an additional keyword argument to `contour()` to make this gridded
>>>> contourset an option when calling `contour()`.
>>>>
>>>> Is this all correct? If yes, I might start working on this if I get the
>>>> time ...
>>>
>>> It is not at all clear to me what you want to do, as compared to what
>>> contour does.  Can you illustrate with an extremely simple example?
>>> Maybe even a scanned sketch, if necessary? Do you want the contour lines
>>> to be stepped, like the rectilinear boundaries of the pcolormesh
>>> cells--that is, composed entirely of horizontal and vertical line segments?
>>
>> Yes, Eric, that's exactly what I want. Since my case was simple enough,
>> I did it completely manually, with loads of calls to `plot` (I'm sure
>> there would've been a simpler solution ... -- which one?). I attached
>> the plot so you get an idea of what I want to do.
>
> Andreas,
>
> I have never seen a contour algorithm with an option to do that, but I 
> understand the motivation.  I don't think it would be easy to implement; 
> contouring algorithms generally are not.
>
> You might get an adequate approximation by using nearest-neighbor 
> interpolation to interpolate your data to a very fine grid, and then 
> contour that.

Eric,

thanks, that's a good hint. I took a look into the C source of the 
contour algorithm and decided not to bother right now. But your 
suggestion should do it.

Cheers,
Andreas.

Hello everybody

This is my first post to the list.

To the point.
I want to access the all the axes located  where a mouse event occurred.

My first try is with button_release_event
The event will include inaxes, so I know the axes where the mouse event
occurred.
This is fine if at that location I have only one axes.

If I have a twinx or twiny I only get the axes with the biggest zorder.

The example:

import matplotlib.pyplot as plt
fig = plt.figure()
ax = fig.add_subplot(111)
ax.plot(range(100),range(100))
ax1 = ax.twinx()
plt.show()

The question
Having either ax or ax1 is it possible to find the other?
In other words, from a given axes instance, is it possible to know which
other axes
"share" the same xaxis or yaxis?


Thanks
Federico


-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

On 02/28/2012 08:08 AM, Andreas H. wrote:
> Am 28.02.2012 18:56, schrieb Eric Firing:
>> On 02/28/2012 06:28 AM, Andreas H. wrote:
>>>>> On Tuesday, February 28, 2012, Andreas H. wrote:
>>>>>
>>>>>> Good morning,
>>>>>>
>>>>>> I'm creating the attached plot using pcolormesh(). What I would like to
>>>>>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>>>>>
>>>>>> The problem is that when I use contour(), the lines drawn do not follow
>>>>>> the grid edges but seem to be interpolated somehow.
>>>>>>
>>>>>> Do you have an idea how to draw the contour lines following the grid
>>>>>> edges?
>>>>>>
>>>>>> Your insight is very much appreciated :)
>>>>>>
>>>>>> Cheers,
>>>>>> Andreas.
>>>>>>
>>>>>
>>>>> This is because of a subtle difference in how pcolor-like functions and
>>>>> contour-like functions work.  I always forget which is which, but one
>>>>> assumes that the z value lies on the vertices of the grid while the
>>>>> other
>>>>> assumes that it lies in the middle of each grid point.  This is why you
>>>>> see
>>>>> them slightly offset from each other.
>>>>
>>>> Thanks, Ben!
>>>>
>>>> To `pcolormesh`, I pass the *edges* of the grid:
>>>>
>>>>       xbin = linspace(0, 12, nxbin + 1)
>>>>       ybin = np.linspace(-90, 90, nybin + 1)
>>>>
>>>>       pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
>>>>                       vmin=-5, vmax=20)
>>>>
>>>> `contour`, however, wants the coordinates themselves. So I do
>>>>
>>>>       spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
>>>> [-2.5, 2.5])
>>>>
>>>> Still, the outcome is, well, unexpected to me. Actually, no matter if
>>>> contour wants centres or edges, the actual behaviour seems strange. There
>>>> is some interpolation going on, apparently. The input `pdata` has shape
>>>> (12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
>>>> movement in the x-direction.
>>>>
>>>> Any ideas?
>>>
>>> Okay, after some diving into matplotlib sources, I guess the interpolation
>>> comes within the function `QuadContourSet._get_allsegs_and_allkinds`. So
>>> there seems to be no way to accomplish what I actually want with the
>>> current matplotlib API. Correct?
>>>
>>> If I wanted to do something about this, I would need to
>>>
>>> * implement a class `GriddedContourSet`, derived from `ContourSet`, where
>>> I implement the `_get_allsegs_and_allkinds` method appropriately.
>>> * add an additional keyword argument to `contour()` to make this gridded
>>> contourset an option when calling `contour()`.
>>>
>>> Is this all correct? If yes, I might start working on this if I get the
>>> time ...
>>
>> It is not at all clear to me what you want to do, as compared to what
>> contour does.  Can you illustrate with an extremely simple example?
>> Maybe even a scanned sketch, if necessary? Do you want the contour lines
>> to be stepped, like the rectilinear boundaries of the pcolormesh
>> cells--that is, composed entirely of horizontal and vertical line segments?
>
> Yes, Eric, that's exactly what I want. Since my case was simple enough,
> I did it completely manually, with loads of calls to `plot` (I'm sure
> there would've been a simpler solution ... -- which one?). I attached
> the plot so you get an idea of what I want to do.

Andreas,

I have never seen a contour algorithm with an option to do that, but I 
understand the motivation.  I don't think it would be easy to implement; 
contouring algorithms generally are not.

You might get an adequate approximation by using nearest-neighbor 
interpolation to interpolate your data to a very fine grid, and then 
contour that.

Eric

>
> Thanks for your help!
> Andreas.
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Am 28.02.2012 18:56, schrieb Eric Firing:
> On 02/28/2012 06:28 AM, Andreas H. wrote:
>>>> On Tuesday, February 28, 2012, Andreas H. wrote:
>>>>
>>>>> Good morning,
>>>>>
>>>>> I'm creating the attached plot using pcolormesh(). What I would like to
>>>>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>>>>
>>>>> The problem is that when I use contour(), the lines drawn do not follow
>>>>> the grid edges but seem to be interpolated somehow.
>>>>>
>>>>> Do you have an idea how to draw the contour lines following the grid
>>>>> edges?
>>>>>
>>>>> Your insight is very much appreciated :)
>>>>>
>>>>> Cheers,
>>>>> Andreas.
>>>>>
>>>>
>>>> This is because of a subtle difference in how pcolor-like functions and
>>>> contour-like functions work.  I always forget which is which, but one
>>>> assumes that the z value lies on the vertices of the grid while the
>>>> other
>>>> assumes that it lies in the middle of each grid point.  This is why you
>>>> see
>>>> them slightly offset from each other.
>>>
>>> Thanks, Ben!
>>>
>>> To `pcolormesh`, I pass the *edges* of the grid:
>>>
>>>      xbin = linspace(0, 12, nxbin + 1)
>>>      ybin = np.linspace(-90, 90, nybin + 1)
>>>
>>>      pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
>>>                      vmin=-5, vmax=20)
>>>
>>> `contour`, however, wants the coordinates themselves. So I do
>>>
>>>      spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
>>> [-2.5, 2.5])
>>>
>>> Still, the outcome is, well, unexpected to me. Actually, no matter if
>>> contour wants centres or edges, the actual behaviour seems strange. There
>>> is some interpolation going on, apparently. The input `pdata` has shape
>>> (12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
>>> movement in the x-direction.
>>>
>>> Any ideas?
>>
>> Okay, after some diving into matplotlib sources, I guess the interpolation
>> comes within the function `QuadContourSet._get_allsegs_and_allkinds`. So
>> there seems to be no way to accomplish what I actually want with the
>> current matplotlib API. Correct?
>>
>> If I wanted to do something about this, I would need to
>>
>> * implement a class `GriddedContourSet`, derived from `ContourSet`, where
>> I implement the `_get_allsegs_and_allkinds` method appropriately.
>> * add an additional keyword argument to `contour()` to make this gridded
>> contourset an option when calling `contour()`.
>>
>> Is this all correct? If yes, I might start working on this if I get the
>> time ...
> 
> It is not at all clear to me what you want to do, as compared to what 
> contour does.  Can you illustrate with an extremely simple example? 
> Maybe even a scanned sketch, if necessary? Do you want the contour lines 
> to be stepped, like the rectilinear boundaries of the pcolormesh 
> cells--that is, composed entirely of horizontal and vertical line segments?

Yes, Eric, that's exactly what I want. Since my case was simple enough,
I did it completely manually, with loads of calls to `plot` (I'm sure
there would've been a simpler solution ... -- which one?). I attached
the plot so you get an idea of what I want to do.

Thanks for your help!
Andreas.

On 02/28/2012 06:28 AM, Andreas H. wrote:
>>> On Tuesday, February 28, 2012, Andreas H. wrote:
>>>
>>>> Good morning,
>>>>
>>>> I'm creating the attached plot using pcolormesh(). What I would like to
>>>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>>>
>>>> The problem is that when I use contour(), the lines drawn do not follow
>>>> the grid edges but seem to be interpolated somehow.
>>>>
>>>> Do you have an idea how to draw the contour lines following the grid
>>>> edges?
>>>>
>>>> Your insight is very much appreciated :)
>>>>
>>>> Cheers,
>>>> Andreas.
>>>>
>>>
>>> This is because of a subtle difference in how pcolor-like functions and
>>> contour-like functions work.  I always forget which is which, but one
>>> assumes that the z value lies on the vertices of the grid while the
>>> other
>>> assumes that it lies in the middle of each grid point.  This is why you
>>> see
>>> them slightly offset from each other.
>>
>> Thanks, Ben!
>>
>> To `pcolormesh`, I pass the *edges* of the grid:
>>
>>      xbin = linspace(0, 12, nxbin + 1)
>>      ybin = np.linspace(-90, 90, nybin + 1)
>>
>>      pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
>>                      vmin=-5, vmax=20)
>>
>> `contour`, however, wants the coordinates themselves. So I do
>>
>>      spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
>> [-2.5, 2.5])
>>
>> Still, the outcome is, well, unexpected to me. Actually, no matter if
>> contour wants centres or edges, the actual behaviour seems strange. There
>> is some interpolation going on, apparently. The input `pdata` has shape
>> (12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
>> movement in the x-direction.
>>
>> Any ideas?
>
> Okay, after some diving into matplotlib sources, I guess the interpolation
> comes within the function `QuadContourSet._get_allsegs_and_allkinds`. So
> there seems to be no way to accomplish what I actually want with the
> current matplotlib API. Correct?
>
> If I wanted to do something about this, I would need to
>
> * implement a class `GriddedContourSet`, derived from `ContourSet`, where
> I implement the `_get_allsegs_and_allkinds` method appropriately.
> * add an additional keyword argument to `contour()` to make this gridded
> contourset an option when calling `contour()`.
>
> Is this all correct? If yes, I might start working on this if I get the
> time ...

It is not at all clear to me what you want to do, as compared to what 
contour does.  Can you illustrate with an extremely simple example? 
Maybe even a scanned sketch, if necessary? Do you want the contour lines 
to be stepped, like the rectilinear boundaries of the pcolormesh 
cells--that is, composed entirely of horizontal and vertical line segments?

Eric

>
> Cheers,
> Andreas.
>
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hello --

When I run the following code (heavily adapted from the matplotlib examples):

...
SCHistogram = Figure(figsize=(6,6), dpi=300, facecolor='w') # 6 inches across (X-axis) by 4 inches tall (Y-axis)
ax = SCHistogram.add_subplot(111)

canvas = FigureCanvas(SCHistogram)

AxisTitleFontProps = FontProperties(size=10, family='serif')
AxisTitleFontProps.set_name('Times')

n, bins, patches = ax.hist(DimensionData)

y = normpdf( bins, self.meanVal, self.stdDev)
line, = ax.plot(bins, y, 'r--')
line.set_linewidth(1)

ax.set_xlabel(self.Description, fontproperties=AxisTitleFontProps)
ax.set_ylabel('Number of Parts' ,fontproperties=AxisTitleFontProps)
ax.set_xlim([x_lowest, x_highest])
ax.plot([self.LCL,self.LCL],[0,max(n)],'b--')
ax.plot([self.Nom,self.Nom],[0,max(n)],'g--')
ax.plot([self.UCL,self.UCL],[0,max(n)],'r--')
.
.
.

AxisTickFontProps = copy.deepcopy(AxisTitleFontProps)
AxisTickFontProps.set_size(7)

canvas.draw()

s = canvas.tostring_rgb()  # save this and convert to bitmap as needed

The following error appears when run under matplotlib 1.1 (the code successfully completes in v1.0.1):

Traceback (most recent call last):
  File "./analyze.pyw", line 681, in fileGenerateReport
    SPC_PDF.Generate()
  File "/Users/engelsma/dev/SPC_Analyzer/trunk/1.0.10/report.py", line 201, in Generate
    eachSC.CreateHistogram(eachSC.TempImgFile)
  File "/Users/engelsma/dev/SPC_Analyzer/trunk/1.0.10/SPCmodules.py", line 318, in CreateHistogram
    s = canvas.tostring_rgb()  # save this and convert to bitmap as needed
  File "/Users/engelsma/.virtualenvs/cmm/lib/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 418, in tostring_rgb
    return self.renderer.tostring_rgb()
AttributeError: 'FigureCanvasQTAgg' object has no attribute 'renderer'

Any ideas as to why this code fails under v1.1? I've checked the changelog and I see nothing that would cause this problem... 

Thanks in advance, 

Dave Engelsma

>> On Tuesday, February 28, 2012, Andreas H. wrote:
>>
>>> Good morning,
>>>
>>> I'm creating the attached plot using pcolormesh(). What I would like to
>>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>>
>>> The problem is that when I use contour(), the lines drawn do not follow
>>> the grid edges but seem to be interpolated somehow.
>>>
>>> Do you have an idea how to draw the contour lines following the grid
>>> edges?
>>>
>>> Your insight is very much appreciated :)
>>>
>>> Cheers,
>>> Andreas.
>>>
>>
>> This is because of a subtle difference in how pcolor-like functions and
>> contour-like functions work.  I always forget which is which, but one
>> assumes that the z value lies on the vertices of the grid while the
>> other
>> assumes that it lies in the middle of each grid point.  This is why you
>> see
>> them slightly offset from each other.
>
> Thanks, Ben!
>
> To `pcolormesh`, I pass the *edges* of the grid:
>
>     xbin = linspace(0, 12, nxbin + 1)
>     ybin = np.linspace(-90, 90, nybin + 1)
>
>     pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
>                     vmin=-5, vmax=20)
>
> `contour`, however, wants the coordinates themselves. So I do
>
>     spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
> [-2.5, 2.5])
>
> Still, the outcome is, well, unexpected to me. Actually, no matter if
> contour wants centres or edges, the actual behaviour seems strange. There
> is some interpolation going on, apparently. The input `pdata` has shape
> (12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
> movement in the x-direction.
>
> Any ideas?

Okay, after some diving into matplotlib sources, I guess the interpolation
comes within the function `QuadContourSet._get_allsegs_and_allkinds`. So
there seems to be no way to accomplish what I actually want with the
current matplotlib API. Correct?

If I wanted to do something about this, I would need to

* implement a class `GriddedContourSet`, derived from `ContourSet`, where
I implement the `_get_allsegs_and_allkinds` method appropriately.
* add an additional keyword argument to `contour()` to make this gridded
contourset an option when calling `contour()`.

Is this all correct? If yes, I might start working on this if I get the
time ...

Cheers,
Andreas.

> On Tuesday, February 28, 2012, Andreas H. wrote:
>
>> Good morning,
>>
>> I'm creating the attached plot using pcolormesh(). What I would like to
>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>
>> The problem is that when I use contour(), the lines drawn do not follow
>> the grid edges but seem to be interpolated somehow.
>>
>> Do you have an idea how to draw the contour lines following the grid
>> edges?
>>
>> Your insight is very much appreciated :)
>>
>> Cheers,
>> Andreas.
>>
>
> This is because of a subtle difference in how pcolor-like functions and
> contour-like functions work.  I always forget which is which, but one
> assumes that the z value lies on the vertices of the grid while the other
> assumes that it lies in the middle of each grid point.  This is why you
> see
> them slightly offset from each other.

Thanks, Ben!

To `pcolormesh`, I pass the *edges* of the grid:

    xbin = linspace(0, 12, nxbin + 1)
    ybin = np.linspace(-90, 90, nybin + 1)

    pl = spl.pcolormesh(xbin, ybin, pdata.T, cmap=cmap, edgecolors='None',
                    vmin=-5, vmax=20)

`contour`, however, wants the coordinates themselves. So I do

    spl.contour((xbin[:-1]+xbin[1:])/2., (ybin[:-1]+ybin[1:])/2, pdata.T,
[-2.5, 2.5])

Still, the outcome is, well, unexpected to me. Actually, no matter if
contour wants centres or edges, the actual behaviour seems strange. There
is some interpolation going on, apparently. The input `pdata` has shape
(12, 72) (or 72,12), and I definitely wouldn't expect this sub-grid
movement in the x-direction.

Any ideas?

Cheers,
Andreas.

On Tue, Feb 28, 2012 at 9:10 AM, Benjamin Root <ben...@ou...> wrote:
> On Tuesday, February 28, 2012, Andreas H. wrote:
>>
>> Good morning,
>>
>> I'm creating the attached plot using pcolormesh(). What I would like to
>> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>>
>> The problem is that when I use contour(), the lines drawn do not follow
>> the grid edges but seem to be interpolated somehow.
>>
>> Do you have an idea how to draw the contour lines following the grid
>> edges?
>>
>> Your insight is very much appreciated :)
>>
>> Cheers,
>> Andreas.
>
>
> This is because of a subtle difference in how pcolor-like functions and
> contour-like functions work.  I always forget which is which, but one
> assumes that the z value lies on the vertices of the grid while the other
> assumes that it lies in the middle of each grid point.  This is why you see
> them slightly offset from each other.

By definitition, with pcolormesh you're giving it the edges of the
grid cells. In fact, for an NxN grid of data, you should have N+1xN+1
grids of x,y values. Contour is given the actual grid and values.

Ryan

-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tuesday, February 28, 2012, Andreas H. wrote:

> Good morning,
>
> I'm creating the attached plot using pcolormesh(). What I would like to
> do now is draw contour lines at +/- 2.5%, which follow the grid edges.
>
> The problem is that when I use contour(), the lines drawn do not follow
> the grid edges but seem to be interpolated somehow.
>
> Do you have an idea how to draw the contour lines following the grid edges?
>
> Your insight is very much appreciated :)
>
> Cheers,
> Andreas.
>

This is because of a subtle difference in how pcolor-like functions and
contour-like functions work.  I always forget which is which, but one
assumes that the z value lies on the vertices of the grid while the other
assumes that it lies in the middle of each grid point.  This is why you see
them slightly offset from each other.

I hope that clarifies everything for you.

Ben Root

Good morning,

I'm creating the attached plot using pcolormesh(). What I would like to
do now is draw contour lines at +/- 2.5%, which follow the grid edges.

The problem is that when I use contour(), the lines drawn do not follow
the grid edges but seem to be interpolated somehow.

Do you have an idea how to draw the contour lines following the grid edges?

Your insight is very much appreciated :)

Cheers,
Andreas.

On 2012-2-26 4:02, Benjamin Root wrote:
> On Friday, February 24, 2012, fdu...@gm... wrote:
>
>> Dear Ben Root,
>>
>> I have made a pull request of matplotlib on github, and I put my venn
>> function on https://github.com/icetime/**matplotlib/blob/master/lib/**
>> matplotlib/venn.py<https://github.com/icetime/matplotlib/blob/master/lib/matplotlib/venn.py>.
>> However, I'm not sure it is the right place venn.py should go.
>>
>> This is my first time try to contribute to an open source project. Could
>> someone please help review the code? Any comments will be greatly
>> appreciated.Thanks.
>>
>> Regards,
>> Jianfeng
>>
>>
>>
> Jianfeng,
>
> A common mistake new contributors make is that they make a pull request
> against their own mpl fork rather than the official one.  We have not
> received your request yet.  You might want to try again.
>
> Git is confusing at first, but once you try it out a bit more, it becomes
> much easier to use.
>
> Ben Root
>
Dear Ben Root,

Thanks for letting me know. I tried again, and finally made a pull 
request. Please let me know if it works this time. Thanks.

If there is something I can do to improve the code, please just let me 
know, and I will be happy to do it.

Regards,
Jianfeng

On Feb 27, 2012, at 6:16 AM, jonasr <jon...@we...> wrote:

> 
> Hello,
> 
> i am actually trying to plot a vector field over a scalar field, 
> i want to show a vector field on the intervall x=[0,1] y=[0,1]
> this works fine so far, actually i have the problem that if i plot the
> scalarfield
> via imshow() the image geht scaled by the size of the array.
> i.e. if i have a 100x100 array the image is drawn on an [0,100] intervall,
> is there any possibility to bring the image down to an [0,1 ] intevall
> independent of the array size ? 

Take a look at the extent argument to imshow. 

http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.imshow

You want something like extent=[0,1,0,1]

Hello,

i am actually trying to plot a vector field over a scalar field, 
i want to show a vector field on the intervall x=[0,1] y=[0,1]
this works fine so far, actually i have the problem that if i plot the
scalarfield
via imshow() the image geht scaled by the size of the array.
i.e. if i have a 100x100 array the image is drawn on an [0,100] intervall,
is there any possibility to bring the image down to an [0,1 ] intevall
independent of the array size ? 

thanks

-- 
View this message in context: http://old.nabble.com/image-rescale-on-intervall-tp33399314p33399314.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

On 2/26/12 6:42 AM, David Craig wrote:
> Hi, I recently installed basemap and python imaging library on my 
> laptop. I have an i686 machine with fedora 16 on it. I just tried some 
> test plots and basemap seems to work fine but according to the 
> documentation to use the bluemarble(), etopo(), shadedrelief() and 
> warpimage() instance methods I need PIL. SO I installed it via yum,
>
> $ sudo yum install python-imaging.i686
>
> however only the bluemarble method works. If I try any of the others I 
> get the following error.
>
> AttributeError                            Traceback (most recent call 
> last)
> /usr/lib/python2.7/site-packages/IPython/utils/py3compat.pyc in 
> execfile(fname, *where)
>     173             else:
>     174                 filename = fname
> --> 175             __builtin__.execfile(filename, *where)
>
> /home/davcra/Desktop/python_scripts/blue_marble.py in <module>()
>      10
>      11
> ---> 12 m.shadedrelief()
>      13 plt.show()
>
> AttributeError: 'Basemap' object has no attribute 'shadedrelief'
>
> Anyone know what I did wrong????
> Thanks
> David
>
David:  You must not have the latest version of Basemap installed, the 
shadedrelief method was added in 1.0.2.

-Jeff

Hi, I recently installed basemap and python imaging library on my laptop. I
have an i686 machine with fedora 16 on it. I just tried some test plots and
basemap seems to work fine but according to the documentation to use the
bluemarble(), etopo(), shadedrelief() and warpimage() instance methods I
need PIL. SO I installed it via yum,

$ sudo yum install python-imaging.i686

however only the bluemarble method works. If I try any of the others I get
the following error.

AttributeError                            Traceback (most recent call last)
/usr/lib/python2.7/site-packages/IPython/utils/py3compat.pyc in
execfile(fname, *where)
    173             else:
    174                 filename = fname
--> 175             __builtin__.execfile(filename, *where)

/home/davcra/Desktop/python_scripts/blue_marble.py in <module>()
     10
     11
---> 12 m.shadedrelief()
     13 plt.show()

AttributeError: 'Basemap' object has no attribute 'shadedrelief'

Anyone know what I did wrong????
Thanks
David

On 02/26/12 06:25, Eric Firing wrote:
> On 02/25/2012 03:54 AM, Alejandro Dubrovsky wrote:
>> Hi,
>>
>> I've run into something that I expect to be ground well covered but I
>> can't find anything relevant on google.
>>
>> I'm on linux. When using the GtkAgg backend on matplotlib 1.1.0 (or git
>> head for that matter), with interactive mode on, one call to draw() only
>> gives me a blank window, while a second draw() immediately afterwards
>> will draw the requested graph. On IRC, askewchan told me it only one
>> draw is required under MacOSX, and it also works fine with just one draw
>> call if I switch to the TkAgg backend.
> 
> This does not have a simple answer.  The basic problem is a collision 
> between event-driven programming (the gui toolkit) and nice, simple 
> sequential programming such as in your script.  The plotting commands 
> essentially register requests with the gui toolkit, and the toolkit 
> executes them when it gets around to it.  It won't do it during a 
> time.sleep().  Typically, it has to be waiting for input, because that 
> is when the mainloop is checking to see if there is anything that needs 
> to be done.
> 
Ah, good explanation.

>>
>> The following short script should demonstrate the issue (note: this is
>> only a problem when run as a script. It works fine on ipython, or
>> standard python prompt):
>>
> 
> Try removing *all* your "draw" commands, and replace the calls to 
> time.sleep(2) with plt.pause(2).  That works for me on gtkagg, qt4agg, 
> wxagg, and tkagg. plt.pause() calls the event loop while waiting, 
> instead of just freezing everything like sleep() does.
> 
Yes, that works here too. It works even in non-interactive mode. Thank you.

I tried replacing all the draws in my program with plt.pause(0.01), and
it worked fine on GtkAgg, but when I tried it in QtAgg, it went to blank
screen mode. But upping it to 0.05 worked on both. So I went trawling
through code.

pause, through some intermediaries, seems to call flush_events, which
does the interfacing to the corresponding toolkit telling it to process
events, and then calls time.sleep for 0.01 seconds.  It does this until
the total slept time matches or exceeds what you specify.  And it seems
that Qt needs two separate rounds to get everything done. So a call like
plt.pause(0.015) works well

The time.sleep calls from pause seem unnecessary for the people like me
that just want to use pause as a get events processed signals.  It would
be good if flush_events had a direct interface.

(writing this so that maybe it gets picked up by a search engine)

Search for no commitment encounters online. Find hot singles online to hook up.

http://twell.me/3i



























-----
If you would like to not be contacted from us in the future please press on the link below:
http://twell.me/3g

Or write to:
P.O. Box 72, 53 Street, Vancouver, Canada

On 02/25/2012 10:02 AM, Benjamin Root wrote:
>
>
> On Friday, February 24, 2012, fdu...@gm...
> <mailto:fdu...@gm...> wrote:
>
>     Dear Ben Root,
>
>     I have made a pull request of matplotlib on github, and I put my
>     venn function on
>     https://github.com/icetime/__matplotlib/blob/master/lib/__matplotlib/venn.py
>     <https://github.com/icetime/matplotlib/blob/master/lib/matplotlib/venn.py>.
>     However, I'm not sure it is the right place venn.py should go.
>
>     This is my first time try to contribute to an open source project.
>     Could someone please help review the code? Any comments will be
>     greatly appreciated.Thanks.
>
>     Regards,
>     Jianfeng
>
>
>
> Jianfeng,
>
> A common mistake new contributors make is that they make a pull request
> against their own mpl fork rather than the official one.  We have not
> received your request yet.  You might want to try again.
>
> Git is confusing at first, but once you try it out a bit more, it
> becomes much easier to use.
>
> Ben Root
>
Ben,

A first cut would be an answer to the question as to where it belongs: 
mpl core? examples? cookbook?

I don't think it is of sufficiently general usefulness to belong in the 
core, so I think it would be better as an example.  What do you think?

Eric

>
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>
>
>
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Friday, February 24, 2012, fdu...@gm... wrote:

> Dear Ben Root,
>
> I have made a pull request of matplotlib on github, and I put my venn
> function on https://github.com/icetime/**matplotlib/blob/master/lib/**
> matplotlib/venn.py<https://github.com/icetime/matplotlib/blob/master/lib/matplotlib/venn.py>.
> However, I'm not sure it is the right place venn.py should go.
>
> This is my first time try to contribute to an open source project. Could
> someone please help review the code? Any comments will be greatly
> appreciated.Thanks.
>
> Regards,
> Jianfeng
>
>
>
Jianfeng,

A common mistake new contributors make is that they make a pull request
against their own mpl fork rather than the official one.  We have not
received your request yet.  You might want to try again.

Git is confusing at first, but once you try it out a bit more, it becomes
much easier to use.

Ben Root

On 02/25/2012 03:54 AM, Alejandro Dubrovsky wrote:
> Hi,
>
> I've run into something that I expect to be ground well covered but I
> can't find anything relevant on google.
>
> I'm on linux. When using the GtkAgg backend on matplotlib 1.1.0 (or git
> head for that matter), with interactive mode on, one call to draw() only
> gives me a blank window, while a second draw() immediately afterwards
> will draw the requested graph. On IRC, askewchan told me it only one
> draw is required under MacOSX, and it also works fine with just one draw
> call if I switch to the TkAgg backend.

This does not have a simple answer.  The basic problem is a collision 
between event-driven programming (the gui toolkit) and nice, simple 
sequential programming such as in your script.  The plotting commands 
essentially register requests with the gui toolkit, and the toolkit 
executes them when it gets around to it.  It won't do it during a 
time.sleep().  Typically, it has to be waiting for input, because that 
is when the mainloop is checking to see if there is anything that needs 
to be done.

>
> The following short script should demonstrate the issue (note: this is
> only a problem when run as a script. It works fine on ipython, or
> standard python prompt):
>

Try removing *all* your "draw" commands, and replace the calls to 
time.sleep(2) with plt.pause(2).  That works for me on gtkagg, qt4agg, 
wxagg, and tkagg. plt.pause() calls the event loop while waiting, 
instead of just freezing everything like sleep() does.

Eric

> ---
> import time
> from matplotlib import pyplot as plt
>
> def graph():
>
> 	plt.ion()
>
> 	plt.plot(range(10), range(10,20))
> 	plt.draw()
> 	plt.draw()  # blank screen if this omitted
> 	time.sleep(2)
> 	plt.plot(range(30,40), range(10,20))
> 	plt.draw()
> 	plt.draw()  # second line not drawn if this omitted
> 	time.sleep(2)
>
> 	plt.ioff()
>
> graph()
> ---
>
> backend GTKAgg version 2.24.0
> As a different but most likely related issue, th Qt4Agg backend doesn't
> work even with two draw calls.
>
> Is this a known issue? Is the script not using matplotlib as expected?
> If so, is running a separate thread the intended way of showing graphs
> in a non-blocking way?
>
> Thanks,
> alejandro
>
> ------------------------------------------------------------------------------
> Virtualization&  Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Hi,

I've run into something that I expect to be ground well covered but I
can't find anything relevant on google.

I'm on linux. When using the GtkAgg backend on matplotlib 1.1.0 (or git
head for that matter), with interactive mode on, one call to draw() only
gives me a blank window, while a second draw() immediately afterwards
will draw the requested graph. On IRC, askewchan told me it only one
draw is required under MacOSX, and it also works fine with just one draw
call if I switch to the TkAgg backend.

The following short script should demonstrate the issue (note: this is
only a problem when run as a script. It works fine on ipython, or
standard python prompt):

---
import time
from matplotlib import pyplot as plt

def graph():

	plt.ion()

	plt.plot(range(10), range(10,20))
	plt.draw()
	plt.draw()  # blank screen if this omitted
	time.sleep(2)
	plt.plot(range(30,40), range(10,20))
	plt.draw()
	plt.draw()  # second line not drawn if this omitted
	time.sleep(2)

	plt.ioff()

graph()
---

backend GTKAgg version 2.24.0
As a different but most likely related issue, th Qt4Agg backend doesn't
work even with two draw calls.

Is this a known issue? Is the script not using matplotlib as expected?
If so, is running a separate thread the intended way of showing graphs
in a non-blocking way?

Thanks,
alejandro