matplotlib-users Mailing List for matplotlib (Page 4)

Would it be workable for the default to be proportional to the size of the array passed in? (suggested only because I do that myself, when deciding how coarse an investigative plot I can get away with.) 

&C


On Dec 11, 2012, at 9:28 AM, Benjamin Root wrote:

> 
> 
> On Tue, Dec 11, 2012 at 12:17 PM, Ethan Gutmann <eth...@gm...> wrote:
> > This is because the default rstride and cstride arguments is 10, IIRC.  Since your array is only 12x12, the surface plotting is barely plotting anything.  Try calling:
> >
> > ax.plot_surface(x, y, a, rstride=1, cstride=1)
> 
> 
> You know, this has tripped me up a few times too.  I don't use plot_surface often enough to always remember this, and it is not the first parameter I think to check when debugging a program.  Is there a reason the default rstride and cstride aren't 1 other than possible memory constraints for large arrays?
> 
> I suppose changing the defaults might break programs that rely on this behavior, but if this API ever gets revamped, consider this a request to make 1 be the default instead.  I would think that the default should be that the obvious command "just works" while plots that may require too much memory can be tweaked to work faster (I'm assuming that is the reason for the default of 10).
> 
> 
> I actually don't know the reason for the defaults (I didn't create mplot3d), but that has always been my suspicion.  There is an existing PR to change the default behavior to be somewhat "automatic".  At the time, I wasn't really in favor of it, but when looked in this light, it does make some more sense.
> 
> I'll have to think about this a bit more.
> Ben Root
> 
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

On Tue, Dec 11, 2012 at 2:08 PM, Chloe Lewis <ch...@be...> wrote:

> Would it be workable for the default to be proportional to the size of the
> array passed in? (suggested only because I do that myself, when deciding
> how coarse an investigative plot I can get away with.)
>
> &C
>
>
That is pretty much what the PR I was referring to does:

https://github.com/matplotlib/matplotlib/pull/1040

It makes it so that the behavior of both plot_surface and plot_wireframe is
the same in this respect.  So, by default, the rstride and cstride would be
1% of the size of your data array.  This would make the default for the
recent example be 1, therefore showing every point.  I wonder if a
logarithmic default would make sense to better handle large data arrays?

Thoughts?
Ben Root

On Tue, Dec 11, 2012 at 12:17 PM, Ethan Gutmann <eth...@gm...>wrote:

> > This is because the default rstride and cstride arguments is 10, IIRC.
>  Since your array is only 12x12, the surface plotting is barely plotting
> anything.  Try calling:
> >
> > ax.plot_surface(x, y, a, rstride=1, cstride=1)
>
>
> You know, this has tripped me up a few times too.  I don't use
> plot_surface often enough to always remember this, and it is not the first
> parameter I think to check when debugging a program.  Is there a reason the
> default rstride and cstride aren't 1 other than possible memory constraints
> for large arrays?
>
> I suppose changing the defaults might break programs that rely on this
> behavior, but if this API ever gets revamped, consider this a request to
> make 1 be the default instead.  I would think that the default should be
> that the obvious command "just works" while plots that may require too much
> memory can be tweaked to work faster (I'm assuming that is the reason for
> the default of 10).
>
>
I actually don't know the reason for the defaults (I didn't create
mplot3d), but that has always been my suspicion.  There is an existing PR
to change the default behavior to be somewhat "automatic".  At the time, I
wasn't really in favor of it, but when looked in this light, it does make
some more sense.

I'll have to think about this a bit more.
Ben Root

> This is because the default rstride and cstride arguments is 10, IIRC.  Since your array is only 12x12, the surface plotting is barely plotting anything.  Try calling:
> 
> ax.plot_surface(x, y, a, rstride=1, cstride=1)


You know, this has tripped me up a few times too.  I don't use plot_surface often enough to always remember this, and it is not the first parameter I think to check when debugging a program.  Is there a reason the default rstride and cstride aren't 1 other than possible memory constraints for large arrays?  

