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
(14)
2
(11)
3
(5)
4
(17)
5
(11)
6
(37)
7
(35)
8
(9)
9
(1)
10
(9)
11
(7)
12
(22)
13
(34)
14
(24)
15
(27)
16
(13)
17
(19)
18
(43)
19
(36)
20
(12)
21
(9)
22
(21)
23
(3)
24
(5)
25
(30)
26
(14)
27
(23)
28
(19)
29
(19)
30
(10)
31
(6)






Showing 11 results of 11

From: Freddie W. <fr...@wi...> - 2009年05月02日 23:01:25
Attachments: PGP.sig
Hi all,
For those that are interested I have finally (now that my first batch 
of exams are finished) set-up a blog so that you can track the 
progress of the project.
My blog can be found here: http://gsoc-mathtex.blogspot.com/ (no marks 
for originality ;). I intend to update it on a semi-regular basis, 
time permitting.
Regards, Freddie.
From: John H. <jd...@gm...> - 2009年05月02日 22:21:59
On Sat, May 2, 2009 at 9:42 AM, Sandro Tosi <mo...@de...> wrote:
>
> Hi all!
> I'd like to embed a mpl graph into a GTK application (and for that
> embedding_in_gtk*.py examples are fine) but I would also like to
> dynamically update the graph with time.
>
> Consider like if I want to plot some dynamic system information, like
> cpu usage, memory occupation, or so. Than I want to gather those info
> at 1 sec interval, and dynamically update the graph adding the new
> values.
>
> How can I do it? I'm stuck with the "update data as they come" part
> (please note I need for GTK embedded mpl code).
The idioms in the examples/animations dir should be directly portable
to an embedded gtk app, eg simple_anim_gtk.py,
dynamic_image_gtkagg.py, etc.  You will need to either use an idle
handle, a timeout handler, or a special event in the gtk event
handling framework to trigger an update to the data and draw. You can
extend the gobject signals to handle custom events (eg data arrives)
if you want to go this route, but since you are trying to illustrate
mpl more than gtk (I assume) you may want to go the easy route and use
the timeout or idle handler and just check and see if new data has
arrived and then update as necessary.
>
> PS: if there's someone that knows how to gather cpu percentage usage
> on a linux sys, please tell me :) It seems not that easy to find it
> out from google ;)
http://tinyurl.com/d7lkga
Sorry :-) Couldn't resist (less obnoxious answer
http://www.cyberciti.biz/tips/how-do-i-find-out-linux-cpu-utilization.html)
JDH
From: John H. <jd...@gm...> - 2009年05月02日 22:07:02
On Sat, May 2, 2009 at 5:00 PM, Gideon Simpson <si...@ma...>wrote:
> I have two time series, {u_j} and {v_j}, with vastly different scales,
> but all sampled at the same times, {t_j}. Is there an easy way to
> plot the two on the same figure, with different vertical axes on the
> left and the right?
>
Take a look at twinx -- function doc and example links included below:
 http://matplotlib.sourceforge.net/examples/api/two_scales.html
http://matplotlib.sourceforge.net/api/axes_api.html#matplotlib.axes.Axes.twinx
JDH
From: Gideon S. <si...@ma...> - 2009年05月02日 22:00:18
I have two time series, {u_j} and {v_j}, with vastly different scales, 
but all sampled at the same times, {t_j}. Is there an easy way to 
plot the two on the same figure, with different vertical axes on the 
left and the right?
-gideon
From: Eric F. <ef...@ha...> - 2009年05月02日 19:27:34
Thomas Robitaille wrote:
> Not sure if this will help, but maybe you can do something like this?
> 
> ---
> #!/usr/bin/env python
> 
> from pylab import *
> from scipy import *
To run this as a standalone script, without ipython -pylab, you need to 
include:
ion()
> 
> img = standard_normal((40,40))
> image = imshow(img,interpolation='nearest',animated=True,label="blah")
> 
> for k in range(1,10000):
> img = standard_normal((40,40))
> image.set_data(img)
> show()
show() should never be called more than once for a given figure; what 
you want here is draw().
Eric
> ---
> 
> Note, interpolation='nearest' can be faster than interpolation=None if 
> your default interpolation is set to bicubic (which it probably is)
> 
> Does this speed things up?
> 
> Thomas
> 
> On May 1, 2009, at 3:31 PM, Joey Wilson wrote:
> 
>> I am creating a script that generates images and displays them to 
>> the screen in real time. I created the following simple script:
>>
>> __________________________
>>
>> #!/usr/bin/env python
>>
>> from pylab import *
>> from scipy import *
>>
>> for k in range(1,10000):
>> img = standard_normal((40,40))
>> imshow(img,interpolation=None,animated=True,label="blah")
>> clf()
>> show()
>>
>> __________________________
>>
>> Now, this script plots the image too slowly. I am forced to use 
>> the clf() function so that it doesn't slow down at each iteration of 
>> the for loop. Is there a way that I can plot this simple image 
>> faster? What's the best way to get imshow() to plot quickly? 
>> Thanks for your help.
>>
>> -Joey
>>
>> ------------------------------------------------------------------------------
>> Register Now & Save for Velocity, the Web Performance & Operations
>> Conference from O'Reilly Media. Velocity features a full day of
>> expert-led, hands-on workshops and two days of sessions from industry
>> leaders in dedicated Performance & Operations tracks. Use code 
>> vel09scf
>> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf_______________________________________________
>> Matplotlib-users mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
> 
> 
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations 
> Conference from O'Reilly Media. Velocity features a full day of 
> expert-led, hands-on workshops and two days of sessions from industry 
> leaders in dedicated Performance & Operations tracks. Use code vel09scf 
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
From: Thomas R. <tho...@gm...> - 2009年05月02日 18:13:30
Not sure if this will help, but maybe you can do something like this?
---
#!/usr/bin/env python
from pylab import *
from scipy import *
img = standard_normal((40,40))
image = imshow(img,interpolation='nearest',animated=True,label="blah")
for k in range(1,10000):
 img = standard_normal((40,40))
 image.set_data(img)
 show()
