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
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
|
|
|
|
1
|
2
(2) |
3
(16) |
4
(22) |
5
(7) |
6
|
7
(9) |
8
(2) |
9
|
10
(7) |
11
(15) |
12
(7) |
13
(4) |
14
(7) |
15
(3) |
16
(6) |
17
(20) |
18
(18) |
19
(15) |
20
(27) |
21
(14) |
22
|
23
(1) |
24
(18) |
25
(22) |
26
(36) |
27
(17) |
28
(6) |
29
(2) |
30
(3) |
31
(6) |
|
|
|
|
|
From: Eric F. <ef...@ha...> - 2010-05-28 20:57:35
|
On 05/28/2010 09:10 AM, Richard Ree wrote: > On Fri, May 28, 2010 at 12:02 PM, Eric Firing wrote: >> On 05/28/2010 06:31 AM, Richard Ree wrote: >>> To visualize trees, I'm creating Path objects that draw horizontal and >>> vertical lines between connected nodes. I make sure to end these >>> paths with a MOVETO code and the final vertex, and a STOP code and the >>> final vertex. But I consistently see an anomalous line segment >>> getting rendered, angling between two disconnected nodes. The problem >>> is intermittent - if I pan or zoom, the anomalous segment might go >>> away or change position. It's also consistent - if I create two plots >>> of the same tree structure, the anomalous segment appears in the same >>> way. I've tried different backends, all the same. The attached >>> screenshots illustrate the problem. In each case, a detail of the >>> tree is shown in the right pane. path-artefact.png shows the >>> anomalous segment angling across the view. Any ideas on why this >>> occurs? I'm using the latest matplotlib release. >> >> Does it still happen if you turn off path simplification? E.g. >> >> rcParams['path.simplify'] = False > > Yes, this seems to fix it. Thanks! > > -Rick Good. I think this is one of the path simplification problems that has already been fixed in svn by Mike D. If you can build from svn and try your program without turning path simplification off, then we could be sure. Eric |
From: Richard R. <rr...@fi...> - 2010-05-28 19:10:37
|
On Fri, May 28, 2010 at 12:02 PM, Eric Firing wrote: > On 05/28/2010 06:31 AM, Richard Ree wrote: >> To visualize trees, I'm creating Path objects that draw horizontal and >> vertical lines between connected nodes. I make sure to end these >> paths with a MOVETO code and the final vertex, and a STOP code and the >> final vertex. But I consistently see an anomalous line segment >> getting rendered, angling between two disconnected nodes. The problem >> is intermittent - if I pan or zoom, the anomalous segment might go >> away or change position. It's also consistent - if I create two plots >> of the same tree structure, the anomalous segment appears in the same >> way. I've tried different backends, all the same. The attached >> screenshots illustrate the problem. In each case, a detail of the >> tree is shown in the right pane. path-artefact.png shows the >> anomalous segment angling across the view. Any ideas on why this >> occurs? I'm using the latest matplotlib release. > > Does it still happen if you turn off path simplification? E.g. > > rcParams['path.simplify'] = False Yes, this seems to fix it. Thanks! -Rick > > Eric > >> >> Thanks >> -Rick >> >> >> >> ------------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > |
From: Eric F. <ef...@ha...> - 2010-05-28 17:03:07
|
On 05/28/2010 06:31 AM, Richard Ree wrote: > To visualize trees, I'm creating Path objects that draw horizontal and > vertical lines between connected nodes. I make sure to end these > paths with a MOVETO code and the final vertex, and a STOP code and the > final vertex. But I consistently see an anomalous line segment > getting rendered, angling between two disconnected nodes. The problem > is intermittent - if I pan or zoom, the anomalous segment might go > away or change position. It's also consistent - if I create two plots > of the same tree structure, the anomalous segment appears in the same > way. I've tried different backends, all the same. The attached > screenshots illustrate the problem. In each case, a detail of the > tree is shown in the right pane. path-artefact.png shows the > anomalous segment angling across the view. Any ideas on why this > occurs? I'm using the latest matplotlib release. Does it still happen if you turn off path simplification? E.g. rcParams['path.simplify'] = False Eric > > Thanks > -Rick > > > > ------------------------------------------------------------------------------ > > > > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users |
From: Richard R. <rr...@fi...> - 2010-05-28 16:54:03
|
To visualize trees, I'm creating Path objects that draw horizontal and vertical lines between connected nodes. I make sure to end these paths with a MOVETO code and the final vertex, and a STOP code and the final vertex. But I consistently see an anomalous line segment getting rendered, angling between two disconnected nodes. The problem is intermittent - if I pan or zoom, the anomalous segment might go away or change position. It's also consistent - if I create two plots of the same tree structure, the anomalous segment appears in the same way. I've tried different backends, all the same. The attached screenshots illustrate the problem. In each case, a detail of the tree is shown in the right pane. path-artefact.png shows the anomalous segment angling across the view. Any ideas on why this occurs? I'm using the latest matplotlib release. Thanks -Rick |
From: T J <tj...@gm...> - 2010-05-28 08:16:11
|
On Thu, May 27, 2010 at 5:44 PM, Eric Firing <ef...@ha...> wrote: > You can't do this via any manipulation of the colormap, or any fancier > colormap specification--instead, you have to manipulate the data value. For > example, you could identify the "over" values in your data, and then use 2-D > interpolation to replace them with the values you want. > > Basemap includes a 2-D interpolation routine: > > from mpl_toolkits.basemap import interp > Thanks! >> >> This is partially achieved with "white" (and I suppose I could pick >> "grey" or "black"), but I think it might be nicer if it were a pure >> mixture, rather than a mixture of the surrounding colors and the >> "over" color. >> >> The script is attached below. Sorry it is a bit long, but I needed a >> discrete colormap. Can we get cmap_discrete() into matplotlib? > > No, because it doesn't make much sense, given the mpl paradigm in which a > colormap and a norm work together. If you want 4 colors, make a colormap > with 4 colors, and use a norm that maps your data to those 4 colors. > > For example: > > cm4 = get_cmap('jet', 4) > cm4a = mpl.colors.ListedColormap(get_cmap('jet', 256)([20, 70, 150, 200])) > > You can select any discrete set of colors you want using ListedColormap. > > Then you can use the default Normalize, or a custom BoundaryNorm, to map > data ranges to the colors. You just don't need a lookup table with 1024 > entries to specify 4 colors--it doesn't gain you anything. > Wonderful. Definitely makes the cookbook entry seem unnecessary |
From: Eric F. <ef...@ha...> - 2010-05-28 00:44:22
|
On 05/27/2010 01:58 PM, T J wrote: > On Thu, May 27, 2010 at 3:23 PM, Eric Firing<ef...@ha...> wrote: >> >> I'm not sure I understand the problem; could you provide a tiny example >> to illustrate? >> > > Sure, let me focus just on the interpolation and I'll leave the > filtering issue out. > > In the script below, I plot a 3x3 array with the center element having > an "over" value. In the default case, because its value is over, the > colormap will assign it the maximum color. I also plot the case when > the "over" color is explicitly set to the minimum color and also to > white. What I want is this: > > The center element should be an equal mixture of the 4 elements around it. You can't do this via any manipulation of the colormap, or any fancier colormap specification--instead, you have to manipulate the data value. For example, you could identify the "over" values in your data, and then use 2-D interpolation to replace them with the values you want. Basemap includes a 2-D interpolation routine: from mpl_toolkits.basemap import interp > > This is partially achieved with "white" (and I suppose I could pick > "grey" or "black"), but I think it might be nicer if it were a pure > mixture, rather than a mixture of the surrounding colors and the > "over" color. > > The script is attached below. Sorry it is a bit long, but I needed a > discrete colormap. Can we get cmap_discrete() into matplotlib? No, because it doesn't make much sense, given the mpl paradigm in which a colormap and a norm work together. If you want 4 colors, make a colormap with 4 colors, and use a norm that maps your data to those 4 colors. For example: cm4 = get_cmap('jet', 4) cm4a = mpl.colors.ListedColormap(get_cmap('jet', 256)([20, 70, 150, 200])) You can select any discrete set of colors you want using ListedColormap. Then you can use the default Normalize, or a custom BoundaryNorm, to map data ranges to the colors. You just don't need a lookup table with 1024 entries to specify 4 colors--it doesn't gain you anything. Eric > > ------------------ > > import matplotlib.pyplot as plt > import matplotlib.colors > > import numpy as np > from scipy import interpolate > > #### http://www.scipy.org/Cookbook/Matplotlib/ColormapTransformations > #### Can this be added to matplotlib? > def cmap_discretize(cmap, N): > """Return a discrete colormap from the continuous colormap cmap. > > cmap: colormap instance, eg. cm.jet. > N: Number of colors. > > Example > x = resize(arange(100), (5,100)) > djet = cmap_discretize(cm.jet, 5) > imshow(x, cmap=djet) > """ > > cdict = cmap._segmentdata.copy() > # N colors > colors_i = np.linspace(0,1.,N) > # N+1 indices > indices = np.linspace(0,1.,N+1) > for key in ('red','green','blue'): > # Find the N colors > D = np.array(cdict[key]) > I = interpolate.interp1d(D[:,0], D[:,1]) > colors = I(colors_i) > # Place these colors at the correct indices. > A = np.zeros((N+1,3), float) > A[:,0] = indices > A[1:,1] = colors > A[:-1,2] = colors > # Create a tuple for the dictionary. > L = [] > for l in A: > L.append(tuple(l)) > cdict[key] = tuple(L) > # Return colormap object. > return matplotlib.colors.LinearSegmentedColormap('colormap',cdict,1024) > > def draw(m, cm, norm, ncolors): > ax = plt.gca() > ai = ax.imshow(m, cmap=cm, norm=norm, interpolation='gaussian') > cb = ax.figure.colorbar(ai) > cb.set_ticks(np.linspace(.5, ncolors-.5, ncolors)) > cb.set_ticklabels(['$%s$' % (i,) for i in np.arange(ncolors)]) > return ai, cb > > if __name__ == '__main__': > ncolors = 4 > norm = plt.Normalize(vmax=ncolors) > m = np.array([[0, 0, 1], > [3, 10, 1], > [3, 2, 2]]) > > for over in [None, 'min', (1,1,1,1)]: > f = plt.figure() > cm = cmap_discretize(plt.cm.jet, ncolors) > if over == 'min': > cm.set_over(cm(0.0)) > elif over is not None: > cm.set_over(over) > ai, cb = draw(m, cm, norm, ncolors) > > plt.show() |