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
(5) |
2
(23) |
3
(17) |
4
(14) |
5
(12) |
6
(2) |
7
(3) |
8
(7) |
9
(13) |
10
(19) |
11
(24) |
12
(28) |
13
(9) |
14
(5) |
15
(7) |
16
(17) |
17
(17) |
18
(15) |
19
(6) |
20
|
21
(7) |
22
(20) |
23
(6) |
24
(4) |
25
(5) |
26
(11) |
27
(1) |
28
(2) |
29
(14) |
30
(7) |
|
|
|
|
Hello, I would like to plot the polarization state of a two-dimensional vector field (linear, circular or generally elliptic), similarly to that seen on this ZEMAX plot: http://www.zemax.com/UserFiles/Image/UI/pol_pupil.gif It looks like some kind of enhanced quiver plot: a small line with arrows at both ends points out the local direction of linear polarization, while a directed ellipse with a given orientation of its axes depicts local elliptical polarization state (which becomes a circle for circular polarization). I am a novice matplotlib user, please give me some advice on how to start with implementing such a plot (what to read, API examples to look at etc.) Thanks, Kornel JAHN
On Sat, Nov 13, 2010 at 7:58 PM, Michiel de Hoon <mjl...@ya...>wrote: > Thanks for your reply. > > Regarding your first question, how exactly does it disrupt your workflow? > Is it because the drawing takes too much time? Or because the focus switches > from the terminal window to the figure window? Or because the figure takes > up screen space? > > It is partly because the focus switches from the terminal window to the figure window (at least, at fiirst it does), but mostly because there isn't enough screen real estate for both to co-exist. Therefore, I would be alt-tabbing a lot if I am in interactive mode. Anyway, I mostly work from the perspective of running scripts and larger programs to generate publication quality figures and to perform data analyses. My focus is not on messing around with my figures. The only time I am doing that is when I am developing and testing a new script or feature, in which case I might go into interactive mode to figure out what settings and such make my figures look nice, or maybe not. It is nice to have the option to suit my needs. More often than not, I am in non-interactive mode. I see no reason to remove this feature as it puts matplotlib ahead of other systems like Matlab. Choice is a good thing... Ben Root
Thanks for your reply. Regarding your first question, how exactly does it disrupt your workflow? Is it because the drawing takes too much time? Or because the focus switches from the terminal window to the figure window? Or because the figure takes up screen space? Regarding the OP, my understanding is that the original issue is that with interactive=False, the MacOSX backend pops up a window while the other backends do not. It doesn't make a difference in running time, but anyway the different backends should behave the same way, so something needs to be done here. --Michiel. --- On Sat, 11/13/10, Benjamin Root <ben...@ou...> wrote: I would like to cast a vote of support for the "interactive=False" setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow. ... On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here.
Thanks for your reply. --- On Sat, 11/13/10, Eric Firing <ef...@ha...> wrote: > In the gtk backend, draw_idle calls gobject.idle_add > > Thus, "idle" means the gui event loop has no higher > priority events. Is > this condition reached only at the end of the script? With Python, there is only one thread (running both Python and the GUI). So the GUI event loop won't start until the end of the script, so there is no inadvertent redrawing regardless of interactive being True or False. With ipython, I am not sure if they are using one thread, or one thread for Python and one thread for the GUI. But in practice, in ipython I also don't find any evidence of inadvertent redrawing. For example, this script: import matplotlib matplotlib.use("gtkagg") import matplotlib.pyplot as plt import numpy x = numpy.random.random(400000) y = x + numpy.random.random(400000) plt.figure() plt.hexbin(x, y, gridsize=300) for i in range(1000): plt.xlabel('a label') plt.show() both with python and ipython take an equal amount of time regardless of interactive being True or False. If there were any redrawing after each call to plt.xlabel, this script would take forever. > Reminder: the interactive setting controls > draw_if_interactive, which is > what we are talking about here, but also whether or not > show() blocks. > So we may not need draw_if_interactive, but unless we can > dispense with > show entirely, we will still need an interactive setting. If matplotlib were always interactive, then I don't see a good reason for non-blocking show(). > Returning to the issue raised by the OP, however, the > question is > whether the present MacOSX behavior (windows pop up) or the > non-MacOSX > behavior (they don't in non-interactive mode until/unless > show() is > called) is what we really want. It seems to me that > we should preserve > some way of getting this second behavior. I agree. For example, if a user wants to make a figure for the sole purpose of creating a PNG file, there should be a way to do this without the figure popping up as a window. --Michiel.
On Sat, Nov 13, 2010 at 12:06 PM, Eric Firing <ef...@ha...> wrote: > On 11/13/2010 06:16 AM, Michiel de Hoon wrote: > > --- On Sat, 11/13/10, John Hunter<jd...@gm...> wrote: > >> Ie if we have a script like > >> > >> # some plotting commands > >> ... > >> > >> # some expensive non GUI computation > >> ... > >> > >> # some update to plot above > >> ... > >> > >> Would we not run the risk that the GUI is idle in the non > >> GUI computation and therefore trigger a draw in it's thread, > >> and then do redraws again after the update code? > > > > In the MacOSX backend, everything is single-threaded, so this won't > occur. > > > > I am not sufficiently familiar with the non-MacOSX backends to give a > detailed answer, but with multiple threads the "idle" refers to the Python > thread being idle rather than the GUI thread being idle. In other words, > when there are no more Python commands left to be handled, the GUI thread is > notified that it should start redrawing. > > > > In the gtk backend, draw_idle calls gobject.idle_add > > http://www.pygtk.org/pygtk2reference/gobject-functions.html#function-gobject--idle-add > > Thus, "idle" means the gui event loop has no higher priority events. Is > this condition reached only at the end of the script? > > > >> Are you proposing that we can get rid of the interactive setting > >> entirely, always call draw on pyplot commands, and let the > >> idle handler save us from doing repeated draws? > > Reminder: the interactive setting controls draw_if_interactive, which is > what we are talking about here, but also whether or not show() blocks. > So we may not need draw_if_interactive, but unless we can dispense with > show entirely, we will still need an interactive setting. > > Returning to the issue raised by the OP, however, the question is > whether the present MacOSX behavior (windows pop up) or the non-MacOSX > behavior (they don't in non-interactive mode until/unless show() is > called) is what we really want. It seems to me that we should preserve > some way of getting this second behavior. > > Eric > > > > > Yes (I assume you mean to always call draw_idle on pyplot commands). If > there are then still cases where we do get repeated draws, then that is a > bug. > > > > Best, > > --Michiel. > > > > I would like to cast a vote of support for the "interactive=False" setting. I often do work on my netbook, and having a figure window pop up while I am testing out some commands disrupts my workflow. When I want to see all my figures, I will call show() when I am good and ready. And just as I often do work on my netbook, I also do plenty of work on my workstation which sports a large screen. In many cases on that machine, I would like to see my figures while I am working on them, and having an easy option to turn that on and off is valuable to me. interactive : False was one of several reasons why I switched from Matlab to matplotlib. On the issue about the OP, I am a little bit confused as to what the exact issue is at hand. Is it that a figure window pops up in macosx backend regardless of the interactive setting? Or is it that non-macosx backends are not behaving the same way on a mac as they do on other systems? Is the issue that the plot window is blank on the macosx backend until the script finishes? I guess I am a little confused here. Ben Root