---
Note, interpolation='nearest' can be faster than interpolation=None if 
your default interpolation is set to bicubic (which it probably is)
Does this speed things up?
Thomas
On May 1, 2009, at 3:31 PM, Joey Wilson wrote:
> I am creating a script that generates images and displays them to 
> the screen in real time. I created the following simple script:
>
> __________________________
>
> #!/usr/bin/env python
>
> from pylab import *
> from scipy import *
>
> for k in range(1,10000):
> img = standard_normal((40,40))
> imshow(img,interpolation=None,animated=True,label="blah")
> clf()
> show()
>
> __________________________
>
> Now, this script plots the image too slowly. I am forced to use 
> the clf() function so that it doesn't slow down at each iteration of 
> the for loop. Is there a way that I can plot this simple image 
> faster? What's the best way to get imshow() to plot quickly? 
> Thanks for your help.
>
> -Joey
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code 
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf_______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
From: Thomas R. <tho...@gm...> - 2009年05月02日 18:03:52
There was a typo in the script, the callbacks should be
ax.name = "first axis" 
ax.callbacks.connect('xlim_changed',check_callback) 
ax.callbacks.connect('ylim_changed',check_callback) 
ax2 = ax.twin() 
ax2.name = "second axis" 
ax2.callbacks.connect('xlim_changed',check_callback) 
ax2.callbacks.connect('ylim_changed',check_callback) 
but the problem remains: check_callback is never called for ax2.
Tom
-- 
View this message in context: http://www.nabble.com/Enforcing-common-view-limits-tp23334325p23348806.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
From: Thomas R. <tho...@gm...> - 2009年05月02日 16:40:39
I've realized that using the ParasiteAxes from the mpl_toolkits should do
exactly what I'm asking. However, I am having a problem with callbacks when
the x and y limits change (try resizing the window). The following script
shows that the callback for the second set of axes is not carried out. Is
this a bug, or a limitation? Or something I'm doing wrong?
Thanks!
Thomas
---
import matplotlib.pyplot as mpl
import numpy as np
import mpl_toolkits.axes_grid.parasite_axes as mpl_toolkit
def check_callback(ax):
 print "callback for ",ax.name
 
