[Matplotlib-users] MPL = Location of new figure on desktop
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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] TeX fails in general
On 18. aug. 2010, at 23.21, Friedrich Romstedt wrote: 2010/8/17 Paul Anton Letnes paul.anton.let...@gmail.com: If I try to use LaTeX for text processing (i.e. text.usetex : True in my matplotlibrc), I get a cryptic LaTeX error which didn't use to be there before. I get the same problem when using matplotlib-0.98.5 which I compiled from source, and matplotlib-1.0.0 from macports. My python version is 2.6.5 (from macports) and I am running Mac OS X 10.6.4. The error messages are pretty much the same no matter what I plot, and everything works fine if text.usetex : False. Can't reproduce the error here on Mac OS X 10.6.4 64bit with framework-compiled Python 2.6.5 and matplotlib from svn. I could imaging you are missing file creation rights or similar in the directory where matplotlib wants to place that foobar123345.tex file. Friedrich It seems that I had changed an environment variable (TEXINPUTS) elsewhere, meaning that latex didn't pick up the right source file. Everything seems fine now! Paul -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] how do label with matshow
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 :)
--
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] polar plot
On 08/19/2010 05:53 PM, Friedrich Romstedt wrote: 2010/8/19 Michael Droettboommd...@stsci.edu: 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem eemse...@eso.org 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote: On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem eemse...@eso.org 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Fri, Aug 20, 2010 at 9:51 AM, Tony S Yu tsy...@gmail.com wrote: On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote: On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem eemse...@eso.org 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] polar plot
On Fri, Aug 20, 2010 at 8:33 AM, Michael Droettboom md...@stsci.edu wrote: On 08/19/2010 05:53 PM, Friedrich Romstedt wrote: 2010/8/19 Michael Droettboommd...@stsci.edu: 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root ben.r...@ou.edu 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plotting open symbols
Hi Jonathan, On Fri, Aug 20, 2010 at 16:29, Jonathan Slavin jsla...@cfa.harvard.edu 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Aug 20, 2010, at 10:59 AM, Benjamin Root wrote: On Fri, Aug 20, 2010 at 9:51 AM, Tony S Yu tsy...@gmail.com wrote: On Aug 20, 2010, at 10:41 AM, Benjamin Root wrote: On Fri, Aug 20, 2010 at 2:18 AM, Eric Emsellem eemse...@eso.org 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On Fri, Aug 20, 2010 at 10:12 AM, Ryan May rma...@gmail.com wrote: On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root ben.r...@ou.edu 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plotting open symbols
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 jsla...@cfa.harvard.edu 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 jsla...@cfa.harvard.edu 60 Garden Street, MS 83 phone: (617) 496-7981 Cambridge, MA 02138-1516 cell: (781) 363-0035 USA __ -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] plotting open symbols
On Fri, Aug 20, 2010 at 10:25 AM, Jonathan Slavin jsla...@cfa.harvard.eduwrote: 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 jsla...@cfa.harvard.edu 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
[Matplotlib-users] Colorbar labeling
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. -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] MPL = Location of new figure on desktop
On 08/20/2010 05:24 AM, Benjamin Root wrote: On Fri, Aug 20, 2010 at 10:12 AM, Ryan May rma...@gmail.com mailto:rma...@gmail.com wrote: On Fri, Aug 20, 2010 at 9:41 AM, Benjamin Root ben.r...@ou.edu mailto:ben.r...@ou.edu 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 -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] how do label with matshow
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 :)
--
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Colorbar labeling
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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] No installer yet for a Python 2.7-compat. version?
On Mon, Aug 16, 2010 at 9:26 AM, David Goldsmith d.l.goldsm...@gmail.com wrote: And is NumPy 1.5 compat. confirmed yet? Thanks! DG Did I miss a response to this? If not, does silence = (Yes, No)? -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] No installer yet for a Python 2.7-compat. version?
On 10-08-20 1:27 PM, David Goldsmith wrote: On Mon, Aug 16, 2010 at 9:26 AM, David Goldsmith d.l.goldsm...@gmail.com 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/matplotlib-users@lists.sourceforge.net/2010-07/msg00054.html -- 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Colorbar labeling
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...@clearscienceinc.com 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 efir...@hawaii.edu 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 Matplotlib-users@lists.sourceforge.net 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Colorbar labeling
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.001 Out[1]: '-0.0' In [2]: %1.1f % 0.001 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Colorbar labeling
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...@clearscienceinc.com 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 efir...@hawaii.edu 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.001 Out[1]: '-0.0' In [2]: %1.1f % 0.001 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 Matplotlib-users@lists.sourceforge.net 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 Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Re: [Matplotlib-users] Colorbar labeling
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...@clearscienceinc.com 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 Firingefir...@hawaii.edu 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.001 Out[1]: '-0.0' In [2]: %1.1f % 0.001 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 Matplotlib-users@lists.sourceforge.net 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
[Matplotlib-users] Setting y-tick locations on an image plot changes y-axis limits, Bug or expected behavior?
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
--
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
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