I suppose changing the defaults might break programs that rely on this behavior, but if this API ever gets revamped, consider this a request to make 1 be the default instead.  I would think that the default should be that the obvious command "just works" while plots that may require too much memory can be tweaked to work faster (I'm assuming that is the reason for the default of 10). 

thanks
Ethan

On Tue, Dec 11, 2012 at 8:25 AM, Degang Wu <sam...@gm...> wrote:

> Hi,
>
> My OS is Mac OS X Lion, and the version of matplotlib is 1.2.0 from
> macport.
>
> Now I have an 2d array
>
> a=array([[   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    6.40312424,   19.02629759,    9.8488578 ,
>           12.16552506,   14.        ,    0.        ,   37.01351105],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            6.40312424,    4.24264069,    1.41421356,    8.54400375,
>            4.47213595,   31.25699922,    0.        ,   25.70992026],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>           19.02629759,    1.41421356,   17.2626765 ,   31.32091953,
>           24.18677324,   43.829214  ,    0.        ,   55.14526272],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            9.8488578 ,    8.54400375,   31.32091953,   35.51056181,
>           40.81666326,   57.27128425,    0.        ,   84.62860037],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>           12.16552506,    4.47213595,   24.18677324,   40.81666326,
>           43.65775991,   74.24957912,    0.        ,  112.0044642 ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>           14.        ,   31.25699922,   43.829214  ,   57.27128425,
>           74.24957912,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ,
>            0.        ,    0.        ,    0.        ,    0.        ],
>        [   0.        ,    0.        ,    0.        ,    0.        ,
>           37.01351105,   25.70992026,   55.14526272,   84.62860037,
>          112.0044642 ,    0.        ,    0.        ,    0.        ]])
>
> first I plot it (in ipython notebook) using:
>
> coord_max=12
> fig = plt.figure()
> ax = fig.gca(projection='3d')
> x,y=np.meshgrid(np.arange(coord_max),np.arange(coord_max))
> ax.plot_wireframe(x,y,a)
>
> and the plot looks fine.
>
> but if I use plot_surface instead, the plot looks very wrong: the plot is
> zero everywhere except on the boundaries.
>

This is because the default rstride and cstride arguments is 10, IIRC.
Since your array is only 12x12, the surface plotting is barely plotting
anything.  Try calling:

ax.plot_surface(x, y, a, rstride=1, cstride=1)

I hope that helps!
Ben Root

Hi,

My OS is Mac OS X Lion, and the version of matplotlib is 1.2.0 from macport.

Now I have an 2d array

a=array([[   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    6.40312424,   19.02629759,    9.8488578 ,
          12.16552506,   14.        ,    0.        ,   37.01351105],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           6.40312424,    4.24264069,    1.41421356,    8.54400375,
           4.47213595,   31.25699922,    0.        ,   25.70992026],
       [   0.        ,    0.        ,    0.        ,    0.        ,
          19.02629759,    1.41421356,   17.2626765 ,   31.32091953,
          24.18677324,   43.829214  ,    0.        ,   55.14526272],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           9.8488578 ,    8.54400375,   31.32091953,   35.51056181,
          40.81666326,   57.27128425,    0.        ,   84.62860037],
       [   0.        ,    0.        ,    0.        ,    0.        ,
          12.16552506,    4.47213595,   24.18677324,   40.81666326,
          43.65775991,   74.24957912,    0.        ,  112.0044642 ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
          14.        ,   31.25699922,   43.829214  ,   57.27128425,
          74.24957912,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ,
           0.        ,    0.        ,    0.        ,    0.        ],
       [   0.        ,    0.        ,    0.        ,    0.        ,
          37.01351105,   25.70992026,   55.14526272,   84.62860037,
         112.0044642 ,    0.        ,    0.        ,    0.        ]])

first I plot it (in ipython notebook) using:

coord_max=12
fig = plt.figure()
ax = fig.gca(projection='3d')
x,y=np.meshgrid(np.arange(coord_max),np.arange(coord_max))
ax.plot_wireframe(x,y,a)

and the plot looks fine.

but if I use plot_surface instead, the plot looks very wrong: the plot is zero everywhere except on the boundaries.

Dear all,

I checked and it seems that we don't have rc Parameters for colorbar? could
it be desirable?

Chao

-- 
***********************************************************************************
Chao YUE
Laboratoire des Sciences du Climat et de l'Environnement (LSCE-IPSL)
UMR 1572 CEA-CNRS-UVSQ
Batiment 712 - Pe 119
91191 GIF Sur YVETTE Cedex
Tel: (33) 01 69 08 29 02; Fax:01.69.08.77.16
************************************************************************************

On Mon, Dec 10, 2012 at 2:45 AM, Phil Elson <pel...@gm...> wrote:

> Hi Joe,
>
> Thanks for bringing this up, it is certainly valuable to highlight this on
> the mailinglist. As you say, the change is hard to spot and, I agree, makes
> library code supporting v1.1.1 and v1.2 harder than one would like.
> Typically, anything which is going to break core APIs (even slightly)
> should be documented under the "API Changes" page here
> http://matplotlib.org/api/api_changes.html#changes-in-1-2-x .


