matplotlib-users Mailing List for matplotlib

Hi,

I've recently noticed that setting the y-tick locations on an image plot
changes the y-axis limits, while changing the x-tick locations does not
change the x-axis limits.  I wouldn't have expected either to change the
axis limits, but it seems quite inconsistent that the y-axis and x-axis
behave differently in this situation.

The axis limits are easily restored by a call to "ax.axis('image')", but
this seems unnecessary.

A very quick search of the bug tracker doesn't reveal anything matching this
description...

Is this expected behavior or a bug?

As an example, setting the y-tick locations changes the y-axis limits:
import numpy as np
import matplotlib.pyplot as plt

num = 10
data = np.arange(num**2).reshape((num,num))

fig = plt.figure()
ax = fig.add_subplot(111)

cax = ax.imshow(data)

ax.set_yticks(range(num//2))

fig.show()

However, setting the x-tick locations does not change the axis limits...
import numpy as np
import matplotlib.pyplot as plt

num = 10
data = np.arange(num**2).reshape((num,num))

fig = plt.figure()
ax = fig.add_subplot(111)

cax = ax.imshow(data)

ax.set_xticks(range(num//2))

fig.show()

As a reference, I'm running matplotlib 1.0.0 with python 2.7.0 on a 64-bit
Linux (kernel 2.6.31) machine.  I can confirm this on python 2.6 and
matplotlib 0.99 as well, though.

If this isn't expected behavior, I'll be glad to open a bug report.

Thanks!
-Joe

On 08/20/2010 10:51 AM, Bruce Ford wrote:
> Thanks I'll give this a try.  numpy.min(grid) reports 0.0 (no
> negative) yet it labels as -0.0, BTW, but let me give this a try.

Bruce,

What matters is not min(grid), but the value of the tick. Unless you are 
forcing them to be the same via a kwarg (which I don't see), they may 
differ, as seems to be the case.  Unfortunately, this is hard to debug, 
because there is no way to get at the set of numbers that are being 
formatted to give the tick labels.  Doing something like this:

print cbar.cax.get_yticks()

will be of no help, because the tick positions are on a 0-1 scale 
regardless of the values they represent.

You can, however, specify the desired tick values as a sequence via the 
ticks kwarg to colorbar.  Ticks in that sequence but outside the actual 
colorbar range (as set by the clim() function, for example) will not appear.

Eric

>
> Bruce
>
> ---------------------------------------
> Bruce W. Ford
> Clear Science, Inc.
> br...@cl...
> http://www.ClearScienceInc.com
> http://www.facebook.com/clearscience
> http://www.twitter.com/ROVs_rule
> Phone: (904) 796-8101
> Fax:  (904) 379-9704
> 8241 Parkridge Circle N.
> Jacksonville, FL  32211
> Skype:  bruce.w.ford
>
> ---------------------------------------
> To schedule a meeting with Bruce, Go to: http://tungle.me/bruceford
> ----------------------------------------
>
>
>
>
> On Fri, Aug 20, 2010 at 4:44 PM, Eric Firing<ef...@ha...>  wrote:
>> On 08/20/2010 10:14 AM, Bruce Ford wrote:
>>> This effect is happening within an web app that displays gridded
>>> fields from multiple datasets (~4500 lines of code).  So I it's tricky
>>> to create an example.  Although if I use numpy.min(grid) the minimum
>>> is 0.  So, I think colorbar or matplotlib is interpreting the 0 as -0.
>>
>>
>> You are talking about the colorbar tick labels, correct?  The lowest
>> tick label is coming out as -0.0?
>>
>>
>>>    (Matplotlib version 0.99.0 RC0)
>>>
>>> The colorbar call that I'm using is:
>>>
>>> cbar = pyplot.colorbar(plot,shrink=0.7, format="%1.1f",
>>> spacing='proportional',orientation='vertical')
>>
>> This means your colorbar tick values are simply being formatted by
>> python, like this:
>>
>> In [1]: "%1.1f" % -0.0000001
>> Out[1]: '-0.0'
>>
>> In [2]: "%1.1f" % 0.0000001
>> Out[2]: '0.0'
>>
>> In [3]: "%1.1f" % 0.0
>> Out[3]: '0.0'
>>
>> In [4]: "%1.1f" % -0.0
>> Out[4]: '-0.0'
>>
>> In [5]: import numpy
>>
>> In [6]: numpy.min(-0.0)
>> Out[6]: -0
>>
>> In [7]: -0.0 == 0.0
>> Out[7]: True
>>
>>
>> So I suspect the problem is that a small negative value, or a negative
>> zero, is becoming the tick value.  I don't know why.  You may or may not
>> want to investigate.
>>
>> I dimly recall a problem like this cropping up on the list before--but I
>> don't remember anything else about it.
>>
>> Here is a workaround (untested, but should be close):
>>
>> from matplotlib.ticker import FormatStrFormatter
>> class MyCBFormatter(FormatStrFormatter):
>>      def __call__(self, x, pos=None):
>>          xstr = self.fmt % x
>>          if float(xstr) == 0:
>>              return self.fmt % 0
>>          return xstr
>> cbar = pyplot.colorbar(plot,shrink=0.7, format=MyCBFormatter("%1.1f"),
>>           spacing='proportional',orientation='vertical')
>>
>>
>> Eric
>>
>>>
>>> cbar.ax.set_ylabel(cbar_label(param,unit))
>>>
>>> The function cbar_label is:
>>>
>>> def cbar_label(param,unit):
>>>       #Helper function for making colorbar label
>>>       if param == "sig":
>>>           if unit==1:
>>>               cbar_label = "Feet"
>>>           else:
>>>               cbar_label = "Meters"
>>>       elif param == "dir":
>>>           cbar_label = "Radial Direction"
>>>       elif param == "per":
>>>           cbar_label = "Seconds"
>>>       elif param[-5:] == "_wind":
>>>           if unit == 3:
>>>               cbar_label = "Kts"
>>>           else:
>>>               cbar_label = "M/S"
>>>       elif param[-4:] == "_hgt":
>>>           if unit == 5:
>>>               cbar_label = "GPFt"
>>>           else:
>>>               cbar_label = "GPM"
>>>       elif param == "slp":
>>>           cbar_label = "Millibars"
>>>       elif param == "1000_rh":
>>>           cbar_label = "%"
>>>       elif param == "1000_temp":
>>>           if unit == 9:
>>>               cbar_label = "Degrees F"
>>>           else:
>>>               cbar_label = "Degrees C"
>>>       else:
>>>           cbar_label = param
>>>       return cbar_label
>>>
>>> If this doesn't offer anything, I'll try to generate a
>>> compartmentalized example of the issue.
>>>
>>> Bruce
>>
>> ------------------------------------------------------------------------------
>> This SF.net email is sponsored by
>>
>> Make an app they can't live without
>> Enter the BlackBerry Developer Challenge
>> http://p.sf.net/sfu/RIM-dev2dev
>> _______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users

Thanks I'll give this a try.  numpy.min(grid) reports 0.0 (no
negative) yet it labels as -0.0, BTW, but let me give this a try.

Bruce

---------------------------------------
Bruce W. Ford
Clear Science, Inc.
br...@cl...
http://www.ClearScienceInc.com
http://www.facebook.com/clearscience
http://www.twitter.com/ROVs_rule
Phone: (904) 796-8101
Fax:  (904) 379-9704
8241 Parkridge Circle N.
Jacksonville, FL  32211
Skype:  bruce.w.ford

---------------------------------------
To schedule a meeting with Bruce, Go to: http://tungle.me/bruceford
----------------------------------------




On Fri, Aug 20, 2010 at 4:44 PM, Eric Firing <ef...@ha...> wrote:
> On 08/20/2010 10:14 AM, Bruce Ford wrote:
>> This effect is happening within an web app that displays gridded
>> fields from multiple datasets (~4500 lines of code).  So I it's tricky
>> to create an example.  Although if I use numpy.min(grid) the minimum
>> is 0.  So, I think colorbar or matplotlib is interpreting the 0 as -0.
>
>
> You are talking about the colorbar tick labels, correct?  The lowest
> tick label is coming out as -0.0?
>
>
>>   (Matplotlib version 0.99.0 RC0)
>>
>> The colorbar call that I'm using is:
>>
>> cbar = pyplot.colorbar(plot,shrink=0.7, format="%1.1f",
>> spacing='proportional',orientation='vertical')
>
> This means your colorbar tick values are simply being formatted by
> python, like this:
>
> In [1]: "%1.1f" % -0.0000001
> Out[1]: '-0.0'
>
> In [2]: "%1.1f" % 0.0000001
> Out[2]: '0.0'
>
> In [3]: "%1.1f" % 0.0
> Out[3]: '0.0'
>
> In [4]: "%1.1f" % -0.0
> Out[4]: '-0.0'
>
> In [5]: import numpy
>
> In [6]: numpy.min(-0.0)
> Out[6]: -0
>
> In [7]: -0.0 == 0.0
> Out[7]: True
>
>
> So I suspect the problem is that a small negative value, or a negative
> zero, is becoming the tick value.  I don't know why.  You may or may not
> want to investigate.
>
> I dimly recall a problem like this cropping up on the list before--but I
> don't remember anything else about it.
>
> Here is a workaround (untested, but should be close):
>
> from matplotlib.ticker import FormatStrFormatter
> class MyCBFormatter(FormatStrFormatter):
>     def __call__(self, x, pos=None):
>         xstr = self.fmt % x
>         if float(xstr) == 0:
>             return self.fmt % 0
>         return xstr
> cbar = pyplot.colorbar(plot,shrink=0.7, format=MyCBFormatter("%1.1f"),
>          spacing='proportional',orientation='vertical')
>
>
> Eric
>
>>
>> cbar.ax.set_ylabel(cbar_label(param,unit))
>>
>> The function cbar_label is:
>>
>> def cbar_label(param,unit):
>>      #Helper function for making colorbar label
>>      if param == "sig":
>>          if unit==1:
>>              cbar_label = "Feet"
>>          else:
>>              cbar_label = "Meters"
>>      elif param == "dir":
>>          cbar_label = "Radial Direction"
>>      elif param == "per":
>>          cbar_label = "Seconds"
>>      elif param[-5:] == "_wind":
>>          if unit == 3:
>>              cbar_label = "Kts"
>>          else:
>>              cbar_label = "M/S"
>>      elif param[-4:] == "_hgt":
>>          if unit == 5:
>>              cbar_label = "GPFt"
>>          else:
>>              cbar_label = "GPM"
>>      elif param == "slp":
>>          cbar_label = "Millibars"
>>      elif param == "1000_rh":
>>          cbar_label = "%"
>>      elif param == "1000_temp":
>>          if unit == 9:
>>              cbar_label = "Degrees F"
>>          else:
>>              cbar_label = "Degrees C"
>>      else:
>>          cbar_label = param
>>      return cbar_label
>>
>> If this doesn't offer anything, I'll try to generate a
>> compartmentalized example of the issue.
>>
>> Bruce
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

On 08/20/2010 10:14 AM, Bruce Ford wrote:
> This effect is happening within an web app that displays gridded
> fields from multiple datasets (~4500 lines of code).  So I it's tricky
> to create an example.  Although if I use numpy.min(grid) the minimum
> is 0.  So, I think colorbar or matplotlib is interpreting the 0 as -0.


You are talking about the colorbar tick labels, correct?  The lowest 
tick label is coming out as -0.0?


>   (Matplotlib version 0.99.0 RC0)
>
> The colorbar call that I'm using is:
>
> cbar = pyplot.colorbar(plot,shrink=0.7, format="%1.1f",
> spacing='proportional',orientation='vertical')

This means your colorbar tick values are simply being formatted by 
python, like this:

In [1]: "%1.1f" % -0.0000001
Out[1]: '-0.0'

In [2]: "%1.1f" % 0.0000001
Out[2]: '0.0'

In [3]: "%1.1f" % 0.0
Out[3]: '0.0'

In [4]: "%1.1f" % -0.0
Out[4]: '-0.0'

In [5]: import numpy

In [6]: numpy.min(-0.0)
Out[6]: -0

In [7]: -0.0 == 0.0
Out[7]: True


So I suspect the problem is that a small negative value, or a negative 
zero, is becoming the tick value.  I don't know why.  You may or may not 
want to investigate.

I dimly recall a problem like this cropping up on the list before--but I 
don't remember anything else about it.

Here is a workaround (untested, but should be close):

from matplotlib.ticker import FormatStrFormatter
class MyCBFormatter(FormatStrFormatter):
     def __call__(self, x, pos=None):
         xstr = self.fmt % x
         if float(xstr) == 0:
             return self.fmt % 0
         return xstr
cbar = pyplot.colorbar(plot,shrink=0.7, format=MyCBFormatter("%1.1f"),
          spacing='proportional',orientation='vertical')


Eric

>
> cbar.ax.set_ylabel(cbar_label(param,unit))
>
> The function cbar_label is:
>
> def cbar_label(param,unit):
>      #Helper function for making colorbar label
>      if param == "sig":
>          if unit==1:
>              cbar_label = "Feet"
>          else:
>              cbar_label = "Meters"
>      elif param == "dir":
>          cbar_label = "Radial Direction"
>      elif param == "per":
>          cbar_label = "Seconds"
>      elif param[-5:] == "_wind":
>          if unit == 3:
>              cbar_label = "Kts"
>          else:
>              cbar_label = "M/S"
>      elif param[-4:] == "_hgt":
>          if unit == 5:
>              cbar_label = "GPFt"
>          else:
>              cbar_label = "GPM"
>      elif param == "slp":
>          cbar_label = "Millibars"
>      elif param == "1000_rh":
>          cbar_label = "%"
>      elif param == "1000_temp":
>          if unit == 9:
>              cbar_label = "Degrees F"
>          else:
>              cbar_label = "Degrees C"
>      else:
>          cbar_label = param
>      return cbar_label
>
> If this doesn't offer anything, I'll try to generate a
> compartmentalized example of the issue.
>
> Bruce

This effect is happening within an web app that displays gridded
fields from multiple datasets (~4500 lines of code).  So I it's tricky
to create an example.  Although if I use numpy.min(grid) the minimum
is 0.  So, I think colorbar or matplotlib is interpreting the 0 as -0.
 (Matplotlib version 0.99.0 RC0)

The colorbar call that I'm using is:

cbar = pyplot.colorbar(plot,shrink=0.7, format="%1.1f",
spacing='proportional',orientation='vertical')

cbar.ax.set_ylabel(cbar_label(param,unit))

The function cbar_label is:

def cbar_label(param,unit):
    #Helper function for making colorbar label
    if param == "sig":
        if unit==1:
            cbar_label = "Feet"
        else:
            cbar_label = "Meters"
    elif param == "dir":
        cbar_label = "Radial Direction"
    elif param == "per":
        cbar_label = "Seconds"
    elif param[-5:] == "_wind":
        if unit == 3:
            cbar_label = "Kts"
        else:
            cbar_label = "M/S"
    elif param[-4:] == "_hgt":
        if unit == 5:
            cbar_label = "GPFt"
        else:
            cbar_label = "GPM"
    elif param == "slp":
        cbar_label = "Millibars"
    elif param == "1000_rh":
        cbar_label = "%"
    elif param == "1000_temp":
        if unit == 9:
            cbar_label = "Degrees F"
        else:
            cbar_label = "Degrees C"
    else:
        cbar_label = param
    return cbar_label

If this doesn't offer anything, I'll try to generate a
compartmentalized example of the issue.

Bruce
---------------------------------------
Bruce W. Ford
Clear Science, Inc.
br...@cl...
http://www.ClearScienceInc.com
http://www.facebook.com/clearscience
http://www.twitter.com/ROVs_rule
Phone: (904) 796-8101
Fax:  (904) 379-9704
8241 Parkridge Circle N.
Jacksonville, FL  32211
Skype:  bruce.w.ford

---------------------------------------
To schedule a meeting with Bruce, Go to: http://tungle.me/bruceford
----------------------------------------




On Fri, Aug 20, 2010 at 2:06 PM, Eric Firing <ef...@ha...> wrote:
> On 08/20/2010 05:29 AM, Bruce Ford wrote:
>> I have a grid with values ranging from exactly 0.0 and 100.0.  When I
>> plot this with colorbar, the base of the colorbar is labeled "-0.0".
>> Is this a default for 0.0...to plot it with as a negative number?  Any
>> workarounds?
>
> Would you provide a minimal runnable example, please, and specify what
> mpl version you are using?  It is certainly not intended or usual that 0
> be displayed as -0.
>
> Eric
>
>
>>
>> Bruce
>>
>> ---------------------------------------
>> Bruce W. Ford
>> Clear Science, Inc.
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>

  On 10-08-20 1:27 PM, David Goldsmith wrote:
> On Mon, Aug 16, 2010 at 9:26 AM, David Goldsmith
> <d.l...@gm...>  wrote:
>> And is NumPy 1.5 compat. confirmed yet?  Thanks!
>>
>> DG
> Did I miss a response to this?  If not, does silence =>  (Yes, No)?
>
David,

  As far as I know, there is no installer for matplotlib with Python 2.7 
because there is no official version of NumPy currently available for 
this version of Python:

http://www.mailinglistarchive.com/html/mat...@li.../2010-07/msg00054.html 

On Mon, Aug 16, 2010 at 9:26 AM, David Goldsmith
<d.l...@gm...> wrote:
> And is NumPy 1.5 compat. confirmed yet?  Thanks!
>
> DG

Did I miss a response to this?  If not, does silence => (Yes, No)?

On 08/20/2010 05:29 AM, Bruce Ford wrote:
> I have a grid with values ranging from exactly 0.0 and 100.0.  When I
> plot this with colorbar, the base of the colorbar is labeled "-0.0".
> Is this a default for 0.0...to plot it with as a negative number?  Any
> workarounds?

Would you provide a minimal runnable example, please, and specify what 
mpl version you are using?  It is certainly not intended or usual that 0 
be displayed as -0.

Eric


>
> Bruce
>
> ---------------------------------------
> Bruce W. Ford
> Clear Science, Inc.

On 08/20/2010 12:38 AM, Patricia wrote:
>
>
> Hi all,
>
> I start using matplotlib a month ago, so I'm still learning.
> I'm trying to do a heatmap with matshow. My code is the following:
>
> data = numpy.array(a).reshape(4, 4)
> cax = ax.matshow(data, interpolation='nearest', cmap=cm.get_cmap('PuBu'),
> norm=LogNorm())
> cbar = fig.colorbar(cax)
>
> ax.set_xticklabels(alpha)
> ax.set_yticklabels(alpha)
>
> where alpha is a model from django with 4fields: 'ABC', 'DEF', 'GHI', 'JKL'

The problem is that ticks and ticklabels are not necessarily within the 
axes limits.  In this case, the array of tick locations is actually [-1, 
0, 1, 2, 3, 4], so what you need to do is provide labels to match those 
locations.  Try this:

alpha = ['', 'ABC', 'DEF', 'GHI', 'JKL', '']

Eric

>
> the thing is that I don't know why, the label 'ABC' doesn't appear, leaving the
> last cell without label.
> I would like to known how do I properly label my heatmap, when I use set_ticks
> the figure decrease size and the colorbar stay bigger than the figure.
> If someone would have a clue how to modify my script in a way to appear the
> 'ABC' I would be grateful :)
>

On 08/20/2010 05:24 AM, Benjamin Root wrote:
>
>
> On Fri, Aug 20, 2010 at 10:12 AM, Ryan May <rm...@gm...
> <mailto:rm...@gm...>> wrote:
>
>     On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben...@ou...
>     <mailto:ben...@ou...>> wrote:
>      > One possibility for this behavior might be that you might be
>     defaulting to a
>      > different backend than QT.  I would imagine if matplotlib is
>     defaulting to
>      > the GTKAgg backend or the Tk backend, then the figure window
>     would not
>      > behave properly in the window manager.  You can set a default
>     backend value
>      > to Qt4Agg in your matplotlibrc file.  Maybe that would work.
>
>     I can see the look of the widgets depending on the backend and current
>     desktop environment, but to a window manager, a window is a window.
>     They're all just X11 objects. The manager is just placing a box and
>     responding to minimize/maximze, etc.
>
>     It doesn't hurt to check, I just would be *GREATLY* surprised if
>     anything changed due to the window manager. My money would be on some
>     hint that a particular backend is failing to give the WM.
>
>     Ryan
>
>
> That is exactly what I am thinking now that we know that it happens even
> with the Qt4Agg backend.  Should these hints be given by the objects in
> backend_bases (for a consistent behavior), or do they have to be done by
> the individual backends?  Maybe the hints could be stored as rcParams
> for all backends to refer to?

Every backend has a call to create a new toplevel window.  All sorts of 
window properties, including window manager hints and requests, are 
controlled by some combination of the initializer and the methods of 
that toplevel window object, perhaps supplemented with toolkit-level 
functions and other methods of setting gui toolkit defaults.  At 
present, I think mpl is simply using defaults for everything except the 
window dimensions.  Certainly it would be possible to allow more 
customization, but it will require separate code for each gui backend. 
Putting in enough such code to provide some control over where windows 
are created, and whether they come up above or below existing windows, 
would be a nice project for someone, and would be a good enhancement to 
mpl.  It would be good to agree on what the default behavior should be; 
the first step in such a project would be to make the defaults 
consistent among backends, to the extent permitted by the various 
toolkits and window managers.

Eric

Hi

thanks a lot for the feedback.

Just tested with Qt4Agg and the window is coming up in the right location (just 
below my xterm where there is still space for a new window) now, and sometimes 
on TOP, but also sometimes at the BOTTOM.... I was using WxAgg before.

So it seems it is backend dependent at least with me (0.99). If this is 
confirmed I am ok for the moment to use Qt4Agg (if this does not impact other 
functionalities) as at least it seems to deal with the location in a better way. 
It would be better if really the link with the WM works better of course.

Eric

> That is exactly what I am thinking now that we know that it happens even
> with the Qt4Agg backend.  Should these hints be given by the objects in
> backend_bases (for a consistent behavior), or do they have to be done by
> the individual backends?  Maybe the hints could be stored as rcParams
> for all backends to refer to

I have a grid with values ranging from exactly 0.0 and 100.0.  When I
plot this with colorbar, the base of the colorbar is labeled "-0.0".
Is this a default for 0.0...to plot it with as a negative number?  Any
workarounds?

Bruce

---------------------------------------
Bruce W. Ford
Clear Science, Inc.

On Fri, Aug 20, 2010 at 10:25 AM, Jonathan Slavin
<js...@cf...>wrote:

> Tinne,
>
> Thanks.  I think I had tried that but with mfc=None -- that is without
> None in quotes as if it were a string.  I have to say it's a bit odd to
> have it in quotes since generally it is a different data type entirely
> (None type).
>
> Jon
>
> On Fri, 2010-08-20 at 17:12 +0200, Tinne De Laet wrote:
> > Hi Jonathan,
> >
> > On Fri, Aug 20, 2010 at 16:29, Jonathan Slavin <js...@cf...>
> wrote:
> > > To all:
> > >
> > > I'm wondering if there is any way to make plots with open symbols, e.g.
> > > a circle.  I know how to use markers that look open, e.g. by doing
> > > something like,
> > > plot(x,y,marker='o',mfc='w')
> > > They are white in the center, but they're not really open since they
> > > block out whatever is behind them.  I tried using a color with
> > > transparency, say alpha=0.1 or something (mfc=(1.,1.,1.,0.1)) but that
> > > didn't work.  What I have in mind is illustrated in the attached plot,
> > > which I made some time ago in IDL. Is there an easy way to define your
> > > own markers for plotting?
> >
> > just use mfc='None'
> >
> >
> > Tinne
> --
>


John,

This used to trip me up as well.  However, for colors in matplotlib, None
(without quotes) tells mpl to use the default color, while 'None' (typically
not case-sensitive) means "do not plot any color".

I hope that clears things up.

Ben Root

Tinne,

Thanks.  I think I had tried that but with mfc=None -- that is without
None in quotes as if it were a string.  I have to say it's a bit odd to
have it in quotes since generally it is a different data type entirely
(None type).

Jon

On Fri, 2010-08-20 at 17:12 +0200, Tinne De Laet wrote:
> Hi Jonathan,
> 
> On Fri, Aug 20, 2010 at 16:29, Jonathan Slavin <js...@cf...> wrote:
> > To all:
> >
> > I'm wondering if there is any way to make plots with open symbols, e.g.
> > a circle.  I know how to use markers that look open, e.g. by doing
> > something like,
> > plot(x,y,marker='o',mfc='w')
> > They are white in the center, but they're not really open since they
> > block out whatever is behind them.  I tried using a color with
> > transparency, say alpha=0.1 or something (mfc=(1.,1.,1.,0.1)) but that
> > didn't work.  What I have in mind is illustrated in the attached plot,
> > which I made some time ago in IDL. Is there an easy way to define your
> > own markers for plotting?
> 
> just use mfc='None'
> 
> 
> Tinne
-- 
______________________________________________________________
Jonathan D. Slavin              Harvard-Smithsonian CfA
js...@cf...         60 Garden Street, MS 83
phone: (617) 496-7981           Cambridge, MA 02138-1516
 cell: (781) 363-0035           USA
______________________________________________________________

On Fri, Aug 20, 2010 at 10:12 AM, Ryan May <rm...@gm...> wrote:

> On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben...@ou...> wrote:
> > One possibility for this behavior might be that you might be defaulting
> to a
> > different backend than QT.  I would imagine if matplotlib is defaulting
> to
> > the GTKAgg backend or the Tk backend, then the figure window would not
> > behave properly in the window manager.  You can set a default backend
> value
> > to Qt4Agg in your matplotlibrc file.  Maybe that would work.
>
> I can see the look of the widgets depending on the backend and current
> desktop environment, but to a window manager, a window is a window.
> They're all just X11 objects. The manager is just placing a box and
> responding to minimize/maximze, etc.
>
> It doesn't hurt to check, I just would be *GREATLY* surprised if
> anything changed due to the window manager. My money would be on some
> hint that a particular backend is failing to give the WM.
>
> Ryan
>
>
That is exactly what I am thinking now that we know that it happens even
with the Qt4Agg backend.  Should these hints be given by the objects in
backend_bases (for a consistent behavior), or do they have to be done by the
individual backends?  Maybe the hints could be stored as rcParams for all
backends to refer to?

Ben Root

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

On Aug 20, 2010, at 10:59 AM, Benjamin Root wrote:

> 
> 
> On Fri, Aug 20, 2010 at 9:51 AM, Tony S Yu <ts...@gm...> wrote:
> 
> On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote:
> 
>> On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eem...@es...> wrote:
>> Hi
>> 
>> I have one very nagging issue which I would like to solve with matplotlib once
>> and for all: this may have to do with my desktop windown manager but I couldn't
>> find much there, so any input is welcome.
>> 
>> When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using
>> KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
>> other windows). I would like some "smart" location for that figure so I don't
>> have systematically to get it up and move it when I open a new figure. Is this
>> linked to matplotlib? (this is the only application which is not managed
>> properly in this context). I am using ipython -pylab as a working context (on
>> opensuse 11.2).
>> 
>> thanks and cheers
>> 
>> Eric
>> 
>> 
>> Eric,
>> 
>> One possibility for this behavior might be that you might be defaulting to a different backend than QT.  I would imagine if matplotlib is defaulting to the GTKAgg backend or the Tk backend, then the figure window would not behave properly in the window manager.  You can set a default backend value to Qt4Agg in your matplotlibrc file.  Maybe that would work.
>> 
>> Ben Root
> 
> I've had the same issue as Eric using Qt4Agg as the backend (and with all other backends I've used). As Eric mentioned, I have this windowing issue with ipython -pylab, but this issue also arises when running scripts from the command line and from my text editor (i.e. it's not ipython specific).
> 
> -Tony
> 
> 
> 
> Does it also happen with the QtAgg backend?  Does the behavior change based on which backend you choose?  That might help narrow down whether it is a problem with particular backends or with the backend interface.
> 
> Ben Root

A couple of corrections: 

1) I wasn't clear earlier: I was agreeing with Eric on the fact that the plot window appeared below other windows. The location (e.g. top-left corner)  depends on the backend I use.

