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
(8) |
2
(7) |
3
(8) |
4
(12) |
5
(1) |
|
6
(1) |
7
(9) |
8
(2) |
9
|
10
(1) |
11
|
12
(6) |
|
13
(6) |
14
(2) |
15
(7) |
16
(10) |
17
|
18
(3) |
19
(4) |
|
20
(4) |
21
(10) |
22
(8) |
23
(17) |
24
(13) |
25
(9) |
26
(1) |
|
27
(1) |
28
(4) |
29
(7) |
30
(2) |
31
(10) |
|
|
|
From: Tony Yu <ts...@gm...> - 2012-05-25 21:41:51
|
On Friday, May 25, 2012, Jerzy Karczmarczuk wrote: > Tony Yu: > > # rc definitions for dark backgrounds > > lines.color: white > patch.edgecolor: white > > ... > > don't forget to lighten the colours in axes.color_cycle (unless blue on > black, etc. suits you). This is used by plot and was one of my numerous > mistakes two days ago... > > Jerzy Karczmarczuk > > Indeed: blue on black is a fashion faux pas. ;) Also the default color_cycle has black in it, so it should be changed, regardless of aesthetic considerations. -Tony |
|
From: Jerzy K. <jer...@un...> - 2012-05-25 21:35:34
|
Tony Yu: > # rc definitions for dark backgrounds > > lines.color: white > patch.edgecolor: white ... don't forget to lighten the colours in axes.color_cycle (unless blue on black, etc. suits you). This is used by plot and was one of my numerous mistakes two days ago... Jerzy Karczmarczuk |
|
From: Tony Yu <ts...@gm...> - 2012-05-25 21:23:34
|
On Fri, May 25, 2012 at 4:07 PM, Tom Aldcroft <ald...@he... > wrote: > Is there a simple way to essentially invert the default plotting color > scheme so that the figure background is black and all text, ticks, > axes, axis labels, etc are white? I think what I want is to redefine > the RGB definitions of the standard color values 'b', 'y', 'k', etc so > that I can make a plot figure with a black background using the same > script as one for the normal white background. > > A spent a little while googling and didn't find anything apart from > specifically setting different colors for every single plot element. > This would be tiresome. > > Thanks in advance for any help, > Tom > > Hi Tom, You can create a custom matplotlibrc file [1] and use that for your plots. The settings you'd probably want to change are copied below. Note that not all plotting elements grab colors from rc parameters (unfortunately), so you may find that some functions will ignore these settings. I think the simplest way (currently) to use the rc file is by putting it in the same directory as your plotting script (or wherever you're executing your script). There's a pending pull request [2] that adds the ability to load rc parameters from a file. Also, I maintain a small set of matplotlib convenience functions, including a stylesheet-like function. I added the rc parameters below as a new style and added an example to the documentation [3]. Hope that helps, -Tony [1] http://matplotlib.sourceforge.net/users/customizing.html [2] https://github.com/matplotlib/matplotlib/pull/861 [3] http://tonysyu.github.com/mpltools/auto_examples/style/plot_dark_background.html # rc definitions for dark backgrounds lines.color: white patch.edgecolor: white text.color: white axes.facecolor: black axes.edgecolor: white axes.labelcolor: white xtick.color: white ytick.color: white grid.color: white figure.facecolor: black figure.edgecolor: black savefig.facecolor: black savefig.edgecolor: black |
|
From: Tom A. <ald...@he...> - 2012-05-25 20:07:58
|
Is there a simple way to essentially invert the default plotting color scheme so that the figure background is black and all text, ticks, axes, axis labels, etc are white? I think what I want is to redefine the RGB definitions of the standard color values 'b', 'y', 'k', etc so that I can make a plot figure with a black background using the same script as one for the normal white background. A spent a little while googling and didn't find anything apart from specifically setting different colors for every single plot element. This would be tiresome. Thanks in advance for any help, Tom |
|
From: AI <tri...@gm...> - 2012-05-25 16:51:23
|
Hi,
same problem with ipython 0.12 and matplotlib 1.1.1rc.
To recall, I'm trying to add a QT4 widget to a matplotlib figure (MPL is
using Qt4 as backend). However, in the attached example the widget callback
(or slot) is not called. Oddly, if I add the qt4 widget manually calling
qt4_interface() from ipython it works.
Basically I want to preserve the maplotlib+ipython interactive workflow,
but using some "enhanced" figures (i.e. mpl figure+qt4 widgets).
Thank you for any suggestion.
Antonio
2012/5/24 AI <tri...@gm...>
> Hi,
>
> I want to add a QT4 widget to a matplotlib figure, but the widget does not
> react to user input.
>
> Here it is a test case:
>
> from PyQt4 import QtGui, QtCore
> from pylab import *
>
> def test():
> plot([1,2,3], lw=2)
> qt4_interface(gcf())
>
> class qt4_interface:
> def __init__(self,fig):
> QMainWin = fig.canvas.parent()
> toolbar = QtGui.QToolBar(QMainWin)
> QMainWin.addToolBar(QtCore.Qt.BottomToolBarArea, toolbar)
>
> self.line_edit = QtGui.QLineEdit(parent=toolbar)
> self.line_edit.editingFinished.connect(self.do_something)
> toolbar.addWidget(self.line_edit)
>
> def do_something(self, *args):
> f = open('l','a'); f.write('yes\n'); f.flush(); f.close()
> #close()
>
> I run the script as "run -i qt4_test.py" from ipython. Then running test()
> I get the figure with the additional widget but the do_something method is
> never called.
>
> Incidentally if I do a plot from ipython and then I type interactively
> qt4_interface(gcf()), the qt4 widget is added to the figure and works
> properly.
>
> Any hints on how can I resolve this problem?
>
> BTW, I'm running matplotlib official package (1.0.1) included in ubuntu
> 11.10.
>
> Thanks,
> Antonio
>
>
>
>
|
|
From: Gordon H. <go...@rf...> - 2012-05-25 16:18:01
|
I am a matplotlib noob, but I have searched the documentation, lists etc
and cannot find a simple way to stop a curve being drawn once it crosses
another curve. In the attached example, I am trying to draw the solid
curve only until it intersects the dashed one. I have tried using the
numpy.where() method, but it does not seem to be the right way to go
about it- I end up having to write FOR loops and so on, and that does
not make use of the vectorization advantages of numpy. Seems like there
ought to be a simple way to do this.
Gordon
mport numpy as np
import matplotlib.pyplot as plt
def ig_CRM(vg,V,L,Ts):
return ((Ts*vg/(2*L))*(1-(vg/V)))
def ig_CCM(vg,V,L,Ts,d):
return (Ts*vg*d**2/(2*L))/(1-vg/V)
L= 110*10**-6
Ts= 10**-5
V= 400
vg= np.arange(0.0,400.0,1.0)
ig_bdry= ig_CRM(vg,V,L,Ts)
plt.plot(vg,ig_bdry,'--')
ig_d2=ig_CCM(vg,V,L,Ts,0.2)
plt.plot(vg,ig_d2)
plt.axis([0, 400, 0, 20])
plt.show()
|
|
From: Sergi P. F. <spo...@gm...> - 2012-05-25 08:30:53
|
> It seems that setting `interpolation='none'` is significantly slower than > setting it to 'nearest' (or even 'bilinear'). On supported backends (e.g. > any Agg backend) the code paths for 'none' and 'nearest' are different: > 'nearest' gets passed to Agg's interpolation routine, whereas 'none' does an > unsampled rescale of the image (I'm just reading the code comments here). > Could you check whether changing to `interpolation='nearest'` fixes this > issue? Yes, changing it really speeds-up the interactivity! The delay is now just a few ms, you can notice it's not completely smooth, but perfectly usable. I'll compare if when zoomed in any artifacts/distortion appear. Thank you! |
|
From: Jerzy K. <jer...@un...> - 2012-05-25 07:55:57
|
I wrote: > > mpl.rcParams['lines.color'] = 'r' > ... > ...the line is still blue. > BR answers: > > Plot() doesn't use lines.color. I don't remember the exact name, but > it uses an rcparam for color cycling. Just change make the list of > colors be just 'r'. [*!#!!%*!!] Of course I found that myself some time after reporting this "bug"... Sorry. The parameter is "axes.color_cycle" Jerzy K. |
|
From: Benjamin R. <ben...@ou...> - 2012-05-25 00:24:47
|
On Thursday, May 24, 2012, Jerzy Karczmarczuk wrote: > Gurus, > > Windows XP, matplotlib 1.1.0. Backend Tk, but the same elsewhere. > > Programme: > > import matplotlib as mpl > import matplotlib.pyplot as plt > mpl.rcParams['lines.linewidth'] = 2 > mpl.rcParams['lines.color'] = 'r' > > x=range(800) > y=[t for t in x] > plt.plot(x,y) > plt.show() > > # ============================== > Linewidth OK, equal to 2, but the line is still blue. Changing "r" to > red, or to #ff0000, or (1,0,0) doesn't change anything, still blue. > Changing directly the matplotlibrc file (default) - the same. Leaving in > peace the defaults, constructing another rc in the working dir - the > same. The dictionary rcParams contains the correct value > 'lines.color': 'r' > (Anyway, rcsetup.py validation doesn't protest. But then, the modified > colour is ignored). > > Somebody could confirm that? > > The best. > > Jerzy Karczmarczuk > Caen, France Plot() doesn't use lines.color. I don't remember the exact name, but it uses an rcparam for color cycling. Just change make the list of colors be just 'r'. Ben Root |