Thanks! I wasn't aware of that page! (and it does a very nice job of
documenting the changes!)


> You will find there were quite a few changes made relating to transforms
> which I think is entirely my doing, so at least we know who the guilty
> party is :-)
>
> Thanks for spotting the example failure - I split these changes over many
> separate pull requests and did scan the gallery for any noticeable changes,
> but this one must have slipped the net.
>
> If you're still having problems with using the newer transform API, please
> shout and I'd be happy to have a look for you.
>

Will do, thanks for the offer!


>
> All the best,
>
> Phil
>
>
> On 9 December 2012 22:10, Joe Kington <jof...@gm...> wrote:
>
>> Hi folks,
>>
>> At some point transforms.Transform was slightly refactored.
>> (Particularly, this commit:
>> https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c)  This changed what methods need to be overridden when subclassing
>> Transform.
>>
>> All in all, it seems like a very sensible change, but it led to some very
>> hard-to-find bugs in some of my code that subclasses transforms.Transform.
>> I thought I would mention it on the mailing list for anyone else that uses
>> custom projections. Forgive me if it was mentioned earlier and I just
>> didn't notice.
>>
>> With versions 1.1.x and older, one had to directly implement a transformmethod when subclassingtransforms.Transform,
>> otherwise a NotImplemented error would be raised.
>>
>> With versions 1.2.x and newer, the preferred way appears to be to
>> implement things in a separate transform_affine or transform_non_affinemethod and not explicitly implement a
>> transform method.
>>
>> If you implement the non-affine portion directly in the transform method
>> without overriding transform_non_affine, it leads to strange drawing
>> bugs with v1.2 that did not occur with older versions.  (For example, this
>> broke one of the examples in the gallery between 1.1. and 1.2:
>> http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html
>> http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html. I just submitted a pull request to update the example, by the way.)
>>
>> On the other hand, for compatibility with versions 1.1 and older, you
>> have to explicitly implement the transform method as well, otherwise
>> you'll get the NotImplemented error.
>>
>> Therefore, now one needs to explicitly implement *_both_* the
>> transform_non_affine and transform methods of a custom non-affine
>> transform for compatibility with 1.1 and older as well as 1.2 and newer.
>>
>> Similarly, one needs to implement* _both_ *the transform_path_non_affineand the
>> transform_path methods for compatibility with newer and older versions
>> of matplotlib.
>>
>> Arguably, it should have always been done this way, but  based onexamples/api/custom_projection_example.py,
>> I (and I suspect many other people as well)  implemented the transform
>> directly as the transform method when subclassing Transform, instead of
>> separately in a transform_affine or transform_non_affine method.
>>
>> Is this a large enough change to warrant a mention in the changelog? (On
>> the other hand, the mailing list probably gets a lot more eyes on it than
>> the changelog...)
>>
>> Thanks!
>> -Joe
>>
>>
>>
>> ------------------------------------------------------------------------------
>> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
>> Remotely access PCs and mobile devices and provide instant support
>> Improve your efficiency, and focus on delivering more value-add services
>> Discover what IT Professionals Know. Rescue delivers
>> http://p.sf.net/sfu/logmein_12329d2d
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>>
>

Paul,

Actually, I didn't realize that you had to change the backend in the
matplotlibrc file.  Once I changed it to 'Qt4Agg', everything worked.
 Thanks!

(to find out where your matplotlibrc file is:
"matplotlib.matplotlib_fname()" )

Tim


On Mon, Dec 10, 2012 at 2:34 PM, Timothy Duly <tim...@gm...> wrote:

