You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
|
2
|
3
(2) |
4
|
5
|
6
|
7
|
8
|
9
(2) |
10
(5) |
11
|
12
(1) |
13
|
14
|
15
(3) |
16
|
17
(3) |
18
(9) |
19
|
20
(2) |
21
|
22
|
23
(7) |
24
(4) |
25
(1) |
26
|
27
|
28
(1) |
29
(1) |
30
|
31
(12) |
|
|
On 5/23/07, John Hunter <jd...@gm...> wrote: > I seem to be getting some corner artifacts when using *Agg that I > haven't seen before. Anyone else seeing something strange and any > idea why? Glad you wrote this, I was about to. I noticed them only recently, and they're driving me nuts. They aren't just corners, they have to do with the overlap of two lines and Agg messing something up when thick lines overlap. Here's an example that illustrates it more easily (that's how I ran into it): import numpy as N from pylab import figure, show t = N.linspace(-1.0, 1.0, 2001) s = N.exp(-300*N.abs(t)) fig = figure() ax = fig.add_subplot(111) ax.plot(t, s, '-', lw=2) show() ### Plot this, then click on the little zoom tool (the cross) and do a horizontal right-mouse motion to widen/tighten the exponential. You'll see the white artifact move across the region of overlap of the vertical lines. Fortunately for me, the generated EPS don't have the problem (it's a pure Agg bug), so I'm OK for the final output. But it's really annoying on screen. My plots have tons of nearly retracing lines on them, and they look atrociously bad now. Cheers, f
On Wed, May 23, 2007 at 03:15:45PM -0500, John Hunter wrote: > I seem to be getting some corner artifacts when using *Agg that I > haven't seen before. Anyone else seeing something strange and any > idea why? I started seeing them with the QtAgg backend when I updated the svn version I was using. That was about 2 weeks ago, and the previous version was about 6 weeks old, at that point. Glen
John Hunter wrote: > I seem to be getting some corner artifacts when using *Agg that I > haven't seen before. Anyone else seeing something strange and any > idea why? > > import numpy > > from pylab import figure, show > > t = numpy.arange(0.0, 1.0, 0.1) > s = numpy.ones(len(t), dtype=numpy.float_) > s[1::2] = 0. > > fig = figure() > ax = fig.add_subplot(111) > ax.plot(t, s, '-', lw=2) > ax.set_ylim(-.5, 1.5) > show() Confirmed with GTKAgg on OS X, latest svn (but not with 0.90). No idea why though. -Jeff -- Jeffrey S. Whitaker Phone : (303)497-6313 Meteorologist FAX : (303)497-6449 NOAA/OAR/PSD R/PSD1 Email : Jef...@no... 325 Broadway Office : Skaggs Research Cntr 1D-124 Boulder, CO, USA 80303-3328 Web : http://tinyurl.com/5telg
Works for me, python 2.4, matplotlib 0.90.0, .matplotlibrc: numerix: numpy backend: GTKAgg even with lw=20 John Hunter wrote: > I seem to be getting some corner artifacts when using *Agg that I > haven't seen before. Anyone else seeing something strange and any > idea why? > > import numpy > > from pylab import figure, show > > t = numpy.arange(0.0, 1.0, 0.1) > s = numpy.ones(len(t), dtype=numpy.float_) > s[1::2] = 0. > > fig = figure() > ax = fig.add_subplot(111) > ax.plot(t, s, '-', lw=2) > ax.set_ylim(-.5, 1.5) > show() > -- Tom Holroyd, Ph.D. "The fundamentally misconceived nature versus nurture debate should be abandoned: child development is inextricably both." -- Louann Brizendine
I seem to be getting some corner artifacts when using *Agg that I haven't seen before. Anyone else seeing something strange and any idea why? import numpy from pylab import figure, show t = numpy.arange(0.0, 1.0, 0.1) s = numpy.ones(len(t), dtype=numpy.float_) s[1::2] = 0. fig = figure() ax = fig.add_subplot(111) ax.plot(t, s, '-', lw=2) ax.set_ylim(-.5, 1.5) show()
Timothy wrote: > Please let me know if there is a > better way to submit the code. > Hi Timothy, If you make it into a complete example that plots something, send it as an attachment to the list (so their are no line-break issues), I will commit it into the examples directory. From there, we can figure out where the key dendrogram() function should live, but at least your work will get in the repository as soon as possible. -Andrew
I've spent some time on this problem and have a 44 line solution for generating dendrogram line segments and root ending locations, i.e. x and y values. The format for cluster information is a nested tuple like this: cluster=(4.5,(3.0,'c',(1.0,'a','b')),(2.0,'e',(1.5,'f','g'))) where the FP numbers are distance information and the strings are the names of the items being clustered. The code can also handle cluster data without distance information, by assuming a fixed distance of 1.0: cluster=(('c',('a','b')),('e',('f','g'))) The output is a list of root location and value tuples: (x,y,item) and a list of dendrogram line segment tuples: (x1,y1,x2,y2). I've purposely avoided recursion back into the function by using list stacks because I'm always a little leery of how much space is available on the [virtual] machine stack. Note that this code has not been extensively tested. One limitation on this dendrogram code is that only pairs of objects may be clustered together at a time. Obviously a lot of work would need to be done to apply these data to a Matplotlib plot, but I don't know how to do it. The output could also be used to generate images in SVG, Postscript, mechanical plotters, or any other vector oriented graphical system. Anyway, FWIW, my code is listed, below. I'm sure it can be improved upon. In hopes of someone doing something useful for others with it, I hereby release it under the Matplotlib license, while retaining the copyright for my own additional use. Please let me know if there is a better way to submit the code. --Tim import sys def dendrogram(ctree,hasDistances='yes',yincr=1.0): stype=type("") tstack=[ctree[:]] ## make a copy nstack=[] ## node stack baselist=[] linelist=[] y=0.0 while len(tstack)>0: tob=tstack.pop() if hasDistances=='yes': dist=tob[0] tob=tob[1:] elif hasDistances=='ignore': dist=1.0 tob=tob[1:] elif hasDistances=='no': dist=1.0 else: raise Exception("unknown value '%s' for named argument 'hasDistances'" % self.hasDistances) obflag=False for ob in tob: if type(ob)==stype: baselist.append( (0.0,y,ob) ) nstack.append( (0.0,y,dist) ) y+=yincr else: tstack.append(ob) obflag=True if obflag: nstack.append((dist,)) while len(nstack)>1 and len(nstack[-1])>1 and len(nstack[-2])>1: x1,y1,d1=nstack.pop() x2,y2,d2=nstack.pop() if d1>d2: d=d1 else: d=d2 if x1>x2: xnew=x1+d else: xnew=x2+d ynew=(y1+y2)/2.0 linelist.append((x1,y1,xnew,y1)) linelist.append((x2,y2,xnew,y2)) linelist.append((xnew,y1,xnew,y2)) if len(nstack)>0 and len(nstack[-1])<=1: dist=nstack.pop()[0] nstack.append( (xnew,ynew,dist) ) return baselist,linelist if __name__=="__main__": baselist,linelist=dendrogram( (4.5,(3.0,'c',(1.0,'a','b')),(2.0,'e',(1.5,'f','g'))) ) print baselist print print linelist Jouni K. Seppänen wrote: > Timothy <te...@xm...> writes: > > >> It appears matplotlib does not have a dendrogram plot. I may be >> interested in developing one, if I can get a sense for what it would >> take. Could someone suggest some code I could look at as a model for >> developing a new plot? >> > > In the file axes.py, search for the comment "Specialized plotting" and > look at the functions after that. The first function is "bar", which > looks quite complicated, but perhaps "stem" would be a good starting > point. > >