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
(2) |
2
(32) |
3
(26) |
4
(29) |
5
(41) |
6
(2) |
7
(1) |
8
(13) |
9
(15) |
10
(23) |
11
(23) |
12
(16) |
13
(6) |
14
(15) |
15
(4) |
16
(18) |
17
(28) |
18
(17) |
19
(11) |
20
(6) |
21
(2) |
22
(4) |
23
(1) |
24
|
25
|
26
(1) |
27
(2) |
28
(2) |
29
(3) |
30
(10) |
31
(2) |
|
|
|
Hi Jianbao, I used to try and install my python suite from src code on my own. Somewhere between the Mac OS 10.5, 10.6, migrating accounts, my python installation broke, and I never could get it all working again. Something related to 10.6 didn't have full backwards compatibility because of the switch to 64 bit architecture, so my binaries stopped working... many long frustrating days trying to figure it out. I eventually went to a friend of mine who does computing support for an astrophysics group, to get help solving my installation problems. He said, "Do you know about the Enthought python distribution?" So that changed my philosophy. If my computer-wiz-friend uses Enthought, I have no excuse not to. I have been happier ever since :) Also - I have recently come to love HDF5 (Hierarchical Data Format (Version) 5), which is a smart binary database with smart metadata mapping (maybe good for your research). Eg. on the big machines at NERSC, Livermore, Argonne, etc (meaning next generation super computers) HDF5 is one of the pieces of software they use to benchmark the performance of their file systems, and make sure this code scales to work with these new architectures. HDF5 is also professionally maintained. And the Enthought distribution comes with HDF5 and two python interfaces to it. From your description, I thought maybe you guys already use this. And if not, maybe it is worth looking into. Cheers, Andre On Oct 8, 2012, at 11:32 AM, Jianbao Tao wrote: > Hi Andre, > > Thanks for your message. I like it. :-) > > I do have a .edu email. I didn't try to install Chaco with EPD because I tend to be skeptical when it comes to a bundled package with a lot of stuff. I like it to be as simple as possible. But it seems that I am probably better off to install EPD as a whole. > > Cheers, > Jianbao > > On Mon, Oct 8, 2012 at 11:17 AM, Andre' Walker-Loud <wal...@gm...> wrote: > Hi Jianbao, > > One option for getting Chaco is to install the Enthought python disctribution > > http://www.enthought.com/ > > you can see from their package index, they install Chaco (and all needed libraries to make it work) > > http://www.enthought.com/products/epdlibraries.php > > If you have an email ending in ".edu" you can automatically get their academic version (fully functioning version - you just have to verify you are doing academic research). Since you mentioned you were at UC Berkeley, I assume you have .edu. > Their python installation works nicely, and installs itself in /Library/Frameworks/Python.framework/ so it plays nicely with the Mac GUI environment. Also, it will not overwrite any other installation you have - it makes its own install dir. > > UNFORTUNATELY - at the moment, it appears they are writing their new academic software licenses, so you can not download it right now. But there message promises it will soon be available again. > > I have found the Enthought installation to be MUCH more reliable than FINK or MacPorts (Enthought is also a private company - hence the quality installers etc, and they like to support academic work). > > > Cheers, > > Andre > > > > > > > On Oct 8, 2012, at 10:55 AM, Jianbao Tao wrote: > > > Hi all, > > > > A little background: I am from the space physics field where a lot of people watch/analyze satellite data for a living. This is a field currently dominated by IDL in terms of visualization/analysis software. I was a happy IDL user until I saw those very, very, I mean, seriously, very, very pretty matplotlib plots a couple of weeks ago. Although I was happy with IDL most of the time, I always hated the feel of IDL plots on screen. > > > > So, I decided to make my move from IDL to python + numpy + scipy + matplotlib. However, this is not a trivial move. One major thing that makes me stick to IDL in the first place is the Tplot package (bundled into THEMIS Data Analysis Software, a.k.a., TDAS) developed at my own lab, the Space Sciences Lab at UC Berkeley. I must have something equivalent to Tplot to work efficiently on the python platform. In order to do that, there are two problems to solve. First, a utility module is required to load data that are in NASA CDF format. Second, a 2D plotting application is required with the following features: 1) Able to handle large amount vector data, 2) able to display spectrogram with log scale axis quickly, and 3) convenient toolbar to navigate the data. > > > > I have written a module that can quickly load data in CDF files in cython, with help from the cython and the numpy communities. I have also gotten the third plotting feature working with a customized navigation toolbar, thanks to the help I received in this mailing list. However, I haven't figured out how to get the first two plotting features. Matplotlib is known for its slow speed when it comes to large data sets. However, it seems some other packages can plot large data sets very fast, although not as pretty as matplotlib. So, I am wondering what makes matplotlib so slow. Is it because the anti-aliasing engine? If so, is it possible to turn it on or off flexibly to compromise between performance and quality? Also, is it possible to convert the bottle-neck bit of the code into cython to speed up matplotlib? As for spectrograms with log scale axis, I found a working solution from Stack Overflow, but it is simply too slow. So, again, why is it so slow? > > > > So, for my purposes, my real problem now is the slow speed of matplotlib. I tried other packages, such as pyqtgraph, pyqwt, and Chaco/Traits. They seem to be faster, but they have serious problems too. Pyqtgraph seems very promising, but it seems to be in an infant stage for now with serious bugs. For example, I can't get it working together with matplotlib. PyQwt/guiqwt is reasonably robust, but it has too many dependencies in my opinion, and doesn't seem to have a wide user base. Chaco/Traits seems another viable possibility, especially considering the fact that it is actually supported by a company, but I didn't get a chance to see their performance and quality because I can't install Enable, a necessary bit for Chaco, on my mac. (But the fact that Chaco/Traits is supported by a real company is a real plus to me. If I can't eventually speed up matplotlib, I will probably give it another shot.) > > > > I have one idea to speed up line plots in matplotlib on screen, which is basically down-sampling the data before plotting. Basically, my idea is to down-sample the data into a level that one pixel only corresponds to one data point. Apparently, one must have enough information to determine the mapping between the data and the pixels on screen. However, such an overhead is just to maintain some house-keeping information, which I suppose is minimal. > > > > I have no idea how to speed up the log-scale spectrogram plot at the moment. :-( > > > > So, the bottom line: What are the options to speed up matplotlib? Your comments and insights are very much appreciated. :-) > > > > Thank you for reading. > > > > Cheers, > > Jianbao > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >
On Mon, Oct 8, 2012 at 4:37 PM, Jianbao Tao <jia...@gm...> wrote: > Problem: The autodatelocator and autodateformatter don't seem to work > properly. One, the formatter doesn't seem to work immediately after being > applied to an axis. A manual call to the locator seems necessary. Two, the > autodatelocator doesn't seem to be able to handle view intervals less than 1 > second, i.e., the tick labels don't show digits beyond second. You can see > this by zooming the example figure from the code below to a level shorter > than one second. > > 1. Operating system: OS X 10.8.2 > 2. matplotlib version: 1.2.0rc2 > 3. I installed matplotlib via: > > pip install > git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib-dev > > 4. Backend: TkAgg, but I don't think the problem depends on the backend. > 5. Code: > #--------------------------------- code > ----------------------------------------------------- > # Running in ipython --pylab mode. > fig = figure() > tsta = num2epoch(date2num(datetime.datetime.now())) > tarr = tsta + arange(0, 60*30., 0.01) # half hour, dt = 0.01 sec > x = np.array(num2date(epoch2num(tarr))) > nt = len(tarr) > y = randn(nt) > > ax = fig.add_subplot(111) > ax.plot(x, y) > fig.canvas.draw() # Show an overall view of the data > > > locator = mpl.dates.AutoDateLocator() > formatter = mpl.dates.AutoDateFormatter(locator) > > formatter.scaled = { > 365.0 : '%Y', > 30. : '%b %Y', > 1.0 : '%b %d', > 1./24. : '%H:%M', > 1./24./60. : '%M:%S', > 1./24./60./60. : '%S', > } > ax.get_xaxis().set_major_formatter(formatter) # Won't work immediately. > locator.set_axis(ax.xaxis) # Have to manually make this call and the one > below. > locator.refresh() # Another manual call. > fig.canvas.draw() > #------------------------------------ end of code > -------------------------------------------------------- I put it on github: https://github.com/matplotlib/matplotlib/issues/1343 -- Damon McDougall http://www.damon-is-a-geek.com B2.39 Mathematics Institute University of Warwick Coventry West Midlands CV4 7AL United Kingdom
Hi Andre, Thanks for your message. I like it. :-) I do have a .edu email. I didn't try to install Chaco with EPD because I tend to be skeptical when it comes to a bundled package with a lot of stuff. I like it to be as simple as possible. But it seems that I am probably better off to install EPD as a whole. Cheers, Jianbao On Mon, Oct 8, 2012 at 11:17 AM, Andre' Walker-Loud <wal...@gm...>wrote: > Hi Jianbao, > > One option for getting Chaco is to install the Enthought python > disctribution > > http://www.enthought.com/ > > you can see from their package index, they install Chaco (and all needed > libraries to make it work) > > http://www.enthought.com/products/epdlibraries.php > > If you have an email ending in ".edu" you can automatically get their > academic version (fully functioning version - you just have to verify you > are doing academic research). Since you mentioned you were at UC Berkeley, > I assume you have .edu. > Their python installation works nicely, and installs itself in > /Library/Frameworks/Python.framework/ so it plays nicely with the Mac GUI > environment. Also, it will not overwrite any other installation you have - > it makes its own install dir. > > UNFORTUNATELY - at the moment, it appears they are writing their new > academic software licenses, so you can not download it right now. But > there message promises it will soon be available again. > > I have found the Enthought installation to be MUCH more reliable than FINK > or MacPorts (Enthought is also a private company - hence the quality > installers etc, and they like to support academic work). > > > Cheers, > > Andre > > > > > > > On Oct 8, 2012, at 10:55 AM, Jianbao Tao wrote: > > > Hi all, > > > > A little background: I am from the space physics field where a lot of > people watch/analyze satellite data for a living. This is a field currently > dominated by IDL in terms of visualization/analysis software. I was a happy > IDL user until I saw those very, very, I mean, seriously, very, very pretty > matplotlib plots a couple of weeks ago. Although I was happy with IDL most > of the time, I always hated the feel of IDL plots on screen. > > > > So, I decided to make my move from IDL to python + numpy + scipy + > matplotlib. However, this is not a trivial move. One major thing that makes > me stick to IDL in the first place is the Tplot package (bundled into > THEMIS Data Analysis Software, a.k.a., TDAS) developed at my own lab, the > Space Sciences Lab at UC Berkeley. I must have something equivalent to > Tplot to work efficiently on the python platform. In order to do that, > there are two problems to solve. First, a utility module is required to > load data that are in NASA CDF format. Second, a 2D plotting application is > required with the following features: 1) Able to handle large amount vector > data, 2) able to display spectrogram with log scale axis quickly, and 3) > convenient toolbar to navigate the data. > > > > I have written a module that can quickly load data in CDF files in > cython, with help from the cython and the numpy communities. I have also > gotten the third plotting feature working with a customized navigation > toolbar, thanks to the help I received in this mailing list. However, I > haven't figured out how to get the first two plotting features. Matplotlib > is known for its slow speed when it comes to large data sets. However, it > seems some other packages can plot large data sets very fast, although not > as pretty as matplotlib. So, I am wondering what makes matplotlib so slow. > Is it because the anti-aliasing engine? If so, is it possible to turn it on > or off flexibly to compromise between performance and quality? Also, is it > possible to convert the bottle-neck bit of the code into cython to speed up > matplotlib? As for spectrograms with log scale axis, I found a working > solution from Stack Overflow, but it is simply too slow. So, again, why is > it so slow? > > > > So, for my purposes, my real problem now is the slow speed of > matplotlib. I tried other packages, such as pyqtgraph, pyqwt, and > Chaco/Traits. They seem to be faster, but they have serious problems too. > Pyqtgraph seems very promising, but it seems to be in an infant stage for > now with serious bugs. For example, I can't get it working together with > matplotlib. PyQwt/guiqwt is reasonably robust, but it has too many > dependencies in my opinion, and doesn't seem to have a wide user base. > Chaco/Traits seems another viable possibility, especially considering the > fact that it is actually supported by a company, but I didn't get a chance > to see their performance and quality because I can't install Enable, a > necessary bit for Chaco, on my mac. (But the fact that Chaco/Traits is > supported by a real company is a real plus to me. If I can't eventually > speed up matplotlib, I will probably give it another shot.) > > > > I have one idea to speed up line plots in matplotlib on screen, which is > basically down-sampling the data before plotting. Basically, my idea is to > down-sample the data into a level that one pixel only corresponds to one > data point. Apparently, one must have enough information to determine the > mapping between the data and the pixels on screen. However, such an > overhead is just to maintain some house-keeping information, which I > suppose is minimal. > > > > I have no idea how to speed up the log-scale spectrogram plot at the > moment. :-( > > > > So, the bottom line: What are the options to speed up matplotlib? Your > comments and insights are very much appreciated. :-) > > > > Thank you for reading. > > > > Cheers, > > Jianbao > > > ------------------------------------------------------------------------------ > > Don't let slow site performance ruin your business. Deploy New Relic APM > > Deploy New Relic app performance management and know exactly > > what is happening inside your Ruby, Python, PHP, Java, and .NET app > > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > > > http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ > > Matplotlib-users mailing list > > Mat...@li... > > https://lists.sourceforge.net/lists/listinfo/matplotlib-users > >
On 2012年10月08日 7:55 AM, Jianbao Tao wrote: > Hi all, > > A little background: I am from the space physics field where a lot of > people watch/analyze satellite data for a living. This is a field > currently dominated by IDL in terms of visualization/analysis software. > I was a happy IDL user until I saw those very, very, I mean, seriously, > very, very pretty matplotlib plots a couple of weeks ago. Although I was > happy with IDL most of the time, I always hated the feel of IDL plots on > screen. > > So, I decided to make my move from IDL to python + numpy + scipy + > matplotlib. However, this is not a trivial move. One major thing that > makes me stick to IDL in the first place is the Tplot package (bundled > into THEMIS Data Analysis Software, a.k.a.,TDAS > <http://themis.ssl.berkeley.edu/software.shtml>) developed at my own > lab, the Space Sciences Lab at UC Berkeley. I must have something > equivalent to Tplot to work efficiently on the python platform. In order > to do that, there are two problems to solve. First, a utility module is > required to load data that are in NASA CDF format. Second, a 2D plotting > application is required with the following features: 1) Able to handle > large amount vector data, 2) able to display spectrogram with log scale > axis quickly, and 3) convenient toolbar to navigate the data. > > I have written a module that can quickly load data in CDF files in > cython, with help from the cython and the numpy communities. I have also > gotten the third plotting feature working with a customized navigation > toolbar, thanks to the help I received in this mailing list. However, I > haven't figured out how to get the first two plotting features. > Matplotlib is known for its slow speed when it comes to large data sets. > However, it seems some other packages can plot large data sets very > fast, although not as pretty as matplotlib. So, I am wondering what > makes matplotlib so slow. Is it because the anti-aliasing engine? If so, > is it possible to turn it on or off flexibly to compromise between > performance and quality? Also, is it possible to convert the bottle-neck > bit of the code into cython to speed up matplotlib? As for spectrograms > with log scale axis, I found a working solution fromStack Overflow > <http://stackoverflow.com/questions/10812189/creating-a-log-frequency-axis-spectrogram-using-specgram-in-matplotlib>, > but it is simply too slow. So, again, why is it so slow? > > So, for my purposes, my real problem now is the slow speed of > matplotlib. I tried other packages, such as pyqtgraph, pyqwt, and > Chaco/Traits. They seem to be faster, but they have serious problems > too. Pyqtgraph seems very promising, but it seems to be in an infant > stage for now with serious bugs. For example, I can't get it working > together with matplotlib. PyQwt/guiqwt is reasonably robust, but it has > too many dependencies in my opinion, and doesn't seem to have a wide > user base. Chaco/Traits seems another viable possibility, especially > considering the fact that it is actually supported by a company, but I > didn't get a chance to see their performance and quality because I can't > install Enable, a necessary bit for Chaco, on my mac. (But the fact that > Chaco/Traits is supported by a real company is a real plus to me. If I > can't eventually speed up matplotlib, I will probably give it another shot.) > > I have one idea to speed up line plots in matplotlib on screen, which is > basically down-sampling the data before plotting. Basically, my idea is > to down-sample the data into a level that one pixel only corresponds to > one data point. Apparently, one must have enough information to > determine the mapping between the data and the pixels on screen. > However, such an overhead is just to maintain some house-keeping > information, which I suppose is minimal. > > I have no idea how to speed up the log-scale spectrogram plot at the > moment. :-( For each type of plot, I suggest you provide a very minimal script, generating its own fake data, that illustrates the problem and that can serve as a benchmark and test jig for speed-ups. Without these examples, it is somewhere between difficult and impossible for anyone to make useful suggestions. Eric > > So, the bottom line: What are the options to speed up matplotlib? Your > comments and insights are very much appreciated. :-) > > Thank you for reading. > > Cheers, > Jianbao > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > > > > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
Hi Jianbao, One option for getting Chaco is to install the Enthought python disctribution http://www.enthought.com/ you can see from their package index, they install Chaco (and all needed libraries to make it work) http://www.enthought.com/products/epdlibraries.php If you have an email ending in ".edu" you can automatically get their academic version (fully functioning version - you just have to verify you are doing academic research). Since you mentioned you were at UC Berkeley, I assume you have .edu. Their python installation works nicely, and installs itself in /Library/Frameworks/Python.framework/ so it plays nicely with the Mac GUI environment. Also, it will not overwrite any other installation you have - it makes its own install dir. UNFORTUNATELY - at the moment, it appears they are writing their new academic software licenses, so you can not download it right now. But there message promises it will soon be available again. I have found the Enthought installation to be MUCH more reliable than FINK or MacPorts (Enthought is also a private company - hence the quality installers etc, and they like to support academic work). Cheers, Andre On Oct 8, 2012, at 10:55 AM, Jianbao Tao wrote: > Hi all, > > A little background: I am from the space physics field where a lot of people watch/analyze satellite data for a living. This is a field currently dominated by IDL in terms of visualization/analysis software. I was a happy IDL user until I saw those very, very, I mean, seriously, very, very pretty matplotlib plots a couple of weeks ago. Although I was happy with IDL most of the time, I always hated the feel of IDL plots on screen. > > So, I decided to make my move from IDL to python + numpy + scipy + matplotlib. However, this is not a trivial move. One major thing that makes me stick to IDL in the first place is the Tplot package (bundled into THEMIS Data Analysis Software, a.k.a., TDAS) developed at my own lab, the Space Sciences Lab at UC Berkeley. I must have something equivalent to Tplot to work efficiently on the python platform. In order to do that, there are two problems to solve. First, a utility module is required to load data that are in NASA CDF format. Second, a 2D plotting application is required with the following features: 1) Able to handle large amount vector data, 2) able to display spectrogram with log scale axis quickly, and 3) convenient toolbar to navigate the data. > > I have written a module that can quickly load data in CDF files in cython, with help from the cython and the numpy communities. I have also gotten the third plotting feature working with a customized navigation toolbar, thanks to the help I received in this mailing list. However, I haven't figured out how to get the first two plotting features. Matplotlib is known for its slow speed when it comes to large data sets. However, it seems some other packages can plot large data sets very fast, although not as pretty as matplotlib. So, I am wondering what makes matplotlib so slow. Is it because the anti-aliasing engine? If so, is it possible to turn it on or off flexibly to compromise between performance and quality? Also, is it possible to convert the bottle-neck bit of the code into cython to speed up matplotlib? As for spectrograms with log scale axis, I found a working solution from Stack Overflow, but it is simply too slow. So, again, why is it so slow? > > So, for my purposes, my real problem now is the slow speed of matplotlib. I tried other packages, such as pyqtgraph, pyqwt, and Chaco/Traits. They seem to be faster, but they have serious problems too. Pyqtgraph seems very promising, but it seems to be in an infant stage for now with serious bugs. For example, I can't get it working together with matplotlib. PyQwt/guiqwt is reasonably robust, but it has too many dependencies in my opinion, and doesn't seem to have a wide user base. Chaco/Traits seems another viable possibility, especially considering the fact that it is actually supported by a company, but I didn't get a chance to see their performance and quality because I can't install Enable, a necessary bit for Chaco, on my mac. (But the fact that Chaco/Traits is supported by a real company is a real plus to me. If I can't eventually speed up matplotlib, I will probably give it another shot.) > > I have one idea to speed up line plots in matplotlib on screen, which is basically down-sampling the data before plotting. Basically, my idea is to down-sample the data into a level that one pixel only corresponds to one data point. Apparently, one must have enough information to determine the mapping between the data and the pixels on screen. However, such an overhead is just to maintain some house-keeping information, which I suppose is minimal. > > I have no idea how to speed up the log-scale spectrogram plot at the moment. :-( > > So, the bottom line: What are the options to speed up matplotlib? Your comments and insights are very much appreciated. :-) > > Thank you for reading. > > Cheers, > Jianbao > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev_______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Hi all, A little background: I am from the space physics field where a lot of people watch/analyze satellite data for a living. This is a field currently dominated by IDL in terms of visualization/analysis software. I was a happy IDL user until I saw those very, very, I mean, seriously, very, very pretty matplotlib plots a couple of weeks ago. Although I was happy with IDL most of the time, I always hated the feel of IDL plots on screen. So, I decided to make my move from IDL to python + numpy + scipy + matplotlib. However, this is not a trivial move. One major thing that makes me stick to IDL in the first place is the Tplot package (bundled into THEMIS Data Analysis Software, a.k.a., TDAS<http://themis.ssl.berkeley.edu/software.shtml>) developed at my own lab, the Space Sciences Lab at UC Berkeley. I must have something equivalent to Tplot to work efficiently on the python platform. In order to do that, there are two problems to solve. First, a utility module is required to load data that are in NASA CDF format. Second, a 2D plotting application is required with the following features: 1) Able to handle large amount vector data, 2) able to display spectrogram with log scale axis quickly, and 3) convenient toolbar to navigate the data. I have written a module that can quickly load data in CDF files in cython, with help from the cython and the numpy communities. I have also gotten the third plotting feature working with a customized navigation toolbar, thanks to the help I received in this mailing list. However, I haven't figured out how to get the first two plotting features. Matplotlib is known for its slow speed when it comes to large data sets. However, it seems some other packages can plot large data sets very fast, although not as pretty as matplotlib. So, I am wondering what makes matplotlib so slow. Is it because the anti-aliasing engine? If so, is it possible to turn it on or off flexibly to compromise between performance and quality? Also, is it possible to convert the bottle-neck bit of the code into cython to speed up matplotlib? As for spectrograms with log scale axis, I found a working solution from Stack Overflow<http://stackoverflow.com/questions/10812189/creating-a-log-frequency-axis-spectrogram-using-specgram-in-matplotlib>, but it is simply too slow. So, again, why is it so slow? So, for my purposes, my real problem now is the slow speed of matplotlib. I tried other packages, such as pyqtgraph, pyqwt, and Chaco/Traits. They seem to be faster, but they have serious problems too. Pyqtgraph seems very promising, but it seems to be in an infant stage for now with serious bugs. For example, I can't get it working together with matplotlib. PyQwt/guiqwt is reasonably robust, but it has too many dependencies in my opinion, and doesn't seem to have a wide user base. Chaco/Traits seems another viable possibility, especially considering the fact that it is actually supported by a company, but I didn't get a chance to see their performance and quality because I can't install Enable, a necessary bit for Chaco, on my mac. (But the fact that Chaco/Traits is supported by a real company is a real plus to me. If I can't eventually speed up matplotlib, I will probably give it another shot.) I have one idea to speed up line plots in matplotlib on screen, which is basically down-sampling the data before plotting. Basically, my idea is to down-sample the data into a level that one pixel only corresponds to one data point. Apparently, one must have enough information to determine the mapping between the data and the pixels on screen. However, such an overhead is just to maintain some house-keeping information, which I suppose is minimal. I have no idea how to speed up the log-scale spectrogram plot at the moment. :-( So, the bottom line: What are the options to speed up matplotlib? Your comments and insights are very much appreciated. :-) Thank you for reading. Cheers, Jianbao
> Hello, > > Is there any collection of articles that shows academic articles using > matplotlib produced plots? I have come across a few recent articles in my > field with plots produced by matplotlib. Though, the mpl page shows some > nice examples of publication quality plots, it would be nice to have a > discipline specific collection of academic paper citations/links > (hopefully > mostly open-access titles) to raise awareness of mpl usage in academia by > attracting other language users. > > What do you think? I like that idea. Probably, a wiki page at github would be best for this?
Bug to the bug report: In the subject, it should be 'Bug report', rather than 'But report'. Oops :-( Jianbao On Mon, Oct 8, 2012 at 9:37 AM, Jianbao Tao <jia...@gm...> wrote: > Problem: The autodatelocator and autodateformatter don't seem to work > properly. One, the formatter doesn't seem to work immediately after being > applied to an axis. A manual call to the locator seems necessary. Two, the > autodatelocator doesn't seem to be able to handle view intervals less than > 1 second, i.e., the tick labels don't show digits beyond second. You can > see this by zooming the example figure from the code below to a level > shorter than one second. > > 1. Operating system: OS X 10.8.2 > 2. matplotlib version: 1.2.0rc2 > 3. I installed matplotlib via: > > pip install git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib-dev > > 4. Backend: TkAgg, but I don't think the problem depends on the backend. > 5. Code: > #--------------------------------- code > ----------------------------------------------------- > # Running in ipython --pylab mode. > fig = figure() > tsta = num2epoch(date2num(datetime.datetime.now())) > tarr = tsta + arange(0, 60*30., 0.01) # half hour, dt = 0.01 sec > x = np.array(num2date(epoch2num(tarr))) > nt = len(tarr) > y = randn(nt) > > ax = fig.add_subplot(111) > ax.plot(x, y) > fig.canvas.draw() # Show an overall view of the data > > > locator = mpl.dates.AutoDateLocator() > formatter = mpl.dates.AutoDateFormatter(locator) > > formatter.scaled = { > 365.0 : '%Y', > 30. : '%b %Y', > 1.0 : '%b %d', > 1./24. : '%H:%M', > 1./24./60. : '%M:%S', > 1./24./60./60. : '%S', > } > ax.get_xaxis().set_major_formatter(formatter) # Won't work immediately. > locator.set_axis(ax.xaxis) # Have to manually make this call and the one > below. > locator.refresh() # Another manual call. > fig.canvas.draw() > #------------------------------------ end of code > -------------------------------------------------------- > >
Problem: The autodatelocator and autodateformatter don't seem to work properly. One, the formatter doesn't seem to work immediately after being applied to an axis. A manual call to the locator seems necessary. Two, the autodatelocator doesn't seem to be able to handle view intervals less than 1 second, i.e., the tick labels don't show digits beyond second. You can see this by zooming the example figure from the code below to a level shorter than one second. 1. Operating system: OS X 10.8.2 2. matplotlib version: 1.2.0rc2 3. I installed matplotlib via: pip install git+https://github.com/matplotlib/matplotlib.git#egg=matplotlib-dev 4. Backend: TkAgg, but I don't think the problem depends on the backend. 5. Code: #--------------------------------- code ----------------------------------------------------- # Running in ipython --pylab mode. fig = figure() tsta = num2epoch(date2num(datetime.datetime.now())) tarr = tsta + arange(0, 60*30., 0.01) # half hour, dt = 0.01 sec x = np.array(num2date(epoch2num(tarr))) nt = len(tarr) y = randn(nt) ax = fig.add_subplot(111) ax.plot(x, y) fig.canvas.draw() # Show an overall view of the data locator = mpl.dates.AutoDateLocator() formatter = mpl.dates.AutoDateFormatter(locator) formatter.scaled = { 365.0 : '%Y', 30. : '%b %Y', 1.0 : '%b %d', 1./24. : '%H:%M', 1./24./60. : '%M:%S', 1./24./60./60. : '%S', } ax.get_xaxis().set_major_formatter(formatter) # Won't work immediately. locator.set_axis(ax.xaxis) # Have to manually make this call and the one below. locator.refresh() # Another manual call. fig.canvas.draw() #------------------------------------ end of code --------------------------------------------------------
Thanks, Ben. Your fix works when the view interval is greater than 1 minute, but not so much when the view interval is less than one minute. BTW, what I am trying to accomplish is to use matplotlib to plot time-series data that can be as long as several days and as short as a few milliseconds. So, do you think I am better off to handle the format manually by myself instead of deriving the format from auto locator? I am skeptical about the auto locator now because it doesn't seem to be designed for intervals less than 1 second. Cheers, Jianbao On Mon, Oct 8, 2012 at 6:16 AM, Benjamin Root <ben...@ou...> wrote: > > > On Sun, Oct 7, 2012 at 6:47 PM, Jianbao Tao <jia...@gm...> wrote: > >> fig = figure() >> tsta = num2epoch(date2num(datetime.datetime.now())) >> tarr = tsta + arange(0, 60*60*0.5, 0.1) # half hour, dt = >> 0.1 sec >> x = np.array(num2date(epoch2num(tarr))) >> nt = len(tarr) >> y = randn(nt) >> >> ax = fig.add_subplot(111) >> ax.plot(x, y) >> fig.canvas.draw() >> >> # Make a formatter instance. >> locator = mpl.dates.AutoDateLocator() >> formatter = mpl.dates.AutoDateFormatter(locator) >> >> # Customize the scaling. >> formatter.scaled = { >> 365.0 : '%Y', # view interval > 356 days >> 30. : '%b %Y', # view interval > 30 days but less than >> 365 days >> 1.0 : '%b %d', # view interval > 1 day but less than 30 >> days >> 1./24. : '%H:%M', # view interval > 1 hour but less than 24 >> hours >> 1./24./60. : '%M:%S', # view interval > 1 min but less than 1 hour >> 1./24./60./60. : '%S', # view interval < 1 min >> } >> >> # Apply the formatter and redraw the plot. >> ax.get_xaxis().set_major_formatter(formatter) >> fig.canvas.draw() >> > > Confirmed. It seems like that code fell out of maintenance a bit > somehow. Luckily, there is a quick fix to get your code working again. > Just add the following two lines after you set the major formatter, but > before your final draw: > > locator.set_axis(ax.xaxis) > locator.refresh() > > Note, if you zoom in and out after that call, I doubt it will re-adjust > your formatter. Could you file a bug report, please? > > Cheers! > Ben Root > >
On Sun, Oct 7, 2012 at 6:47 PM, Jianbao Tao <jia...@gm...> wrote: > fig = figure() > tsta = num2epoch(date2num(datetime.datetime.now())) > tarr = tsta + arange(0, 60*60*0.5, 0.1) # half hour, dt = > 0.1 sec > x = np.array(num2date(epoch2num(tarr))) > nt = len(tarr) > y = randn(nt) > > ax = fig.add_subplot(111) > ax.plot(x, y) > fig.canvas.draw() > > # Make a formatter instance. > locator = mpl.dates.AutoDateLocator() > formatter = mpl.dates.AutoDateFormatter(locator) > > # Customize the scaling. > formatter.scaled = { > 365.0 : '%Y', # view interval > 356 days > 30. : '%b %Y', # view interval > 30 days but less than 365 > days > 1.0 : '%b %d', # view interval > 1 day but less than 30 > days > 1./24. : '%H:%M', # view interval > 1 hour but less than 24 > hours > 1./24./60. : '%M:%S', # view interval > 1 min but less than 1 hour > 1./24./60./60. : '%S', # view interval < 1 min > } > > # Apply the formatter and redraw the plot. > ax.get_xaxis().set_major_formatter(formatter) > fig.canvas.draw() > Confirmed. It seems like that code fell out of maintenance a bit somehow. Luckily, there is a quick fix to get your code working again. Just add the following two lines after you set the major formatter, but before your final draw: locator.set_axis(ax.xaxis) locator.refresh() Note, if you zoom in and out after that call, I doubt it will re-adjust your formatter. Could you file a bug report, please? Cheers! Ben Root
Hi Mark, 2012年10月8日 mgurling <mag...@gm...> > I called plt.pie with autopct='%1.1f%%' and got the labels I wanted. > However, > when I added the line > > mpl.rcParams['text.usetex'] = True > > the % disappeared from my labels. I'd like to be able to use LaTex for > text, > but can't figure out how to get the % back on my labels. > in (La)Tex % is a comment and to print it you have to escape it with '\'. Have you tried autopct='%1.1f\%'? Cheers, Francesco > I've read the documentation for autopct > > > > autopct: [ None | format string | format function ] > > If not None, is a string or function used to label the wedges with > > their numeric value. The label will be placed inside the wedge. If it is > a > > format string, the label will be fmt%pct. If it is a function, it will be > > called. > > and I am wondering what a format function would look like. All of the > examples using autopct that I can find use a format string similar to > %1.1f%% and none seem to use functions. > > So my questions are: > > 1) How might I get the % back on my labels (whether this requires a format > function or not)? > 2) What would a format function look like when used with autopct? > > > > -- > View this message in context: > http://matplotlib.1069221.n5.nabble.com/What-is-a-autopct-format-function-tp39315.html > Sent from the matplotlib - users mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------------ > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users >
I called plt.pie with autopct='%1.1f%%' and got the labels I wanted. However, when I added the line mpl.rcParams['text.usetex'] = True the % disappeared from my labels. I'd like to be able to use LaTex for text, but can't figure out how to get the % back on my labels. I've read the documentation for autopct > autopct: [ None | format string | format function ] > If not None, is a string or function used to label the wedges with > their numeric value. The label will be placed inside the wedge. If it is a > format string, the label will be fmt%pct. If it is a function, it will be > called. and I am wondering what a format function would look like. All of the examples using autopct that I can find use a format string similar to %1.1f%% and none seem to use functions. So my questions are: 1) How might I get the % back on my labels (whether this requires a format function or not)? 2) What would a format function look like when used with autopct? -- View this message in context: http://matplotlib.1069221.n5.nabble.com/What-is-a-autopct-format-function-tp39315.html Sent from the matplotlib - users mailing list archive at Nabble.com.