> Paul,
>
> I am using the "agg" backend:
>
> In [1]: import matplotlib
>
> In [2]: matplotlib.rcParams['backend']
> Out[2]: 'agg'
>
>
> I was able to switch it to the one you have:
>
> In [12]: import matplotlib
> In [13]: matplotlib.rcParams['backend'] = 'Qt4Agg'
>
> but still a simple "plot(1,1)" resulted in no plot being shown.
>
> Thanks,
> Tim
>
>
>
>
>
> On Mon, Dec 10, 2012 at 2:20 PM, Paul Hobson <pmh...@gm...> wrote:
>
>> On Mon, Dec 10, 2012 at 12:15 PM, Timothy Duly <tim...@gm...>wrote:
>>
>>> Hi,
>>>
>>> I recently upgraded to matplotlib v1.2.0 on my Linux machine.  For some
>>> reason, plots are not appearing at all on my screen whenever I try to plot
>>> any routines.
>>>
>>> When I open the interpreter with "ipython --pylab" and do
>>>
>>> In [1]: plot(1,1)
>>> Out[1]: [<matplotlib.lines.Line2D object at 0x2a40450>]
>>>
>>> No plot shows up.  This is somewhat strange as no other error shows up
>>> either.  Does anyone know of a way to debug this? I'm not sure where to
>>> start.
>>>
>>> I also tried to run a simple plot in a script with
>>>
>>> from matplotlib.pyplot import *
>>> figure()
>>> plot(1,1)
>>> draw(); show()
>>>
>>> and still had no success.
>>>
>>> Thanks,
>>> Tim
>>>
>>
>> Which backend are you using?
>>
>> In [1]: import matplotlib
>>
>> In [2]: matplotlib.rcParams['backend']
>>
>> Out[2]: 'Qt4Agg'
>>
>
>

Paul,

I am using the "agg" backend:

In [1]: import matplotlib

In [2]: matplotlib.rcParams['backend']
Out[2]: 'agg'


I was able to switch it to the one you have:

In [12]: import matplotlib
In [13]: matplotlib.rcParams['backend'] = 'Qt4Agg'

but still a simple "plot(1,1)" resulted in no plot being shown.

Thanks,
Tim





On Mon, Dec 10, 2012 at 2:20 PM, Paul Hobson <pmh...@gm...> wrote:

> On Mon, Dec 10, 2012 at 12:15 PM, Timothy Duly <tim...@gm...> wrote:
>
>> Hi,
>>
>> I recently upgraded to matplotlib v1.2.0 on my Linux machine.  For some
>> reason, plots are not appearing at all on my screen whenever I try to plot
>> any routines.
>>
>> When I open the interpreter with "ipython --pylab" and do
>>
>> In [1]: plot(1,1)
>> Out[1]: [<matplotlib.lines.Line2D object at 0x2a40450>]
>>
>> No plot shows up.  This is somewhat strange as no other error shows up
>> either.  Does anyone know of a way to debug this? I'm not sure where to
>> start.
>>
>> I also tried to run a simple plot in a script with
>>
>> from matplotlib.pyplot import *
>> figure()
>> plot(1,1)
>> draw(); show()
>>
>> and still had no success.
>>
>> Thanks,
>> Tim
>>
>
> Which backend are you using?
>
> In [1]: import matplotlib
>
> In [2]: matplotlib.rcParams['backend']
>
> Out[2]: 'Qt4Agg'
>

On Mon, Dec 10, 2012 at 12:15 PM, Timothy Duly <tim...@gm...> wrote:

> Hi,
>
> I recently upgraded to matplotlib v1.2.0 on my Linux machine.  For some
> reason, plots are not appearing at all on my screen whenever I try to plot
> any routines.
>
> When I open the interpreter with "ipython --pylab" and do
>
> In [1]: plot(1,1)
> Out[1]: [<matplotlib.lines.Line2D object at 0x2a40450>]
>
> No plot shows up.  This is somewhat strange as no other error shows up
> either.  Does anyone know of a way to debug this? I'm not sure where to
> start.
>
> I also tried to run a simple plot in a script with
>
> from matplotlib.pyplot import *
> figure()
> plot(1,1)
> draw(); show()
>
> and still had no success.
>
> Thanks,
> Tim
>

Which backend are you using?

In [1]: import matplotlib

In [2]: matplotlib.rcParams['backend']

Out[2]: 'Qt4Agg'

Hi,

I recently upgraded to matplotlib v1.2.0 on my Linux machine.  For some
reason, plots are not appearing at all on my screen whenever I try to plot
any routines.

When I open the interpreter with "ipython --pylab" and do

In [1]: plot(1,1)
Out[1]: [<matplotlib.lines.Line2D object at 0x2a40450>]

No plot shows up.  This is somewhat strange as no other error shows up
either.  Does anyone know of a way to debug this? I'm not sure where to
start.

I also tried to run a simple plot in a script with

from matplotlib.pyplot import *
figure()
plot(1,1)
draw(); show()

and still had no success.

Thanks,
Tim

Hi Joe,

Thanks for bringing this up, it is certainly valuable to highlight this on
the mailinglist. As you say, the change is hard to spot and, I agree, makes
library code supporting v1.1.1 and v1.2 harder than one would like.
Typically, anything which is going to break core APIs (even slightly)
should be documented under the "API Changes" page here
http://matplotlib.org/api/api_changes.html#changes-in-1-2-x . You will find
there were quite a few changes made relating to transforms which I think is
entirely my doing, so at least we know who the guilty party is :-)