2) I was wrong that all backends show up below the terminal window: the MacOSX backend creates plots above other windows (unfortunately, I can't test QtAgg; only macosx, qt4agg, and tkagg).

-Tony

On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root <ben...@ou...> wrote:
> One possibility for this behavior might be that you might be defaulting to a
> different backend than QT.  I would imagine if matplotlib is defaulting to
> the GTKAgg backend or the Tk backend, then the figure window would not
> behave properly in the window manager.  You can set a default backend value
> to Qt4Agg in your matplotlibrc file.  Maybe that would work.

I can see the look of the widgets depending on the backend and current
desktop environment, but to a window manager, a window is a window.
They're all just X11 objects. The manager is just placing a box and
responding to minimize/maximze, etc.

It doesn't hurt to check, I just would be *GREATLY* surprised if
anything changed due to the window manager. My money would be on some
hint that a particular backend is failing to give the WM.

Ryan

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

Hi Jonathan,

On Fri, Aug 20, 2010 at 16:29, Jonathan Slavin <js...@cf...> wrote:
> To all:
>
> I'm wondering if there is any way to make plots with open symbols, e.g.
> a circle.  I know how to use markers that look open, e.g. by doing
> something like,
> plot(x,y,marker='o',mfc='w')
> They are white in the center, but they're not really open since they
> block out whatever is behind them.  I tried using a color with
> transparency, say alpha=0.1 or something (mfc=(1.,1.,1.,0.1)) but that
> didn't work.  What I have in mind is illustrated in the attached plot,
> which I made some time ago in IDL. Is there an easy way to define your
> own markers for plotting?

just use mfc='None'


Tinne

On Fri, Aug 20, 2010 at 8:33 AM, Michael Droettboom <md...@st...> wrote:

> On 08/19/2010 05:53 PM, Friedrich Romstedt wrote:
> > 2010/8/19 Michael Droettboom<md...@st...>:
> >
> >> On 08/18/2010 06:03 PM, Friedrich Romstedt wrote:
> >>
> >>> Is the attached issue with a plain polar axes already fixed?  I never
> >>> encountered this before.  344 degrees happens to be 6.0 rad.  I'm on
> >>> svn 8626.
> >>>
> >> How are you creating that graph?  By default, polar plots don't do that.
> >>
> > Yeah, it's my issue, but I'm not happy with fixing it.  Currently,
> > matplotlib forces the xticks (i.e., the theta ticks) to be at sensible
> > values via .set_xticks() and .set_xlabels() (projections/polar.py).
> >
> > I'm coding a matplotlib extension package which has to clear the axes
> > often, but restoring the major locators, the title and stuff after
> > clearing.  It was agnostic to the specialities of polar axes so far.
> >
> Why and how are you restoring the major locator?  It seems like that's
> the issue.  I don't think preventing the theta locator from being
> changed is something we want to do.  Polar plots (by default) just set
> fixed theta ticks at multiples of pi/4.
> > I would rather suggest to insert a new Locator class being aware of
> > radians.  It would suffice to return tick positions dividing 2 pi into
> > an integer number of bins.  It's not necessary to cover all the
> > peculiarities of the old historic division system into 360 parts.
> >
> Perhaps using FixedLocator, rather than explicitly setting the ticks
> using set_xticks (as polar plots currently do) would be better.
> However, the locator could still be changed, not really addressing your
> problem.
>
> For convenience, however, we could add a locator that given n, divides
> 2pi into n parts.
> > Accompanying would be formatters in radians and degrees with
> > adjustable precision (no autodetect necessary).
> >
> Sure.  Adding a radian formatter makes sense.
>
>
Just curious, this wouldn't have to be just for PolarPlots, right?  Could it
also be used for regular plots of sinusoids and such.

Ben Root

To all:

I'm wondering if there is any way to make plots with open symbols, e.g.
a circle.  I know how to use markers that look open, e.g. by doing
something like,
plot(x,y,marker='o',mfc='w')
They are white in the center, but they're not really open since they
block out whatever is behind them.  I tried using a color with
transparency, say alpha=0.1 or something (mfc=(1.,1.,1.,0.1)) but that
didn't work.  What I have in mind is illustrated in the attached plot,
which I made some time ago in IDL. Is there an easy way to define your
own markers for plotting?

Jon

On Fri, Aug 20, 2010 at 9:51 AM, Tony S Yu <ts...@gm...> wrote:

>
> On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote:
>
> On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eem...@es...> wrote:
>
>> Hi
>>
>> I have one very nagging issue which I would like to solve with matplotlib
>> once
>> and for all: this may have to do with my desktop windown manager but I
>> couldn't
>> find much there, so any input is welcome.
>>
>> When I open a new figure, the figure ALWAYS comes BELOW my current xterm
>> (using
>> KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually
>> put
>> other windows). I would like some "smart" location for that figure so I
>> don't
>> have systematically to get it up and move it when I open a new figure. Is
>> this
>> linked to matplotlib? (this is the only application which is not managed
>> properly in this context). I am using ipython -pylab as a working context
>> (on
>> opensuse 11.2).
>>
>> thanks and cheers
>>
>> Eric
>>
>>
> Eric,
>
> One possibility for this behavior might be that you might be defaulting to
> a different backend than QT.  I would imagine if matplotlib is defaulting to
> the GTKAgg backend or the Tk backend, then the figure window would not
> behave properly in the window manager.  You can set a default backend value
> to Qt4Agg in your matplotlibrc file.  Maybe that would work.
>
> Ben Root
>
>
> I've had the same issue as Eric using Qt4Agg as the backend (and with all
> other backends I've used). As Eric mentioned, I have this windowing issue
> with ipython -pylab, but this issue also arises when running scripts from
> the command line and from my text editor (i.e. it's not ipython specific).
>
> -Tony
>
>
>
Does it also happen with the QtAgg backend?  Does the behavior change based
on which backend you choose?  That might help narrow down whether it is a
problem with particular backends or with the backend interface.

Ben Root

On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote:

> On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eem...@es...> wrote:
> Hi
> 
> I have one very nagging issue which I would like to solve with matplotlib once
> and for all: this may have to do with my desktop windown manager but I couldn't
> find much there, so any input is welcome.
> 
> When I open a new figure, the figure ALWAYS comes BELOW my current xterm (using
> KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
> other windows). I would like some "smart" location for that figure so I don't
> have systematically to get it up and move it when I open a new figure. Is this
> linked to matplotlib? (this is the only application which is not managed
> properly in this context). I am using ipython -pylab as a working context (on
> opensuse 11.2).
> 
> thanks and cheers
> 
> Eric
> 
> 
> Eric,
> 
> One possibility for this behavior might be that you might be defaulting to a different backend than QT.  I would imagine if matplotlib is defaulting to the GTKAgg backend or the Tk backend, then the figure window would not behave properly in the window manager.  You can set a default backend value to Qt4Agg in your matplotlibrc file.  Maybe that would work.
> 
> Ben Root

I've had the same issue as Eric using Qt4Agg as the backend (and with all other backends I've used). As Eric mentioned, I have this windowing issue with ipython -pylab, but this issue also arises when running scripts from the command line and from my text editor (i.e. it's not ipython specific).

-Tony

On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem <eem...@es...> wrote:

> Hi
>
> I have one very nagging issue which I would like to solve with matplotlib
> once
> and for all: this may have to do with my desktop windown manager but I
> couldn't
> find much there, so any input is welcome.
>
> When I open a new figure, the figure ALWAYS comes BELOW my current xterm
> (using
> KDE 4.3) and ALWAYS in the wrong place (top left corner where I usually put
> other windows). I would like some "smart" location for that figure so I
> don't
> have systematically to get it up and move it when I open a new figure. Is
> this
> linked to matplotlib? (this is the only application which is not managed
> properly in this context). I am using ipython -pylab as a working context
> (on
> opensuse 11.2).
>
> thanks and cheers
>
> Eric
>
>
Eric,

One possibility for this behavior might be that you might be defaulting to a
different backend than QT.  I would imagine if matplotlib is defaulting to
the GTKAgg backend or the Tk backend, then the figure window would not
behave properly in the window manager.  You can set a default backend value
to Qt4Agg in your matplotlibrc file.  Maybe that would work.

Ben Root

On 08/19/2010 05:53 PM, Friedrich Romstedt wrote:
> 2010/8/19 Michael Droettboom<md...@st...>:
>    
>> On 08/18/2010 06:03 PM, Friedrich Romstedt wrote:
>>      
>>> Is the attached issue with a plain polar axes already fixed?  I never
>>> encountered this before.  344 degrees happens to be 6.0 rad.  I'm on
>>> svn 8626.
>>>        
>> How are you creating that graph?  By default, polar plots don't do that.
>>      
> Yeah, it's my issue, but I'm not happy with fixing it.  Currently,
> matplotlib forces the xticks (i.e., the theta ticks) to be at sensible
> values via .set_xticks() and .set_xlabels() (projections/polar.py).
>
> I'm coding a matplotlib extension package which has to clear the axes
> often, but restoring the major locators, the title and stuff after
> clearing.  It was agnostic to the specialities of polar axes so far.
>    
Why and how are you restoring the major locator?  It seems like that's 
the issue.  I don't think preventing the theta locator from being 
changed is something we want to do.  Polar plots (by default) just set 
fixed theta ticks at multiples of pi/4.
> I would rather suggest to insert a new Locator class being aware of
> radians.  It would suffice to return tick positions dividing 2 pi into
> an integer number of bins.  It's not necessary to cover all the
> peculiarities of the old historic division system into 360 parts.
>    
Perhaps using FixedLocator, rather than explicitly setting the ticks 
using set_xticks (as polar plots currently do) would be better.  
However, the locator could still be changed, not really addressing your 
problem.

For convenience, however, we could add a locator that given n, divides 
2pi into n parts.
> Accompanying would be formatters in radians and degrees with
> adjustable precision (no autodetect necessary).
>    
Sure.  Adding a radian formatter makes sense.

Mike

-- 
Michael Droettboom
Science Software Branch
Space Telescope Science Institute
Baltimore, Maryland, USA

Hi all,

I start using matplotlib a month ago, so I'm still learning.
I'm trying to do a heatmap with matshow. My code is the following:

data = numpy.array(a).reshape(4, 4)
cax = ax.matshow(data, interpolation='nearest', cmap=cm.get_cmap('PuBu'),
norm=LogNorm())
cbar = fig.colorbar(cax)

ax.set_xticklabels(alpha)
ax.set_yticklabels(alpha)

where alpha is a model from django with 4fields: 'ABC', 'DEF', 'GHI', 'JKL'

the thing is that I don't know why, the label 'ABC' doesn't appear, leaving the
last cell without label.
I would like to known how do I properly label my heatmap, when I use set_ticks
the figure decrease size and the colorbar stay bigger than the figure.
If someone would have a clue how to modify my script in a way to appear the
'ABC' I would be grateful :)