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) |
|
|
|
|
|
|
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.
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
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
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
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
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
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.
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.
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
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
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 >>> >>> >>> >