Thanks for spotting the example failure - I split these changes over many
separate pull requests and did scan the gallery for any noticeable changes,
but this one must have slipped the net.

If you're still having problems with using the newer transform API, please
shout and I'd be happy to have a look for you.

All the best,

Phil


On 9 December 2012 22:10, Joe Kington <jof...@gm...> wrote:

> Hi folks,
>
> At some point transforms.Transform was slightly refactored.
> (Particularly, this commit:
> https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c)  This changed what methods need to be overridden when subclassing
> Transform.
>
> All in all, it seems like a very sensible change, but it led to some very
> hard-to-find bugs in some of my code that subclasses transforms.Transform.
> I thought I would mention it on the mailing list for anyone else that uses
> custom projections. Forgive me if it was mentioned earlier and I just
> didn't notice.
>
> With versions 1.1.x and older, one had to directly implement a transformmethod when subclassingtransforms.Transform,
> otherwise a NotImplemented error would be raised.
>
> With versions 1.2.x and newer, the preferred way appears to be to
> implement things in a separate transform_affine or transform_non_affinemethod and not explicitly implement a
> transform method.
>
> If you implement the non-affine portion directly in the transform method
> without overriding transform_non_affine, it leads to strange drawing bugs
> with v1.2 that did not occur with older versions.  (For example, this broke
> one of the examples in the gallery between 1.1. and 1.2:
> http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html
> http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html .
> I just submitted a pull request to update the example, by the way.)
>
> On the other hand, for compatibility with versions 1.1 and older, you have
> to explicitly implement the transform method as well, otherwise you'll
> get the NotImplemented error.
>
> Therefore, now one needs to explicitly implement *_both_* the
> transform_non_affine and transform methods of a custom non-affine
> transform for compatibility with 1.1 and older as well as 1.2 and newer.
>
> Similarly, one needs to implement* _both_ *the transform_path_non_affineand the
> transform_path methods for compatibility with newer and older versions of
> matplotlib.
>
> Arguably, it should have always been done this way, but  based onexamples/api/custom_projection_example.py,
> I (and I suspect many other people as well)  implemented the transform
> directly as the transform method when subclassing Transform, instead of
> separately in a transform_affine or transform_non_affine method.
>
> Is this a large enough change to warrant a mention in the changelog? (On
> the other hand, the mailing list probably gets a lot more eyes on it than
> the changelog...)
>
> Thanks!
> -Joe
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>

Hi folks,

