You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(12) |
Sep
(12) |
Oct
(56) |
Nov
(65) |
Dec
(37) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(59) |
Feb
(78) |
Mar
(153) |
Apr
(205) |
May
(184) |
Jun
(123) |
Jul
(171) |
Aug
(156) |
Sep
(190) |
Oct
(120) |
Nov
(154) |
Dec
(223) |
| 2005 |
Jan
(184) |
Feb
(267) |
Mar
(214) |
Apr
(286) |
May
(320) |
Jun
(299) |
Jul
(348) |
Aug
(283) |
Sep
(355) |
Oct
(293) |
Nov
(232) |
Dec
(203) |
| 2006 |
Jan
(352) |
Feb
(358) |
Mar
(403) |
Apr
(313) |
May
(165) |
Jun
(281) |
Jul
(316) |
Aug
(228) |
Sep
(279) |
Oct
(243) |
Nov
(315) |
Dec
(345) |
| 2007 |
Jan
(260) |
Feb
(323) |
Mar
(340) |
Apr
(319) |
May
(290) |
Jun
(296) |
Jul
(221) |
Aug
(292) |
Sep
(242) |
Oct
(248) |
Nov
(242) |
Dec
(332) |
| 2008 |
Jan
(312) |
Feb
(359) |
Mar
(454) |
Apr
(287) |
May
(340) |
Jun
(450) |
Jul
(403) |
Aug
(324) |
Sep
(349) |
Oct
(385) |
Nov
(363) |
Dec
(437) |
| 2009 |
Jan
(500) |
Feb
(301) |
Mar
(409) |
Apr
(486) |
May
(545) |
Jun
(391) |
Jul
(518) |
Aug
(497) |
Sep
(492) |
Oct
(429) |
Nov
(357) |
Dec
(310) |
| 2010 |
Jan
(371) |
Feb
(657) |
Mar
(519) |
Apr
(432) |
May
(312) |
Jun
(416) |
Jul
(477) |
Aug
(386) |
Sep
(419) |
Oct
(435) |
Nov
(320) |
Dec
(202) |
| 2011 |
Jan
(321) |
Feb
(413) |
Mar
(299) |
Apr
(215) |
May
(284) |
Jun
(203) |
Jul
(207) |
Aug
(314) |
Sep
(321) |
Oct
(259) |
Nov
(347) |
Dec
(209) |
| 2012 |
Jan
(322) |
Feb
(414) |
Mar
(377) |
Apr
(179) |
May
(173) |
Jun
(234) |
Jul
(295) |
Aug
(239) |
Sep
(276) |
Oct
(355) |
Nov
(144) |
Dec
(108) |
| 2013 |
Jan
(170) |
Feb
(89) |
Mar
(204) |
Apr
(133) |
May
(142) |
Jun
(89) |
Jul
(160) |
Aug
(180) |
Sep
(69) |
Oct
(136) |
Nov
(83) |
Dec
(32) |
| 2014 |
Jan
(71) |
Feb
(90) |
Mar
(161) |
Apr
(117) |
May
(78) |
Jun
(94) |
Jul
(60) |
Aug
(83) |
Sep
(102) |
Oct
(132) |
Nov
(154) |
Dec
(96) |
| 2015 |
Jan
(45) |
Feb
(138) |
Mar
(176) |
Apr
(132) |
May
(119) |
Jun
(124) |
Jul
(77) |
Aug
(31) |
Sep
(34) |
Oct
(22) |
Nov
(23) |
Dec
(9) |
| 2016 |
Jan
(26) |
Feb
(17) |
Mar
(10) |
Apr
(8) |
May
(4) |
Jun
(8) |
Jul
(6) |
Aug
(5) |
Sep
(9) |
Oct
(4) |
Nov
|
Dec
|
| 2017 |
Jan
(5) |
Feb
(7) |
Mar
(1) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(6) |
Aug
(1) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Neal B. <ndb...@gm...> - 2012-11-20 12:20:09
|
python setup.py install won't cause that issue. Also, easy_install doesn't cause the same issue. OTOH, I'm not sure what easy_install does in the case of deps. If you use pip install --user it will try (and fail) to remove old versions of deps from system. I don't know what easy_install does in this case. I have also had issues where python setup.py install will install everything into /usr/lib, while fedora packaging will try to install arch-dep parts under e.g., /usr/lib64. I have many times wound up with 2 versions of things that way. On Tue, Nov 20, 2012 at 7:04 AM, Mathew Topper <mat...@ed...>wrote: > Neal, thanks for the warning. I found the thread of your discussion here > actually: > > http://lists.fedoraproject.org/pipermail/devel/2012-February/162496.html > > It's very interesting. My feeling would be that a PyPI fedora repository > would make the most sense - much like the current Fedora TexLive2012 > testing repository - but obviously this is no small job. > > "python setup.py install" doesn't have similar issues, I take it? > > Mat > > > On 20/11/12 11:40, Neal Becker wrote: > > The problem is that pip packages something as a dir where easy_install > packages as a file, or vice-versa. Then when you update, cpio will fail > (doesn't know how to replace a dir with a file, or vice-versa). Next, the > entire installation will abort!!!! Leaving you with a mess. > > I understand it's possible to manually then fix this mess using (some > obscure) yum incantations, but I don't recall what. Usually at this point > I wipe the disc. > > This has happened to me multiple times on multiple machines, and was > discussed at some length on fedora-dev list maybe 1 year ago. The basic > message was that I shouldn't use pip to install into the system dirs. But > even using pip --user is not answer, because pip will see that e.g., > matplotlib wants a newer version of pytz, and will attempt to remove the > system pytz (and fail and abort). > > The only reliable approach is virtualenv. Not really very satisfactory. > > > On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote: > >> Hi Neal, >> >> Is that due to conflicting package versions? I haven't suffered any >> particular issues like this yet, but it seems to me that pip would be >> improved if it interacted better with the environment it was in. How hard >> would it be to get pip to interact with yum and apt, for instance, to get >> valid binaries and/or devel files? >> >> I can't help thinking that Latex packaging is very similar, in that linux >> distributions often struggle to keep up, which I guess is why TexLive >> started. >> >> And then to complicate matters further, our sys admin said he didn't like >> pip as he would rather generate RPMs, in order that there is not a lot of >> work to do for system rebuilds in our labs. I found pypi2rpm, but that >> looks pretty bleeding edge and I think I'm getting out of my depth as a >> humble scientist. >> >> Mat >> >> On 19/11/12 12:59, Neal Becker wrote: >> >> Mathew Topper wrote: >> >> >> Hi, >> >> I'm interested to know why the pip package manager is not more widely >> supported for installation of python packages like matplotlib? >> Matplotlib seems to be particularly slowly updated in the Fedora >> repositories, for example, so I often find that a source installation is >> necessary. I know this isn't especially difficult for the experienced >> user, but surely using something like pip would make this process for >> accessible for all users of python packages, particularly those that do >> not receive much attention from the big distribution maintainers? Yet, >> pip doesn't get a mention on the installation documentation of >> matplotlib or many other python packs. >> >> I would love to hear anyone's thoughts on this matter. >> >> Many Thanks, >> >> Mat >> >> It is dangerous to use pip on fedora, it may result in your next attempt to >> update the system failing horribly. >> >> If you use it, try to install with --user. Unfortunately, this often won't work >> because pip will then complain when attempting to remove a system version of >> some dep. >> >> >> ------------------------------------------------------------------------------ >> Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Matplotlib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/matplotlib-users >> >> >> -- >> Dr. Mathew Topper >> Institute for Energy Systems >> School of Engineering >> The University of Edinburgh >> Faraday Building >> The King’s Buildings >> Edinburgh EH9 3JL >> Tel: +44 (0)131 650 5570 <%2B44%20%280%29131%20650%205570> >> School fax: +44 (0)131 650 6554 <%2B44%20%280%29131%20650%206554> >> mat...@ed... >> http://www.see.ed.ac.uk >> >> The University of Edinburgh is a charitable body, registered in >> Scotland, with registration number SC005336. >> >> > > -- > Dr. Mathew Topper > Institute for Energy Systems > School of Engineering > The University of Edinburgh > Faraday Building > The King’s Buildings > Edinburgh EH9 3JL > Tel: +44 (0)131 650 5570 > School fax: +44 (0)131 650 6554 > mat...@ed... > http://www.see.ed.ac.uk > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > |
|
From: Mathew T. <mat...@ed...> - 2012-11-20 12:04:31
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: Neal B. <ndb...@gm...> - 2012-11-20 11:41:07
|
The problem is that pip packages something as a dir where easy_install packages as a file, or vice-versa. Then when you update, cpio will fail (doesn't know how to replace a dir with a file, or vice-versa). Next, the entire installation will abort!!!! Leaving you with a mess. I understand it's possible to manually then fix this mess using (some obscure) yum incantations, but I don't recall what. Usually at this point I wipe the disc. This has happened to me multiple times on multiple machines, and was discussed at some length on fedora-dev list maybe 1 year ago. The basic message was that I shouldn't use pip to install into the system dirs. But even using pip --user is not answer, because pip will see that e.g., matplotlib wants a newer version of pytz, and will attempt to remove the system pytz (and fail and abort). The only reliable approach is virtualenv. Not really very satisfactory. On Tue, Nov 20, 2012 at 6:02 AM, Mathew Topper <mat...@ed...>wrote: > Hi Neal, > > Is that due to conflicting package versions? I haven't suffered any > particular issues like this yet, but it seems to me that pip would be > improved if it interacted better with the environment it was in. How hard > would it be to get pip to interact with yum and apt, for instance, to get > valid binaries and/or devel files? > > I can't help thinking that Latex packaging is very similar, in that linux > distributions often struggle to keep up, which I guess is why TexLive > started. > > And then to complicate matters further, our sys admin said he didn't like > pip as he would rather generate RPMs, in order that there is not a lot of > work to do for system rebuilds in our labs. I found pypi2rpm, but that > looks pretty bleeding edge and I think I'm getting out of my depth as a > humble scientist. > > Mat > > On 19/11/12 12:59, Neal Becker wrote: > > Mathew Topper wrote: > > > Hi, > > I'm interested to know why the pip package manager is not more widely > supported for installation of python packages like matplotlib? > Matplotlib seems to be particularly slowly updated in the Fedora > repositories, for example, so I often find that a source installation is > necessary. I know this isn't especially difficult for the experienced > user, but surely using something like pip would make this process for > accessible for all users of python packages, particularly those that do > not receive much attention from the big distribution maintainers? Yet, > pip doesn't get a mention on the installation documentation of > matplotlib or many other python packs. > > I would love to hear anyone's thoughts on this matter. > > Many Thanks, > > Mat > > It is dangerous to use pip on fedora, it may result in your next attempt to > update the system failing horribly. > > If you use it, try to install with --user. Unfortunately, this often won't work > because pip will then complain when attempting to remove a system version of > some dep. > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications!http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > -- > Dr. Mathew Topper > Institute for Energy Systems > School of Engineering > The University of Edinburgh > Faraday Building > The King’s Buildings > Edinburgh EH9 3JL > Tel: +44 (0)131 650 5570 > School fax: +44 (0)131 650 6554 > mat...@ed... > http://www.see.ed.ac.uk > > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > |
|
From: Phil E. <pel...@gm...> - 2012-11-20 11:23:27
|
The original question was raised in a mpl ticket: https://github.com/matplotlib/matplotlib/issues/1513 My original answer there (copied & pasted): The bbox_inches='tight' option to savefig does some analysis on the artists visible on your plot and figures out the minimum bounding box needed to fit all of the artists on the plot. In doing so, *it will reduce the size of the outputted image, rather than keeping the size and "zooming" in*. A really simple example to show this (not using basemap): >>> import matplotlib.pyplot as plt >>> fig = plt.figure(figsize=(3, 4)) >>> ax = plt.axes([0.4, 0.4, 0.2, 0.2]) >>> ax.plot(range(10)) >>> plt.savefig('figsize_no_tight.png') >>> plt.savefig('figsize_tight.png', bbox_inches='tight') $> file figsize_* figsize_no_tight.png: PNG image data, 300 x 400, 8-bit/color RGBA, non-interlaced figsize_tight.png: PNG image data, 98 x 123, 8-bit/color RGBA, non-interlaced *Matt has said that he doesn't think this addresses the issue *so anyone else with any ideas, please chip in! My suspicion is that what is being described is a combination of bbox_inches="tight" and a snapping issue relating to the fixed aspect (snapping here could be literally mpl snapping, or could simply be floating point problems). Hope someone else has some ideas about what is going on. Cheers, Phil On 20 November 2012 00:25, <sa...@ns...> wrote: > > Hi there, > > I've boiled down a problem and while the following my look useless, I need > to understand why matplotlib is behaving like it is. > > Below is code showing my issue. I don't believe the issue is with the > "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400, > but the last row is a row of transparent pixels(on linux/not mac). It's > difficult to see unless you use the imagemagik command display. > > The basic problem is that when my data has an aspect ratio very close to > 1.75, the image gets changed to one with an aspect of 1.74875. > > Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio. > Incorrect figure info => 800x1399 => 1.74875 > > Data that works aspect ratio: 1.7499999999999998 > Data that fails aspect ratio: 1.7499999999999996 > ---> Srsly?! -------------------------------^ > > It would be great if someone could explain to me what's happening if this > is indeed working as expected. If it's not, it would be great if someone > could fix it. > > Thanks in advance. > Matt > > > import matplotlib.pyplot as plt > > def create_image(): > # I want an 800x1400 image (aspect = 1400/800 = 1.75. > fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100) > > # Use the whole figure and fill with a patch. > fig.add_axes([0, 0, 1, 1]) > ax = plt.gca() > limb = ax.axesPatch > limb.set_facecolor('#6587ad') > > # Set some bounds with Aspects very close to the desired aspect ratios. > x1 = 0.0 > y1 = 0.0 > x2 = 16. > > # If you un-comment out this line (and comment the one below). I get > an image I expect > # y2 = 27.999999999999994671 # produces 800 x 1400 image > # aspect = 1.7499999999999998 works > > # Use this line and I get and image the wrong size (or with > transparent pixels.) > y2 = 27.999999999999994670 # produces (wrong?) 800 x 1399 image > # aspect = 1.7499999999999996 Fails? wat? > > corners = ((x1, y1), (x2, y2)) > ax.update_datalim(corners) > ax.set_xlim((x1, x2)) > ax.set_ylim((y1, y2)) > > ax.set_aspect('equal', anchor='C') > ax.set_xticks([]) > ax.set_yticks([]) > > plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight') > > # If you use this below, the file size is correct, but there is a > single > # line transparent pixels along the bottom of the image > > # plt.savefig('rectangle.png', pad_inches=0.0) > > > if __name__ == '__main__': > create_image() > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
|
From: Mathew T. <mat...@ed...> - 2012-11-20 11:02:42
|
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. |
|
From: Stephen G. <Ste...@an...> - 2012-11-20 06:14:50
|
I want to plot a series of (x,y) datasets similar to the
polygon plot tutorial example (add_collection3d),
but with a transparent facecolor and no baseline.
Setting alpha=0.0 in the tutorial example (below)
achieves the transparency, but the baseline remains.
Is there a way to remove the baseline?
Tks,
Steve.
from mpl_toolkits.mplot3d import Axes3D
from matplotlib.collections import PolyCollection
from matplotlib.colors import colorConverter
import matplotlib.pyplot as plt
import numpy as np
fig = plt.figure()
ax = fig.gca(projection='3d')
cc = lambda arg: colorConverter.to_rgba(arg, alpha=0.0)
xs = np.arange(0, 10, 0.4)
verts = []
zs = [0.0, 1.0, 2.0, 3.0]
for z in zs:
ys = np.random.rand(len(xs))
ys[0], ys[-1] = 0, 0
verts.append(list(zip(xs, ys)))
poly = PolyCollection(verts, facecolors = [cc('r'), cc('g'), cc('b'),
cc('y')])
#poly.set_alpha(0.7)
ax.add_collection3d(poly, zs=zs, zdir='y')
ax.set_xlabel('X')
ax.set_xlim3d(0, 10)
ax.set_ylabel('Y')
ax.set_ylim3d(-1, 4)
ax.set_zlabel('Z')
ax.set_zlim3d(0, 1)
|
|
From: <sa...@ns...> - 2012-11-20 00:59:44
|
Hi there,
I've boiled down a problem and while the following my look useless, I need to understand why matplotlib is behaving like it is.
Below is code showing my issue. I don't believe the issue is with the "bbox_inches='tight'", if you leave that off, my image is indeed, 800x1400, but the last row is a row of transparent pixels(on linux/not mac). It's difficult to see unless you use the imagemagik command display.
The basic problem is that when my data has an aspect ratio very close to 1.75, the image gets changed to one with an aspect of 1.74875.
Correct figure info 8x14@100dpi = 800x1400 => 1.75 Aspect Ratio.
Incorrect figure info => 800x1399 => 1.74875
Data that works aspect ratio: 1.7499999999999998
Data that fails aspect ratio: 1.7499999999999996
---> Srsly?! -------------------------------^
It would be great if someone could explain to me what's happening if this is indeed working as expected. If it's not, it would be great if someone could fix it.
Thanks in advance.
Matt
import matplotlib.pyplot as plt
def create_image():
# I want an 800x1400 image (aspect = 1400/800 = 1.75.
fig = plt.figure(1, figsize=(8, 14), frameon=False, dpi=100)
# Use the whole figure and fill with a patch.
fig.add_axes([0, 0, 1, 1])
ax = plt.gca()
limb = ax.axesPatch
limb.set_facecolor('#6587ad')
# Set some bounds with Aspects very close to the desired aspect ratios.
x1 = 0.0
y1 = 0.0
x2 = 16.
# If you un-comment out this line (and comment the one below). I get an image I expect
# y2 = 27.999999999999994671 # produces 800 x 1400 image
# aspect = 1.7499999999999998 works
# Use this line and I get and image the wrong size (or with transparent pixels.)
y2 = 27.999999999999994670 # produces (wrong?) 800 x 1399 image
# aspect = 1.7499999999999996 Fails? wat?
corners = ((x1, y1), (x2, y2))
ax.update_datalim(corners)
ax.set_xlim((x1, x2))
ax.set_ylim((y1, y2))
ax.set_aspect('equal', anchor='C')
ax.set_xticks([])
ax.set_yticks([])
plt.savefig('rectangle.png', pad_inches=0.0, bbox_inches='tight')
# If you use this below, the file size is correct, but there is a single
# line transparent pixels along the bottom of the image
# plt.savefig('rectangle.png', pad_inches=0.0)
if __name__ == '__main__':
create_image()
|
|
From: Eric F. <ef...@ha...> - 2012-11-19 23:53:21
|
On 2012/11/19 11:42 AM, TP wrote: > Hi everybody, > > I have a problem with LinearSegmentedColormap. > In the example below (see PS), I make a colormap, and use it to plot an > EllipseCollection. My plot is parameterized by a quantity that I have named > "large_value". For large_value equal to 257, a blue point is obtained at > (x=0.3, y=0.4). But for large_value equal to 258, it becomes black. > > This is because of the way LinearSegmentedColormap is working. It has a > parameter N which allows to set the "number of colors": > > http://matplotlib.org/api/colors_api.html#matplotlib.colors.LinearSegmentedColormap > > It is 256 by default, so if I increase N to a greater value, the point remains > blue for large_value equal to 258. > > Now, my real plot (not this dummy example) is such that I need N to be very > large so as to obtain the right colors on my plot, although very few colors > are used at the end. > However, when N is too large, the plot becomes very slow, and a lot of memory > is used; I think because an array is probably built with this size, although > in theory there is no need to construct such a complete array. > > Is there an easy workaround, or have I to study and modify the matplotlib code > myself? It is not entirely clear to me what you are trying to do, but it sounds like increasing N is not the right way to do it. Three things might help you find a better way: 1) The colormap is intended to work with a norm that handles the translation from your data numbers to the 0-1.0 range used to select values from the colormap (with exceptions--see below). You can choose a non-default norm, you can write your own, or you can set the parameters (vmin, vmax) of the standard linear norm. 2) By creating a colormap and calling its set_under, set_over, and set_invalid methods, you can control the colors assigned to data values that your norm maps respectively to negative numbers, numbers greater than 1, and masked values. See http://matplotlib.org/examples/pylab_examples/contourf_demo.html for an example of using set_under and set_over. See http://matplotlib.org/examples/pylab_examples/image_masked.html for another example, and for an example of controlling the norm parameters or using an alternative norm. 3) It is also possible to index directly into the colormap if you use a norm that returns an integer data type. An example of such is the BoundaryNorm. http://matplotlib.org/examples/pylab_examples/multicolored_line.html If all you need is a single assignment of a color to a "large value", then using the set_over method will take care of it. Eric > > Thanks, > > TP > > PS: Here is the test code: > ################## > from pylab import * > from matplotlib.colors import LinearSegmentedColormap > from matplotlib.collections import CircleCollection > > ioff() > large_value = 257 # blue below this value > #large_value = 258 # black above this value > N = 1e5 # 256 by default > > cdict = { 'blue': [(0.0, 0.0, 0.0), > (2*1/large_value, 1, 1) > , (1.0, 1.0, 1.0)] > , 'green': [(0.0, 0.0, 0.0), > (2*1/large_value, 0, 0) > , (1.0, 1.0, 1.0)] > , 'red': [(0.0, 0.0, 0.0), > (2*1/large_value, 0, 0), > (1.0, 1.0, 1.0)] } > > measures= array([[ 0.2, 0.3, 1], > [ 0.3, 0.4, 2], > [ 0.5, 0.6, large_value]]) > > cmap = LinearSegmentedColormap( "cmap foobar" > , cdict > # , N= N ) > ) > > fig = figure() > axes = fig.add_subplot(111) > ec = CircleCollection( [80] > , offsets = measures[:,:2] > , transOffset = axes.transData > ) > > ec.set_array( measures[:,2] ) > ec.set_cmap( cmap ) > axes.add_collection( ec ) > > show() > ################## > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
|
From: TP <par...@fr...> - 2012-11-19 21:43:00
|
Hi everybody, I have a problem with LinearSegmentedColormap. In the example below (see PS), I make a colormap, and use it to plot an EllipseCollection. My plot is parameterized by a quantity that I have named "large_value". For large_value equal to 257, a blue point is obtained at (x=0.3, y=0.4). But for large_value equal to 258, it becomes black. This is because of the way LinearSegmentedColormap is working. It has a parameter N which allows to set the "number of colors": http://matplotlib.org/api/colors_api.html#matplotlib.colors.LinearSegmentedColormap It is 256 by default, so if I increase N to a greater value, the point remains blue for large_value equal to 258. Now, my real plot (not this dummy example) is such that I need N to be very large so as to obtain the right colors on my plot, although very few colors are used at the end. However, when N is too large, the plot becomes very slow, and a lot of memory is used; I think because an array is probably built with this size, although in theory there is no need to construct such a complete array. Is there an easy workaround, or have I to study and modify the matplotlib code myself? Thanks, TP PS: Here is the test code: ################## from pylab import * from matplotlib.colors import LinearSegmentedColormap from matplotlib.collections import CircleCollection ioff() large_value = 257 # blue below this value #large_value = 258 # black above this value N = 1e5 # 256 by default cdict = { 'blue': [(0.0, 0.0, 0.0), (2*1/large_value, 1, 1) , (1.0, 1.0, 1.0)] , 'green': [(0.0, 0.0, 0.0), (2*1/large_value, 0, 0) , (1.0, 1.0, 1.0)] , 'red': [(0.0, 0.0, 0.0), (2*1/large_value, 0, 0), (1.0, 1.0, 1.0)] } measures= array([[ 0.2, 0.3, 1], [ 0.3, 0.4, 2], [ 0.5, 0.6, large_value]]) cmap = LinearSegmentedColormap( "cmap foobar" , cdict # , N= N ) ) fig = figure() axes = fig.add_subplot(111) ec = CircleCollection( [80] , offsets = measures[:,:2] , transOffset = axes.transData ) ec.set_array( measures[:,2] ) ec.set_cmap( cmap ) axes.add_collection( ec ) show() ################## |
|
From: Adam M. <ram...@gm...> - 2012-11-19 17:36:30
|
On Mon, Nov 19, 2012 at 7:44 AM, Nelle Varoquaux <nel...@gm...> wrote: > This is not the "correct" way to run the tests. Then that explains it, thanks. >> Does the same thing happen with the following command: >> >> python -c "import matplotlib; matplotlib.test()" No, all tests pass (or fail when they are expected to). > "KnownFailure" is not a "default" nosetest packages. Hence, we have to load > it manually when running the tests. Thanks, makes sense. Cheers Adam |
|
From: Sterling S. <sm...@fu...> - 2012-11-19 16:39:04
|
Chao,
I'm glad you were able to get what you wanted.
I don't know how to add anything to the gallery.
-Sterling
On Nov 17, 2012, at 3:32AM, Chao YUE wrote:
> Hi Sterling,
>
> Thanks for the help. Now we have a complete script that works as what we want:
>
> ****labels parallel with the colorbar with colorbar seperated ****
>
> By the way, is it possible to put in the gallery?
>
>
> from pylab import *
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> cs=contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks(cbarlevel)
>
> #prepare the final label that we want
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append(" {0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
>
> cbar.set_ticklabels(['']*len(cbarlevel)) #remove the original labels
> #set ticks as white; the 'length' parameter is a bit dirty solution
> cbar.ax.tick_params(axis='y',left='on',length=10,color='w',width=5)
> cbar.outline.remove() #remove the colorbar frame
>
> #add the label parallel to colorbar; 0.035 to be set by manual observation, a bit dirty solution.
> yloc=np.arange(0.035,0.95,0.1)
> for l,y in zip(cbar_label,yloc):
> cbar.ax.text(1,y,l,transform=cbar.ax.transAxes,ha='left')
>
> cheers,
>
> Chao
>
> On Sat, Nov 17, 2012 at 12:12 AM, Sterling Smith <sm...@fu...> wrote:
> Chao,
>
> If you don't need the tick marks and are only annoyed by their appearance in the colorbar, then I am pasting below our code so far setting the tick length to 0.
>
> Code so far:
>
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
>
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
>
> #Then to apply on the colorbar:
> cbar.set_ticklabels(cbar_label)
>
> ax = fig.axes[-1] #This is not as clean as making the axes before the colorbar and passing to the colorbar...
> ax.yaxis.set_tick_params(length=0)
>
>
> If you still want the ticks, then you might think of keeping the ticks where you had set them originally, then placing texts (pylab.text) with the transAxes transform, using the following script:
>
>
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> #cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> cbar.set_ticks(cbarlevel)
>
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> #cbar_label.append('')
>
> print cbar_label
> #['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> #'80-90', '90-100', '']
>
> #Then to apply on the colorbar:
> cbar.set_ticklabels(['']*len(cbarlevel))
>
> ax = fig.axes[-1]
> #ax.yaxis.set_tick_params(length=0)
>
> yloc = linspace(0,1,len(cbar_label)+1)
> yloc = yloc[:-1] + yloc[1]/2.
> for l,y in zip(cbar_label,yloc):
> ax.text(1,y,l,transform=ax.transAxes,ha='left')
> draw()
>
> -Sterling
>
> On Nov 16, 2012, at 12:58PM, Chao YUE wrote:
>
> > Thanks Sterling. It's a good idea.
> >
> > Unluckily, I lose the original ticks and the ticks appeared in the middle. Is there any approach I can keep the original ticks while realizing what has been shown in the figure?
> >
> > Chao
> >
> > On Fri, Nov 16, 2012 at 5:47 PM, Sterling Smith <sm...@fu...> wrote:
> > Chao,
> >
> > The secret is positioning your ticks. I list here an untested attempt at putting the labels at the average of the current and next levels:
> >
> > cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> >
> > Because you have less ticks, then you will want to remove the line
> >
> > cbar_level.append('')
> >
> > Hope that helps,
> > Sterling
> >
> > On Nov 16, 2012, at 7:46AM, ChaoYue wrote:
> >
> > > I have a bit progress, but still not very well.
> > >
> > > #to have a contourf plot
> > > a = np.arange(100).reshape(10,10)
> > > cbarlevel=np.arange(0,101,10)
> > > contourf(a,levels=cbarlevel)
> > > cbar = colorbar()
> > > cbar.set_ticks(cbarlevel)
> > >
> > > #to manipulate the range:
> > > cbar_label = []
> > > for i in range(len(cbarlevel)-1):
> > > cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> > > cbar_label.append('')
> > >
> > > In [54]: print cbar_label
> > > ['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> > > '80-90', '90-100', '']
> > >
> > > #Then to apply on the colorbar:
> > > cbar.set_ticklabels(cbar_label)
> > >
> > > The generated figure is attached. But how can I put the labels a little bit
> > > upward to make them parallel with the respective small rectangles in the
> > > colorbar? <http://matplotlib.1069221.n5.nabble.com/file/n39786/fig.jpg>
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context: http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39786.html
> > > Sent from the matplotlib - users mailing list archive at Nabble.com.
> > >
> > > ------------------------------------------------------------------------------
> > > Monitor your physical, virtual and cloud infrastructure from a single
> > > web console. Get in-depth insight into apps, servers, databases, vmware,
> > > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > > Pricing starts from $795 for 25 servers or applications!
> > > http://p.sf.net/sfu/zoho_dev2dev_nov
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> >
> > --
> > ***********************************************************************************
> > 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
> > ************************************************************************************
> >
> > <fig.jpg>
>
>
>
>
> --
> ***********************************************************************************
> 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
> ************************************************************************************
>
|
|
From: Nelle V. <nel...@gm...> - 2012-11-19 13:44:42
|
Hello, Hi >> >> When running the testsuite for matplotlib-1.2.0 i.e. >> >> $ nosetests -exe matplotlib >> > This is not the "correct" way to run the tests. You need to run them using: python tests.py I currently have a PR that indicates that in the README > I'm getting a lot of errors of the form: >> >> > Does the same thing happen with the following command: > > python -c "import matplotlib; matplotlib.test()" > That's another way of running the tests on matplotlib. > > I haven't used nosetest before, so I have no clue if it does anything > different than we expect. > "KnownFailure" is not a "default" nosetest packages. Hence, we have to load it manually when running the tests. Hence, all the tests that are known to fail actually fail, so that what we "expect". Cheers, N > > Ben Root > > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > |
|
From: Benjamin R. <ben...@ou...> - 2012-11-19 13:38:34
|
On Sun, Nov 18, 2012 at 5:51 PM, Adam Mercer <ram...@gm...> wrote: > Hi > > When running the testsuite for matplotlib-1.2.0 i.e. > > $ nosetests -exe matplotlib > > I'm getting a lot of errors of the form: > > Does the same thing happen with the following command: python -c "import matplotlib; matplotlib.test()" I haven't used nosetest before, so I have no clue if it does anything different than we expect. Ben Root |
|
From: Neal B. <ndb...@gm...> - 2012-11-19 12:59:56
|
Mathew Topper wrote: > Hi, > > I'm interested to know why the pip package manager is not more widely > supported for installation of python packages like matplotlib? > Matplotlib seems to be particularly slowly updated in the Fedora > repositories, for example, so I often find that a source installation is > necessary. I know this isn't especially difficult for the experienced > user, but surely using something like pip would make this process for > accessible for all users of python packages, particularly those that do > not receive much attention from the big distribution maintainers? Yet, > pip doesn't get a mention on the installation documentation of > matplotlib or many other python packs. > > I would love to hear anyone's thoughts on this matter. > > Many Thanks, > > Mat It is dangerous to use pip on fedora, it may result in your next attempt to update the system failing horribly. If you use it, try to install with --user. Unfortunately, this often won't work because pip will then complain when attempting to remove a system version of some dep. |
|
From: Adam M. <ram...@gm...> - 2012-11-18 22:52:11
|
Hi
When running the testsuite for matplotlib-1.2.0 i.e.
$ nosetests -exe matplotlib
I'm getting a lot of errors of the form:
======================================================================
ERROR: matplotlib.tests.test_dates.test_empty_date_with_year_formatter.test
----------------------------------------------------------------------
Traceback (most recent call last):
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py",
line 197, in runTest
self.test(*self.arg)
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 72, in test
self._func()
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py",
line 47, in failer
raise KnownFailureTest(msg) # An error here when running nose
means that you don't have the
matplotlib.testing.noseclasses:KnownFailure plugin in use.
KnownFailureTest: Test known to fail
----------------------------------------------------------------------
I would expect that these known tests should fail quietly. Shouldn't they?
Cheers
Adam
PS: I'm using python-2.7.3, nose-1.2.1 on Mac OS X 10.8.2 compiled
from MacPorts.
|
|
From: Ludwig S. <lud...@gm...> - 2012-11-18 19:53:58
|
Hi Russell, On Friday 16 November 2012 at 2:25 PM, Russell Owen wrote: > Unfortunately pip cannot install binaries, so any user that tried to > install matplotlib using pip would have to have a C compiler. > > Unfortunately many users do not have a compiler on MacOS and Windows. This is true, and an important advantage of the binary installer [1]. However, I would venture that most scientific users will have installed a compiler (at least on the Mac) - even accidentally, due to all the complicated installation procedures for many scientific software packages :-) > In addition, matplotlib has some important dependencies that may not be > available on all systems. MacOS now includes all necessary libraries. I > don't think that is true for most flavors linux (though there is > probably an easy way to get all missing packages). I have no idea about > Windows. > > (Does it even work with matplotlib? I've never tried it.) Pip works beautifully on the Mac since Lion, once you install pkg-config. This allows matplotlib to pick up the dependencies from the system (i.e. libpng, libfreetype and zlib). My shortest suggested route to Matplotlib on Lion is (assuming you have Homebrew installed): brew install pkg-config sudo pip install matplotlib The problem with pip / easy_install is that a lot of people assume that this is the standard way to install Python packages. I don't blame them - in fact, I would want all packages to be compatible with pip. It's not the greatest tool, given the pretty sorry state of Python packaging, but it is pretty much the simplest option from the command line. Best regards, Ludwig [1] For me the only downside of the installer is the use of Python.org Python instead of the default "system" Python, as the latter makes more sense to me for a standard installation (and avoids having multiple Pythons on your system, which is a Good Thing). Python.org Python used to be a mandatory install on older Mac systems such as Tiger / 10.3, but this is no longer a compelling argument for me on newer systems. |
|
From: Goyo <goy...@gm...> - 2012-11-17 19:40:24
|
2012/11/14 Skipper Seabold <jss...@gm...>: > Hi All, > > Hoping someone can help me get a definitive answer to this question. > Is draw_if_interactive bad to have in library plotting code? I think the only issue here is the overhead of importing the whole pyplot stuff and checking every now and then for interactive mode in code which is not mainly designed for interactive use. Something that I often do is writing non interactive plotting functions or methods and then wrappers for interactive use which call draw_if_interactive ant do other fancy things. Goyo > > Based on this thread [1], we've been working under the assumption that > calling draw_if_interactive in plotting code is bad. Though I'm > skeptical that this is the takeaway that we should have. I also asked > this question on the IPython mailing list [2] since the recommendation > comes from their type of usage, but I'm still not clear. > > I'll repeat the gist of the question here. > > We have plotting functions that are designed to update a given axes. I > often work in interactive mode, and I'd like it if these functions > updated my axes in the way that I expect (and an R user doing plotting > in Python would expect). But now I'm forced to litter my user scripts > with draw_if_interactive after I call a function I expect to update a > plot - say updating a scatter plot with a regression line. Would be > harmful to just include these draw_if_interactive calls in our plot > functions. To be clear, I never have to call show or draw because I'm > working in interactive mode, so the recommendation to just call show() > at the end of a script is not what I want. > > My understanding of the pitfalls is 1) there's a performance hit to > calling draw instead of just making one call. This is moot because > we're only calling draw_if_interactive - so we assume the user is > working interactively and actually wants to do the drawing and doesn't > care about the performance hit. And 2) we are assuming that the user > has imported and is using pyplot and there are possible side effects. > A user wouldn't be using pyplot in a GUI or in some sort of embedded > plotting framework. However, my intuition says that if this is the > case, draw_if_interactive won't do anything because interactive will > be False in these cases. > > Can someone please help clear this up? Thanks, > > Skipper > > > [1] https://groups.google.com/forum/#!msg/pystatsmodels/biNlCvJPNNY/BT7bQJmOa1cJ > [2] http://python.6.n6.nabble.com/IPython-User-using-matplotlib-draw-if-interactive-in-library-code-td4991275.html > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Ian T. <ian...@gm...> - 2012-11-17 14:32:54
|
On 16 November 2012 15:38, Bror Jonsson <bro...@gm...> wrote: > > Oh, I left out a line in the code, very sorry for that. Here is a full > example: > > import numpy as np > import pylab as pl > > #Generate a matrix populated with 1's > fld = np.ones((4,4)) > #Set one corner of the matrix to NaN > fld[:2,:2] = np.nan > #Plot the contourf plot of the matrix > pl.contourf(arange(4),arange(4),fld,colors='b') > #Create a mask where the NaN's are reversed. > mask = np.isnan(fld).astype(np.float) > mask[mask==0] = np.nan > #Plot the contourf of the mask > contourf(arange(4),arange(4),mask,colors='r') > > The cells with values in mask covers the cells with nan's in fld exactly: > > In [102]: print fld > Out[102]: > array([[ nan, nan, 1., 1.], > [ nan, nan, 1., 1.], > [ 1., 1., 1., 1.], > [ 1., 1., 1., 1.]]) > > > In [101]: print mask > Out[101]: > array([[ 1., 1., nan, nan], > [ 1., 1., nan, nan], > [ nan, nan, nan, nan], > [ nan, nan, nan, nan]]) > > > There are, however, a gap between the red and the blue areas in the > figure. Is there a way to make contourf plot mask so that the red patch > extends to 2,2 and covers all cells with 1's in mask? > > Many thanks! > > :-)Bror > Bror, The key to understanding this behaviour is to realise that your fld and mask values are defined at grid points, whereas contour deals with the quads that connect these grid points. If a single grid point is masked out, all 4 quads that the point is a corner of are masked out as far as contour is concerned as you cannot contour a quad that doesn't have all 4 points defined. You could solve your problem using contour but you would have to expand the mask so that each masked point [j,i] was expanded to [j-1:j+1, i-1:i+1]. I cannot think of a cunning numpy way of doing this whilst handling all the edge cases and would have to resort to explicit looping over the indices. There is a better way. From the point mask create a quad mask which is one smaller in each direction. Then use pcolor rather than contour as pcolor takes a quad-centric view of the world. Also, when dealing with masks I use numpy.ma rather than having to handle NaNs. Here is the simplest modification of your code that I can come up with to do what you want: import numpy as np import pylab as pl #Generate a matrix populated with 1's fld = np.ones((4,4)) #Set one corner of the matrix to NaN fld[:2,:2] = np.nan #Create a mask. mask = np.isnan(fld) #Expand mask so that it is a quad mask. mask = 1 - (mask[:-1,:-1] | mask[:-1,1:] | mask[1:,:-1] | mask[1:,1:]) #Create masked array. maskedArray = np.ma.array(np.zeros_like(mask), mask=mask) #Note mask is one smaller than fld in each direction. print 'fld.shape', fld.shape, 'mask.shape', mask.shape pl.contourf(np.arange(4), np.arange(4), fld, colors='b') #pcolor does what you want. Any colormap is chosen that has red as its first color. pl.pcolor(np.arange(4), np.arange(4), maskedArray, cmap='autumn') pl.show() Ian |
|
From: Chao Y. <cha...@gm...> - 2012-11-17 11:32:51
|
Hi Sterling,
Thanks for the help. Now we have a complete script that works as what we
want:
****labels parallel with the colorbar with colorbar seperated ****
By the way, is it possible to put in the gallery?
from pylab import *
a = np.arange(100).reshape(10,10)
cbarlevel=np.arange(0,101,10)
cs=contourf(a,levels=cbarlevel)
cbar = colorbar()
cbar.set_ticks(cbarlevel)
#prepare the final label that we want
cbar_label = []
for i in range(len(cbarlevel)-1):
cbar_label.append(" {0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
cbar.set_ticklabels(['']*len(cbarlevel)) #remove the original labels
#set ticks as white; the 'length' parameter is a bit dirty solution
cbar.ax.tick_params(axis='y',left='on',length=10,color='w',width=5)
cbar.outline.remove() #remove the colorbar frame
#add the label parallel to colorbar; 0.035 to be set by manual observation,
a bit dirty solution.
yloc=np.arange(0.035,0.95,0.1)
for l,y in zip(cbar_label,yloc):
cbar.ax.text(1,y,l,transform=cbar.ax.transAxes,ha='left')
cheers,
Chao
On Sat, Nov 17, 2012 at 12:12 AM, Sterling Smith <sm...@fu...>wrote:
> Chao,
>
> If you don't need the tick marks and are only annoyed by their appearance
> in the colorbar, then I am pasting below our code so far setting the tick
> length to 0.
>
> Code so far:
>
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
>
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
>
> #Then to apply on the colorbar:
> cbar.set_ticklabels(cbar_label)
>
> ax = fig.axes[-1] #This is not as clean as making the axes before the
> colorbar and passing to the colorbar...
> ax.yaxis.set_tick_params(length=0)
>
>
> If you still want the ticks, then you might think of keeping the ticks
> where you had set them originally, then placing texts (pylab.text) with the
> transAxes transform, using the following script:
>
>
> from pylab import *
> fig = figure(2)
> fig.clear()
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> #cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> cbar.set_ticks(cbarlevel)
>
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> #cbar_label.append('')
>
> print cbar_label
> #['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> #'80-90', '90-100', '']
>
> #Then to apply on the colorbar:
> cbar.set_ticklabels(['']*len(cbarlevel))
>
> ax = fig.axes[-1]
> #ax.yaxis.set_tick_params(length=0)
>
> yloc = linspace(0,1,len(cbar_label)+1)
> yloc = yloc[:-1] + yloc[1]/2.
> for l,y in zip(cbar_label,yloc):
> ax.text(1,y,l,transform=ax.transAxes,ha='left')
> draw()
>
> -Sterling
>
> On Nov 16, 2012, at 12:58PM, Chao YUE wrote:
>
> > Thanks Sterling. It's a good idea.
> >
> > Unluckily, I lose the original ticks and the ticks appeared in the
> middle. Is there any approach I can keep the original ticks while realizing
> what has been shown in the figure?
> >
> > Chao
> >
> > On Fri, Nov 16, 2012 at 5:47 PM, Sterling Smith <sm...@fu...>
> wrote:
> > Chao,
> >
> > The secret is positioning your ticks. I list here an untested attempt
> at putting the labels at the average of the current and next levels:
> >
> > cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
> >
> > Because you have less ticks, then you will want to remove the line
> >
> > cbar_level.append('')
> >
> > Hope that helps,
> > Sterling
> >
> > On Nov 16, 2012, at 7:46AM, ChaoYue wrote:
> >
> > > I have a bit progress, but still not very well.
> > >
> > > #to have a contourf plot
> > > a = np.arange(100).reshape(10,10)
> > > cbarlevel=np.arange(0,101,10)
> > > contourf(a,levels=cbarlevel)
> > > cbar = colorbar()
> > > cbar.set_ticks(cbarlevel)
> > >
> > > #to manipulate the range:
> > > cbar_label = []
> > > for i in range(len(cbarlevel)-1):
> > > cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> > > cbar_label.append('')
> > >
> > > In [54]: print cbar_label
> > > ['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> > > '80-90', '90-100', '']
> > >
> > > #Then to apply on the colorbar:
> > > cbar.set_ticklabels(cbar_label)
> > >
> > > The generated figure is attached. But how can I put the labels a
> little bit
> > > upward to make them parallel with the respective small rectangles in
> the
> > > colorbar? <http://matplotlib.1069221.n5.nabble.com/file/n39786/fig.jpg
> >
> > >
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39786.html
> > > Sent from the matplotlib - users mailing list archive at Nabble.com.
> > >
> > >
> ------------------------------------------------------------------------------
> > > Monitor your physical, virtual and cloud infrastructure from a single
> > > web console. Get in-depth insight into apps, servers, databases,
> vmware,
> > > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > > Pricing starts from $795 for 25 servers or applications!
> > > http://p.sf.net/sfu/zoho_dev2dev_nov
> > > _______________________________________________
> > > Matplotlib-users mailing list
> > > Mat...@li...
> > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> >
> >
> >
> >
> > --
> >
> ***********************************************************************************
> > 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
> >
> ************************************************************************************
> >
> > <fig.jpg>
>
>
--
***********************************************************************************
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
************************************************************************************
|
|
From: Sterling S. <sm...@fu...> - 2012-11-16 23:13:49
|
On Nov 16, 2012, at 2:25PM, Russell E. Owen wrote: > In article <50A...@ed...>, > Mathew Topper <mat...@ed...> wrote: > >> Hi, >> >> I'm interested to know why the pip package manager is not more widely >> supported for installation of python packages like matplotlib? >> Matplotlib seems to be particularly slowly updated in the Fedora >> repositories, for example, so I often find that a source installation is >> necessary. I know this isn't especially difficult for the experienced >> user, but surely using something like pip would make this process for >> accessible for all users of python packages, particularly those that do >> not receive much attention from the big distribution maintainers? Yet, >> pip doesn't get a mention on the installation documentation of >> matplotlib or many other python packs. >> >> I would love to hear anyone's thoughts on this matter. > > Unfortunately pip cannot install binaries, so any user that tried to > install matplotlib using pip would have to have a C compiler. > > Unfortunately many users do not have a compiler on MacOS and Windows. > > In addition, matplotlib has some important dependencies that may not be > available on all systems. MacOS now includes all necessary libraries. I > don't think that is true for most flavors linux (though there is > probably an easy way to get all missing packages). I have no idea about > Windows. > > I agree pip should be mentioned, but I don't see it as a viable > mainstream means of installing matplotlib. > > (Does it even work with matplotlib? I've never tried it.) > > -- Russell pip is the only method I have used in my Linux work. -Sterling > > > ------------------------------------------------------------------------------ > Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
|
From: Sterling S. <sm...@fu...> - 2012-11-16 23:12:42
|
Chao,
If you don't need the tick marks and are only annoyed by their appearance in the colorbar, then I am pasting below our code so far setting the tick length to 0.
Code so far:
from pylab import *
fig = figure(2)
fig.clear()
a = np.arange(100).reshape(10,10)
cbarlevel=np.arange(0,101,10)
contourf(a,levels=cbarlevel)
cbar = colorbar()
cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
#to manipulate the range:
cbar_label = []
for i in range(len(cbarlevel)-1):
cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
#Then to apply on the colorbar:
cbar.set_ticklabels(cbar_label)
ax = fig.axes[-1] #This is not as clean as making the axes before the colorbar and passing to the colorbar...
ax.yaxis.set_tick_params(length=0)
If you still want the ticks, then you might think of keeping the ticks where you had set them originally, then placing texts (pylab.text) with the transAxes transform, using the following script:
from pylab import *
fig = figure(2)
fig.clear()
a = np.arange(100).reshape(10,10)
cbarlevel=np.arange(0,101,10)
contourf(a,levels=cbarlevel)
cbar = colorbar()
#cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
cbar.set_ticks(cbarlevel)
#to manipulate the range:
cbar_label = []
for i in range(len(cbarlevel)-1):
cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
#cbar_label.append('')
print cbar_label
#['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
#'80-90', '90-100', '']
#Then to apply on the colorbar:
cbar.set_ticklabels(['']*len(cbarlevel))
ax = fig.axes[-1]
#ax.yaxis.set_tick_params(length=0)
yloc = linspace(0,1,len(cbar_label)+1)
yloc = yloc[:-1] + yloc[1]/2.
for l,y in zip(cbar_label,yloc):
ax.text(1,y,l,transform=ax.transAxes,ha='left')
draw()
-Sterling
On Nov 16, 2012, at 12:58PM, Chao YUE wrote:
> Thanks Sterling. It's a good idea.
>
> Unluckily, I lose the original ticks and the ticks appeared in the middle. Is there any approach I can keep the original ticks while realizing what has been shown in the figure?
>
> Chao
>
> On Fri, Nov 16, 2012 at 5:47 PM, Sterling Smith <sm...@fu...> wrote:
> Chao,
>
> The secret is positioning your ticks. I list here an untested attempt at putting the labels at the average of the current and next levels:
>
> cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
>
> Because you have less ticks, then you will want to remove the line
>
> cbar_level.append('')
>
> Hope that helps,
> Sterling
>
> On Nov 16, 2012, at 7:46AM, ChaoYue wrote:
>
> > I have a bit progress, but still not very well.
> >
> > #to have a contourf plot
> > a = np.arange(100).reshape(10,10)
> > cbarlevel=np.arange(0,101,10)
> > contourf(a,levels=cbarlevel)
> > cbar = colorbar()
> > cbar.set_ticks(cbarlevel)
> >
> > #to manipulate the range:
> > cbar_label = []
> > for i in range(len(cbarlevel)-1):
> > cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> > cbar_label.append('')
> >
> > In [54]: print cbar_label
> > ['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> > '80-90', '90-100', '']
> >
> > #Then to apply on the colorbar:
> > cbar.set_ticklabels(cbar_label)
> >
> > The generated figure is attached. But how can I put the labels a little bit
> > upward to make them parallel with the respective small rectangles in the
> > colorbar? <http://matplotlib.1069221.n5.nabble.com/file/n39786/fig.jpg>
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39786.html
> > Sent from the matplotlib - users mailing list archive at Nabble.com.
> >
> > ------------------------------------------------------------------------------
> > Monitor your physical, virtual and cloud infrastructure from a single
> > web console. Get in-depth insight into apps, servers, databases, vmware,
> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pricing starts from $795 for 25 servers or applications!
> > http://p.sf.net/sfu/zoho_dev2dev_nov
> > _______________________________________________
> > Matplotlib-users mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>
>
>
>
> --
> ***********************************************************************************
> 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
> ************************************************************************************
>
> <fig.jpg>
|
|
From: Russell E. O. <ro...@uw...> - 2012-11-16 22:25:32
|
In article <50A...@ed...>, Mathew Topper <mat...@ed...> wrote: > Hi, > > I'm interested to know why the pip package manager is not more widely > supported for installation of python packages like matplotlib? > Matplotlib seems to be particularly slowly updated in the Fedora > repositories, for example, so I often find that a source installation is > necessary. I know this isn't especially difficult for the experienced > user, but surely using something like pip would make this process for > accessible for all users of python packages, particularly those that do > not receive much attention from the big distribution maintainers? Yet, > pip doesn't get a mention on the installation documentation of > matplotlib or many other python packs. > > I would love to hear anyone's thoughts on this matter. Unfortunately pip cannot install binaries, so any user that tried to install matplotlib using pip would have to have a C compiler. Unfortunately many users do not have a compiler on MacOS and Windows. In addition, matplotlib has some important dependencies that may not be available on all systems. MacOS now includes all necessary libraries. I don't think that is true for most flavors linux (though there is probably an easy way to get all missing packages). I have no idea about Windows. I agree pip should be mentioned, but I don't see it as a viable mainstream means of installing matplotlib. (Does it even work with matplotlib? I've never tried it.) -- Russell |
|
From: Tony Yu <ts...@gm...> - 2012-11-16 21:35:06
|
On Fri, Nov 16, 2012 at 11:35 AM, Jon Ramsey <jon...@gm...> wrote: > Hi Everyone, > > I have just upgraded to matplotlib 1.2.0 so that I can use the streamplot > module, which I'm quite happy about! > However, I've noticed that when one tries to color the streamlines using a > 2-D array which contains NaNs, streamlines of only one color are shown! I > have appended example code below which reproduces the problem. > > Meanwhile, if the following two lines are inserted inside an "if > use_multicolor_lines:" region within streamplot.py, then the problem goes > away (for example, after line 84 or line 115): > if np.any(np.isnan(color)): > color = np.ma.array(color, mask=np.isnan(color)) > > This check already exists on the input arrays U and V, but not for color. > I am also not sure this issue will persist when a normalize object is > explicitly specified. > > Example code (derived from streamplot_demo.py): > > import numpy as np > import matplotlib.pyplot as plt > > Y, X = np.mgrid[-3:3:100j, -3:3:100j] > U = -1 - X**2 + Y > V = 1 + X - Y**2 > speed = np.sqrt(U*U + V*V) > > m = np.sqrt(X**2 + Y**2) < 1.0 > speed[m] = np.nan > > plt.streamplot(X, Y, U, V, color=speed, linewidth=2, cmap=plt.cm.autumn) > plt.colorbar() > plt.show() > > Additional info: > Linux 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64 > x86_64 x86_64 GNU/Linux > Matplotlib v1.2.0 > > > Best Regards, > > Jon Ramsey > > P.S. Long time reader, first time poster. > > Hi Jon, Welcome! This fix looks good to me. Since you mentioned that you're using the latest release, I assume you're not running matplotlib from github, so I filed a pull request with your fix: https://github.com/matplotlib/matplotlib/pull/1514 Thanks for the bug report and fix! -Tony |
|
From: Sterling S. <sm...@fu...> - 2012-11-16 16:47:41
|
Chao,
The secret is positioning your ticks. I list here an untested attempt at putting the labels at the average of the current and next levels:
cbar.set_ticks((cbarlevel[1:]+cbarlevel[:-1])/2.)
Because you have less ticks, then you will want to remove the line
cbar_level.append('')
Hope that helps,
Sterling
On Nov 16, 2012, at 7:46AM, ChaoYue wrote:
> I have a bit progress, but still not very well.
>
> #to have a contourf plot
> a = np.arange(100).reshape(10,10)
> cbarlevel=np.arange(0,101,10)
> contourf(a,levels=cbarlevel)
> cbar = colorbar()
> cbar.set_ticks(cbarlevel)
>
> #to manipulate the range:
> cbar_label = []
> for i in range(len(cbarlevel)-1):
> cbar_label.append("{0}-{1}".format(cbarlevel[i],cbarlevel[i+1]))
> cbar_label.append('')
>
> In [54]: print cbar_label
> ['0-10', '10-20', '20-30', '30-40', '40-50', '50-60', '60-70', '70-80',
> '80-90', '90-100', '']
>
> #Then to apply on the colorbar:
> cbar.set_ticklabels(cbar_label)
>
> The generated figure is attached. But how can I put the labels a little bit
> upward to make them parallel with the respective small rectangles in the
> colorbar? <http://matplotlib.1069221.n5.nabble.com/file/n39786/fig.jpg>
>
>
>
>
>
> --
> View this message in context: http://matplotlib.1069221.n5.nabble.com/how-to-put-colorbar-label-beside-the-handle-tp39705p39786.html
> Sent from the matplotlib - users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
|
|
From: Jon R. <jon...@gm...> - 2012-11-16 16:36:20
|
Hi Everyone,
I have just upgraded to matplotlib 1.2.0 so that I can use the streamplot
module, which I'm quite happy about!
However, I've noticed that when one tries to color the streamlines using a
2-D array which contains NaNs, streamlines of only one color are shown! I
have appended example code below which reproduces the problem.
Meanwhile, if the following two lines are inserted inside an "if
use_multicolor_lines:" region within streamplot.py, then the problem goes
away (for example, after line 84 or line 115):
if np.any(np.isnan(color)):
color = np.ma.array(color, mask=np.isnan(color))
This check already exists on the input arrays U and V, but not for color.
I am also not sure this issue will persist when a normalize object is
explicitly specified.
Example code (derived from streamplot_demo.py):
import numpy as np
import matplotlib.pyplot as plt
Y, X = np.mgrid[-3:3:100j, -3:3:100j]
U = -1 - X**2 + Y
V = 1 + X - Y**2
speed = np.sqrt(U*U + V*V)
m = np.sqrt(X**2 + Y**2) < 1.0
speed[m] = np.nan
plt.streamplot(X, Y, U, V, color=speed, linewidth=2, cmap=plt.cm.autumn)
plt.colorbar()
plt.show()
Additional info:
Linux 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Matplotlib v1.2.0
Best Regards,
Jon Ramsey
P.S. Long time reader, first time poster.
|