array = np.random.random((100,100))
fig = mpl.figure()
ax = mpl_toolkit.SubplotHost(fig,1,1,1,adjustable='datalim')
ax.name = "first axis"
ax.callbacks.connect('xlim_changed',check_callback)
ax.callbacks.connect('xlim_changed',check_callback)
ax2 = ax.twin()
ax2.name = "second axis"
ax2.callbacks.connect('ylim_changed',check_callback)
ax2.callbacks.connect('ylim_changed',check_callback)
fig.add_axes(ax)
ax.imshow(array,interpolation='nearest')
fig.canvas.draw()
---
-- 
View this message in context: http://www.nabble.com/Enforcing-common-view-limits-tp23334325p23348018.html
Sent from the matplotlib - users mailing list archive at Nabble.com.
From: Sandro T. <mo...@de...> - 2009年05月02日 14:42:43
Hi all!
I'd like to embed a mpl graph into a GTK application (and for that
embedding_in_gtk*.py examples are fine) but I would also like to
dynamically update the graph with time.
Consider like if I want to plot some dynamic system information, like
cpu usage, memory occupation, or so. Than I want to gather those info
at 1 sec interval, and dynamically update the graph adding the new
values.
How can I do it? I'm stuck with the "update data as they come" part
(please note I need for GTK embedded mpl code).
Thanks in advance,
Sandro
PS: if there's someone that knows how to gather cpu percentage usage
on a linux sys, please tell me :) It seems not that easy to find it
out from google ;)
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
From: Thomas R. <tho...@gm...> - 2009年05月02日 00:39:46
Thanks!
Thomas
On 1 May 2009, at 15:04, Eric Firing wrote:
> Christopher Barker wrote:
>> Eric Firing wrote:
>>> Split the command up:
>>> p = Circle(...)
>>> ax.add_patch(p, ...)
>>>
>>> (add_* could be modified to return the reference; maybe this would 
>>> be
>>> worthwhile.)
>>
>> +1
>>
>>
>>
>
> Done in r7077.
>
> Eric
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code 
> vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
From: Thomas R. <tho...@gm...> - 2009年05月02日 00:39:32
The patch seems to work - the MacOSX backend now displays the same 
font size as the other backends.
Thanks!
Thomas
On 1 May 2009, at 14:06, Michael Droettboom wrote:
> Michiel de Hoon provided a patch for this which I just applied to 
> the trunk.
>
> As I don't have a Mac, I can't test it -- any feedback is welcome.
>
> Mike
>
> Jae-Joon Lee wrote:
>> Thomas,
>> As John suggested before, please check if the size differences go 
>> away
>> if you use the same dpi, actually dpi=72.
>>
>> After some quick look, it seems that the osx backend does not scale
>> the font size correctly respecting the dpi.
>> At line 124 of bacend_macosx.py,
>>
>> size = prop.get_size_in_points()
>> weight = prop.get_weight()
>> style = prop.get_style()
>> gc.draw_text(x, y, unicode(s), family, size, weight, 
>> style, angle)
>>
>> My quick guess is that replacing
>>
>> size => size*self.dpi/72.
>>
>> in the last call may solve the problem. Since I don't use the osx
>> backend, I wonder if others can test this.
>>
>> -JJ
>>
>>
>> On Thu, Apr 30, 2009 at 9:32 AM, Michael Droettboom 
>> <md...@st...> wrote:
>>
>>> I forwarded this message to Michiel de Hoon, the author of the Mac 
>>> OS-X
>>> backend, in case he has any thoughts.
>>>
>>> Mike
>>>
>>> Thomas Robitaille wrote:
>>>
>>>> Hi Jae-Jong and John,
>>>>
>>>> Thanks for your replies! While experimenting with this to send
>>>> screenshots, I realized that my default backend was set to 
>>>> MacOSX, not
>>>> WXAgg. The WXAgg output to the screen actually agrees with the 
>>>> PNG output in
>>>> terms of font sizes. But the font sizes differ between the MacOSX 
>>>> and WXAgg
>>>> backends. Attached are screenshots using the MacOSX and WXAgg 
>>>> backends. You
>>>> can see the font size is different. Is this a bug?
>>>>
>>>> Thanks,
>>>>
>>>> Thomas
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> On 29 Apr 2009, at 00:24, Jae-Joon Lee wrote:
>>>>
>>>>
>>>>> On Tue, Apr 28, 2009 at 11:09 PM, John Hunter 
>>>>> <jd...@gm...> wrote:
>>>>>
>>>>>> If you want the relative fontsizes in the figure window and 
>>>>>> saved figure
>>>>>> to
>>>>>> agree, pass the same "dpi" to the figure command and savefig 
>>>>>> command.
>>>>>>
>>>>> John,
>>>>> I thought the font size (which is specified in points) is 
>>>>> independent
>>>>> of dpi, i.e., font size in "pixel" actually scales with the dpi. I
>>>>> think it should be filed as a bug if the relative font size 
>>>>> depends on
>>>>> the dpi.
>>>>>
>>>>> Anyhow, I just did a quick test and the (relative) font size 
>>>>> does not
>>>>> seem to vary with dpi.
>>>>>
>>>>> Thomas,
>>>>> What version of mpl are you using?
>>>>> With the mpl from the svn trunk, I don't see any significant 
>>>>> change as
>>>>> you described.
>>>>> The WxAgg figure and the png output are actually drawn by an 
>>>>> identical
>>>>> backend, so there should be no significant difference. There can 
>>>>> be
>>>>> some subtle difference due to different dpi, but I don't see a
>>>>> difference as large as 30%. Can you post a some sample images? 
>>>>> i.e., a
>>>>> screenshot of WxAgg figure and the png output.
>>>>>
>>>>> I can see that the text in pdf output occupies a bit larger area 
>>>>> than
>>>>> png (when usetex=False), but, to me, this seems to be due to 
>>>>> different
>>>>> amount of kernings (it seems that no kerning is applied for pdf 
>>>>> text)
>>>>> instead of different font size.
>>>>>
>>>>> So, can you first check if the difference goes away when you use 
>>>>> same
>>>>> dpi as John suggested? And if that is the case, can you try the 
>>>>> latest
>>>>> svn and check if the relative font size still depends on the dpi?
>>>>>
>>>>> Regards,
>>>>>
>>>>> -JJ
>>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Register Now & Save for Velocity, the Web Performance & Operations
>>>> Conference from O'Reilly Media. Velocity features a full day of 
>>>> expert-led,
>>>> hands-on workshops and two days of sessions from industry leaders 
>>>> in
>>>> dedicated Performance & Operations tracks. Use code vel09scf and 
>>>> Save an
>>>> extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Matplotlib-users mailing list
>>>> Mat...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>>>>
>>>>
>>> --
>>> Michael Droettboom
>>> Science Software Branch
>>> Operations and Engineering Division
>>> Space Telescope Science Institute
>>> Operated by AURA for NASA
>>>
>>>
>>>
>

Showing 11 results of 11

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 によって変換されたページ (->オリジナル) /