At some point transforms.Transform was slightly refactored. (Particularly,
this commit:
https://github.com/matplotlib/matplotlib/commit/8bbe2e55f29b28ba558504b27596b8e36a087c1c)
 This changed what methods need to be overridden when subclassing
Transform.

All in all, it seems like a very sensible change, but it led to some very
hard-to-find bugs in some of my code that subclasses transforms.Transform.
I thought I would mention it on the mailing list for anyone else that uses
custom projections. Forgive me if it was mentioned earlier and I just
didn't notice.

With versions 1.1.x and older, one had to directly implement a
transformmethod when subclassingtransforms.Transform,
otherwise a NotImplemented error would be raised.

With versions 1.2.x and newer, the preferred way appears to be to implement
things in a separate transform_affine or transform_non_affine method and
not explicitly implement a transform method.

If you implement the non-affine portion directly in the transform method
without overriding transform_non_affine, it leads to strange drawing bugs
with v1.2 that did not occur with older versions.  (For example, this broke
one of the examples in the gallery between 1.1. and 1.2:
http://matplotlib.org/1.1.1/examples/api/custom_projection_example.html
http://matplotlib.org/1.2.0/examples/api/custom_projection_example.html . I
just submitted a pull request to update the example, by the way.)

On the other hand, for compatibility with versions 1.1 and older, you have
to explicitly implement the transform method as well, otherwise you'll get
the NotImplemented error.

Therefore, now one needs to explicitly implement *_both_* the
transform_non_affine and transform methods of a custom non-affine transform
for compatibility with 1.1 and older as well as 1.2 and newer.

Similarly, one needs to implement* _both_ *the transform_path_non_affineand the
transform_path methods for compatibility with newer and older versions of
matplotlib.

Arguably, it should have always been done this way, but  based
onexamples/api/custom_projection_example.py,
I (and I suspect many other people as well)  implemented the transform
directly as the transform method when subclassing Transform, instead of
separately in a transform_affine or transform_non_affine method.

Is this a large enough change to warrant a mention in the changelog? (On
the other hand, the mailing list probably gets a lot more eyes on it than
the changelog...)

Thanks!
-Joe

Incidentally, if anyone else wants to do this and is unable to update their matplotlib to v1.2.0, this code snippet achieves the same effect.

#######################################
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.collections import LineCollection

# the line to plot
x = np.linspace(0,1,101)
y = x*0.5-0.25
scaling = np.exp(-(x-0.5)**2/0.5**2) # scale the transparency of the line according to this

points = np.array([x, y]).T.reshape(-1, 1, 2)
segments = np.concatenate([points[:-1], points[1:]], axis=1)

smin = scaling.min()
smax = scaling.max()
# inline function to convert scaling value to alpha value in [0,1]
alpha = lambda s0: (s0-smin)/(smax-smin)
        
# create a (r,g,b,a) color description for each line segment
cmap = []
for a in segments:
    # the x-value for this segment is:
    x0 = a.mean(0)[0]
    # so it has a scaling value of:
    s0 = np.interp(x0,x,scaling)
    # and it has an alpha value of:
    a0 = alpha(s0)
    cmap.append([0.0,0.0,0.0,a0])
    
# Create the line collection object, and set the color parameters.
lc = LineCollection(segments)
lc.set_color(cmap)

ax = plt.subplot(111)
ax.add_collection(lc)
ax.set_xlim(x.min(), x.max())
ax.set_ylim(y.min(), y.max())
plt.show()
#######################################

On 12/5/12 8:36 PM, Dale Lukas Peterson wrote:
> I have a time series of 32-bit unsigned integers in the form of a
> numpy array with dtype=numpy.uint32.  The bits of each integer in
> array correspond to various boolean states collected during an
> experiment.  I would like to make a plot this data in the following
> way:
> 1)  time on the horizontal axis (I have a time array of the same
> length as my integer array)
> 2)  bit position N on the vertical axis (0-1 corresponds to bit 0, 1-2
> corresponds to bit 1, etc.)
> 3)  a solid filled rectangle from (t1, N) to (t1+dt, N+1) whenever the
> bit is high.
>
> I been able to use the bitwise_and() and right_shift() on the data to
> get individual arrays which are populated with only 0's and1's.
>
> What I'm not clear on is now how to get the solid filled rectangle for
> areas where the bit is high and nothing when the bit is low.
>
> Is there already this functionality somewhere in matplotlib?  I looked
> in the gallery and couldn't find anything quite like what I'm looking
> for, though I may have simply missed it.  If there isn't, I'm sure
> there is a way to do it, does anybody have any recommendations as to
> the path of least resistance?

Just FYI, this reminds me a lot of the recent EventRaster discussion:

http://thread.gmane.org/gmane.comp.python.matplotlib.devel/11458/focus=11655

Thanks,

Jason

Hi Luke,


> I been able to use the bitwise_and() and right_shift() on the data to
> get individual arrays which are populated with only 0's and1's.
> 
> What I'm not clear on is now how to get the solid filled rectangle for
> areas where the bit is high and nothing when the bit is low.
> 
> Is there already this functionality somewhere in matplotlib?  I looked
> in the gallery and couldn't find anything quite like what I'm looking
> for, though I may have simply missed it.  If there isn't, I'm sure
> there is a way to do it, does anybody have any recommendations as to
> the path of least resistance?

How about using imshow()? Turn your individual arrays into a three-dimensional array of (r,g,b,a) values (MxNx4 array). You can then overwrite the axis labels (pixel numbers) with the boolean state descriptors and the time stamps. 

Cheers,
Oliver

Dear Matplotlibers,

I'm trying to insert a logo image (from PNG) in the top left corner of my axes. I'm doing this by reading the logo using read_png() and inserting it as an OffsetImage in an AnnotationBox. When saving the figure as PNG everything is based on pixel sizes and I know how to scale the OffsetImage such that I end up with the desired logo size (based on the figure and logo sizes in pixels). Saving as PDF, however, does not depend on pixel sizes, and I end up with a 'different' size of the logo.

Could someone please tell me what determines the size of the OffsetImage when saving as PDF? And maybe even better, how to achieve scaling that results in the same size logo as in the PNG output?

I have attached:
1a) A small test.py script that produces PNG and PDF output showing the different logo sizes. Uncommenting the zoom_factor line shows how to scale the logo independent of the figure size/dpi settings.
1b) A dummy PNG logo file.
2) Two example output files (PNG and PDF) showing the output of test.py.

