SourceForge logo
SourceForge logo
Menu

matplotlib-users — Discussion related to using matplotlib

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)




Showing 5 results of 5

From: Kornél J. <kja...@gm...> - 2010年11月14日 23:18:04
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
From: Benjamin R. <ben...@ou...> - 2010年11月14日 02:59:33
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
From: Michiel de H. <mjl...@ya...> - 2010年11月14日 01:58:36
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.
 
From: Michiel de H. <mjl...@ya...> - 2010年11月14日 01:50:34
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.
 
From: Benjamin R. <ben...@ou...> - 2010年11月14日 00:12:00
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

Showing 5 results of 5

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X





Briefly describe the problem (required):
Upload screenshot of ad (required):
Select a file, or drag & drop file here.
Screenshot instructions:

Click URL instructions:
Right-click on the ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)

More information about our ad policies

Ad destination/click URL:

AltStyle によって変換されたページ (->オリジナル) /