Any hints would be much appreciated!

Best regards,
Jeroen

I have a time series of 32-bit unsigned integers in the form of a
numpy array with dtype=numpy.uint32.  The bits of each integer in
array correspond to various boolean states collected during an
experiment.  I would like to make a plot this data in the following
way:
1)  time on the horizontal axis (I have a time array of the same
length as my integer array)
2)  bit position N on the vertical axis (0-1 corresponds to bit 0, 1-2
corresponds to bit 1, etc.)
3)  a solid filled rectangle from (t1, N) to (t1+dt, N+1) whenever the
bit is high.

I been able to use the bitwise_and() and right_shift() on the data to
get individual arrays which are populated with only 0's and1's.

What I'm not clear on is now how to get the solid filled rectangle for
areas where the bit is high and nothing when the bit is low.

Is there already this functionality somewhere in matplotlib?  I looked
in the gallery and couldn't find anything quite like what I'm looking
for, though I may have simply missed it.  If there isn't, I'm sure
there is a way to do it, does anybody have any recommendations as to
the path of least resistance?

Thanks,
Luke


-- 
“People call me a perfectionist, but I'm not. I'm a rightist. I do
something until it's right, and then I move on to the next thing.”
― James Cameron

> What is your matplotlib.__version__ ? I think that code only made it's
> way into v1.2.0 (the latest stable), and was did not make it into
> v1.1.1 (or anything before it)

I'm running 1.1.0 - I'll upgrade it now. Thanks for the help!

Oliver

On Wed, Dec 5, 2012 at 2:36 PM, Oliver King <oli...@gm...> wrote:
> What appears to be happening is that the alpha values in the cmap I use when I create the ListedColormap object are being ignored by the add_collection function. I see that this bug (or something quite like it) was reported in late 2008:
> http://matplotlib.1069221.n5.nabble.com/create-ListedColormap-with-different-alpha-values-tt18693.html#a18697
>
> Did the patch from late 2008 not make it into the code, or has this bug resurfaced? Does anyone know of a workaround for this issue?

It's all a blur now, but I don't think that patch made it in because
colormaps were inherently RGB not RGBA.

Something similar to that patch was merged in a year ago:
https://github.com/matplotlib/matplotlib/pull/660 and attached is the
result of running your code on my machine.

What is your matplotlib.__version__ ? I think that code only made it's
way into v1.2.0 (the latest stable), and was did not make it into
v1.1.1 (or anything before it)

--
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7

Hi,

I've been trying to plot a line with varying alpha (but constant color). After much googling I have come up with the following code segment, which by all indications should work. It works when I vary an individual RGB element, but not when I vary alpha.

#################################################
import numpy as np
import matplotlib.pyplot as plt
from matplotlib.collections import LineCollection
from matplotlib.colors import ListedColormap, BoundaryNorm

# the line to plot
x = np.linspace(0,1,101)
y = x*0.5-0.25
scaling = np.exp(-(x-0.5)**2/0.5**2) # scale the transparency of the line according to this

# Create a colormap which has a constant color, but varies the transparency.
N = 50 # this many different transparency levels
alpha_boundaries = np.linspace(np.min(scaling),np.max(scaling),N+1)
# The lowest values are transparent, the highest ones are opaque
cmap = ListedColormap([(0.0,0.0,0.0,a) for a in np.linspace(0,1,N)])
norm = BoundaryNorm(alpha_boundaries, cmap.N)

# Create a set of line segments so that we can color them individually
# This creates the points as a N x 1 x 2 array so that we can stack points
# together easily to get the segments. The segments array for line collection
# needs to be numlines x points per line x 2 (x and y)
points = np.array([x, y]).T.reshape(-1, 1, 2)
segments = np.concatenate([points[:-1], points[1:]], axis=1)
    
# Create the line collection object, setting the colormapping parameters.
# Have to set the actual values used for colormapping separately.
lc = LineCollection(segments, cmap=cmap, norm=norm)
lc.set_array(scaling)

ax = plt.subplot(111)
ax.add_collection(lc)
plt.xlim(x.min(), x.max())
plt.ylim(y.min(), y.max())
plt.show()
#################################################

What appears to be happening is that the alpha values in the cmap I use when I create the ListedColormap object are being ignored by the add_collection function. I see that this bug (or something quite like it) was reported in late 2008:
http://matplotlib.1069221.n5.nabble.com/create-ListedColormap-with-different-alpha-values-tt18693.html#a18697

Did the patch from late 2008 not make it into the code, or has this bug resurfaced? Does anyone know of a workaround for this issue?

Cheers,
Oliver

As of matplotlib v1.2.0 you can hatch a contour set directly. There is an
example in the gallery:

http://matplotlib.org/examples/pylab_examples/contourf_hatching.html

Hope that helps,

Phil


On 5 December 2012 17:28, spencerahill <spe...@gm...> wrote:

> Jae-Joon Lee wrote
> > On Thu, Sep 15, 2011 at 10:33 PM, Jonathan Slavin
> > &lt;
>
> > jslavin@.harvard
>
> > &gt; wrote:
> >> I'm wondering if there is some way to do cross hatching as a way to fill
> >> contours rather than colors (using contourf).  The only references to
> >> cross hatching I see in the documentation are for patches type objects.
> >> As far as I can tell, contour and contourf return objects of their own
> >> type (contour.QuadContourSet) that do not have hatch as an attribute.
> >>
> >
> > Yes, it seems that hatching is only supported in patches.
> > You may workaround this by converting contours to multiple patches.
> > See the attachment.
> >
> > Matplotlib-users mailing list
>
> > Matplotlib-users@.sourceforge
>
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> > contour_to_hatched_patches.py (1K)
> > &lt;
> http://matplotlib.1069221.n5.nabble.com/attachment/23/0/contour_to_hatched_patches.py&gt
> ;
>
> Hi Jae-Joon,
>
> Your contour_to_hatched_patches.py script works excellently. Is there a way
> to suppress the contour lines and filling, leaving only stippling? I have
> been experimenting with it but no luck.
>
> I have a contourf of a 2D variable and a separate 2D array indicating
> regions of statistical significance (i.e. a mask, which equals 1 in cells
> where the variable is significant and equals 0 else), and I want to put
> black hatching over the contourf where it is significant. I can get this to
> work, but still with a black contour line surrounding the hatched region.
> I'd like to remove the line, leaving just the hatching. Thanks!
>
> Best,
> Spencer
>
>
>
>
> --
> View this message in context:
> http://matplotlib.1069221.n5.nabble.com/cross-hatching-in-contours-tp22p39945.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
> Remotely access PCs and mobile devices and provide instant support
> Improve your efficiency, and focus on delivering more value-add services
> Discover what IT Professionals Know. Rescue delivers
> http://p.sf.net/sfu/logmein_12329d2d
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

Jae-Joon Lee wrote
> On Thu, Sep 15, 2011 at 10:33 PM, Jonathan Slavin
> <

> jslavin@.harvard

> > wrote:
>> I'm wondering if there is some way to do cross hatching as a way to fill
>> contours rather than colors (using contourf).  The only references to
>> cross hatching I see in the documentation are for patches type objects.
>> As far as I can tell, contour and contourf return objects of their own
>> type (contour.QuadContourSet) that do not have hatch as an attribute.
>>
> 
> Yes, it seems that hatching is only supported in patches.
> You may workaround this by converting contours to multiple patches.
> See the attachment.
> 
> Matplotlib-users mailing list

> Matplotlib-users@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> contour_to_hatched_patches.py (1K)
> <http://matplotlib.1069221.n5.nabble.com/attachment/23/0/contour_to_hatched_patches.py>

Hi Jae-Joon,

Your contour_to_hatched_patches.py script works excellently. Is there a way
to suppress the contour lines and filling, leaving only stippling? I have
been experimenting with it but no luck. 

I have a contourf of a 2D variable and a separate 2D array indicating
regions of statistical significance (i.e. a mask, which equals 1 in cells
where the variable is significant and equals 0 else), and I want to put
black hatching over the contourf where it is significant. I can get this to
work, but still with a black contour line surrounding the hatched region.
I'd like to remove the line, leaving just the hatching. Thanks!

Best,
Spencer




--
View this message in context: http://matplotlib.1069221.n5.nabble.com/cross-hatching-in-contours-tp22p39945.html
Sent from the matplotlib - users mailing list archive at Nabble.com.

Hi, 

rather than the previous manual definition of the text postioins, I find a
more general/decent way:

yloc=(cbar.values-cbar.boundaries[0])/(cbar.boundaries[-1]-cbar.boundaries[0])
for l,y in zip(cbar_label,yloc):
    cbar.ax.text(1,y,l,transform=cbar.ax.transAxes,ha='left',va='center')

Chao



--
View this message in context: http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39941.html
Sent from the matplotlib - users mailing list archive at Nabble.com.