You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
S | M | T | W | T | F | S |
---|---|---|---|---|---|---|
|
|
1
(2) |
2
(5) |
3
(1) |
4
(5) |
5
|
6
(2) |
7
(3) |
8
(1) |
9
|
10
(7) |
11
(13) |
12
|
13
|
14
(1) |
15
|
16
(2) |
17
|
18
(6) |
19
(2) |
20
(1) |
21
(14) |
22
(12) |
23
(15) |
24
(11) |
25
(15) |
26
|
27
|
28
(1) |
29
|
30
(1) |
31
(2) |
|
|
From: Chris B. - N. F. <chr...@no...> - 2013-10-22 16:04:02
|
Are there recent binaries for OS-X anywhere? There don't seem to be any for recent releases on the MPL download page. I know we had a discussion about this a whole back, but don't remember the outcome. But I hope we'll continue to put them up-- macports and friends really aren't the best solutions for everyone. Chris |
From: Pierre H. <pie...@cr...> - 2013-10-22 15:41:44
|
Hi, Le 22/10/2013 12:31, Todd a écrit : > Currently, both axes.psd and axes.csd return the same thing as > mlab.psd and mlab.csd, namely the spectrum and frequency points. They > do NOT return the line object that was plotted. This is different > than specgram, which returns the AxesImage object that was plotted in > addition to the mlab.specgram return values. > > I think having access to the line object is important, so > axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum > do return the line object. I know this is inconsistent, but I think > it is very important and would strongly objefct to removing this. > > The question, then, is whether this would be a good opportunity to add > the line object to the returned values for axes.psd and axes.csd. > This would be an API break, but would be very easy to fix, and it may > be beneficial enough to warrant it. What does everyone think? I agree that it may be nice to have plt.psd/csd to return lines just like plt.plot for increased consistency. I guess that returning the values comes from Matlab style inspiration. Maybe breaking the API is too strong. In that case, adding a transitional keyword (for example `return_line=False`) to psd/csd may help introduce your new proposed behavior in a softer manner. What do you think ? Of course, for your new functions, there is no API breakage problem. best, Pierre |
From: lorenzo.digregorio <lor...@gm...> - 2013-10-22 13:09:24
|
Hello, I've noticed a behavior which is a bit annoying in the 'home' button of a figure. Employing 'sharex' I can share an axis of across two figures(), say figure 1 and figure 2. If I zoom on figure 2, the axis gets correspondly changed in figure 1: wonderful! However, if I click the home button on figure 1 now, I cannot revert to the original view. I have to zoom once in figure 1 as well in order to make the home button work as expected. Best Regards, Lorenzo -- View this message in context: http://matplotlib.1069221.n5.nabble.com/weak-behavior-of-the-home-button-in-figure-version-1-3-1-tp42353.html Sent from the matplotlib - devel mailing list archive at Nabble.com. |
From: Todd <tod...@gm...> - 2013-10-22 10:32:02
|
On Sun, Oct 20, 2013 at 9:45 AM, Todd <tod...@gm...> wrote: > Hello, > > I submitted a pull request #2522 [1]. It includes support for more basic > spectrum plots like magnitude and phase spectrums. These are extremely > commonly used in signal processing, acoustics, and many other fields, but > are also very important for educational usage since pretty much anyone > going through one of several engineering degrees like electrical > engineering has to learn these types of plots. I have heard a number of > colleagues complaining about the lack of these plots in matlab. > > It has been up for 5 days, but I haven't received any comments on its > content or structure. I understand that it is a pretty substantial patch, > but I think the features are very useful. > > I am also a bit concerned that patches covering the same code might be > submitted and accepted while I am waiting for this, since such changes > would be hard to merge into my branch. > > So does anyone have any thoughts on the patch? > > [1] https://github.com/matplotlib/matplotlib/pull/2522 > I do have one question about my pull request. Currently, both axes.psd and axes.csd return the same thing as mlab.psd and mlab.csd, namely the spectrum and frequency points. They do NOT return the line object that was plotted. This is different than specgram, which returns the AxesImage object that was plotted in addition to the mlab.specgram return values. I think having access to the line object is important, so axes.magnitude_spectrum, axes.angle_spectrum, and axes.phase_spectrum do return the line object. I know this is inconsistent, but I think it is very important and would strongly objefct to removing this. The question, then, is whether this would be a good opportunity to add the line object to the returned values for axes.psd and axes.csd. This would be an API break, but would be very easy to fix, and it may be beneficial enough to warrant it. What does everyone think? |
From: Todd <tod...@gm...> - 2013-10-22 08:06:14
|
On Tue, Oct 22, 2013 at 9:30 AM, Ian Thomas <ian...@gm...> wrote: > On 22 October 2013 07:53, Todd <tod...@gm...> wrote: > >> As of last night, I can no longer compile master. I get the following >> error: >> >> building 'matplotlib.ttconv' extension >> creating build/temp.linux-x86_64-2.7/extern/ttconv >> gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall >> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables >> -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall >> -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables >> -fasynchronous-unwind-tables -g -fPIC >> -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API >> -DPYCXX_ISO_CPP_LIB=1 >> -I/usr/lib64/python2.7/site-packages/numpy/core/include >> -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c >> src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o >> src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or >> directory >> compilation terminated. >> error: command 'gcc' failed with exit status 1 >> >> This happens even when building from a newly-cloned directory. I am >> building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it >> has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is >> still looking there. >> > > Todd, > > This is my fault, I would expect to see a '-Iextern' in the compilation > options. Usually this is obtained from CXX().add_flags(), but obviously > not in your case which implies that your CXX is available via pkg-config. > > I think either of the following changes will fix the problem: > > 1) Either adding the following after line 947 in setupext.py: > ext.include_dirs.append('extern') > > 2) Or changing line 12 of src/_ttconv.cpp from > #include "ttconv/pprdrv.h" > to > #include "extern/ttconv/pprdrv.h" > > I'll need to think about which is the better solution. If you can let me > know which of these fix the problem, I'll have a PR out later today. > > Ian > > Thanks, both seem to work. |
From: Ian T. <ian...@gm...> - 2013-10-22 07:30:52
|
On 22 October 2013 07:53, Todd <tod...@gm...> wrote: > As of last night, I can no longer compile master. I get the following > error: > > building 'matplotlib.ttconv' extension > creating build/temp.linux-x86_64-2.7/extern/ttconv > gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall > -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall > -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables > -fasynchronous-unwind-tables -g -fPIC > -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API > -DPYCXX_ISO_CPP_LIB=1 > -I/usr/lib64/python2.7/site-packages/numpy/core/include > -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c > src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o > src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or > directory > compilation terminated. > error: command 'gcc' failed with exit status 1 > > This happens even when building from a newly-cloned directory. I am > building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it > has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is > still looking there. > Todd, This is my fault, I would expect to see a '-Iextern' in the compilation options. Usually this is obtained from CXX().add_flags(), but obviously not in your case which implies that your CXX is available via pkg-config. I think either of the following changes will fix the problem: 1) Either adding the following after line 947 in setupext.py: ext.include_dirs.append('extern') 2) Or changing line 12 of src/_ttconv.cpp from #include "ttconv/pprdrv.h" to #include "extern/ttconv/pprdrv.h" I'll need to think about which is the better solution. If you can let me know which of these fix the problem, I'll have a PR out later today. Ian |
From: Todd <tod...@gm...> - 2013-10-22 06:54:08
|
As of last night, I can no longer compile master. I get the following error: building 'matplotlib.ttconv' extension creating build/temp.linux-x86_64-2.7/extern/ttconv gcc -pthread -fno-strict-aliasing -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -DNDEBUG -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -fPIC -DPY_ARRAY_UNIQUE_SYMBOL=MPL_matplotlib_ttconv_ARRAY_API -DPYCXX_ISO_CPP_LIB=1 -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/local/include -I/usr/include -I. -I/usr/include/python2.7 -c src/_ttconv.cpp -o build/temp.linux-x86_64-2.7/src/_ttconv.o src/_ttconv.cpp:12:27: fatal error: ttconv/pprdrv.h: No such file or directory compilation terminated. error: command 'gcc' failed with exit status 1 This happens even when building from a newly-cloned directory. I am building on Linux (openSUSE 12.3). There shouldn't be ttconv/pprdrv.h, it has been moved to extern/ttconv/pprdrv.h. I can't figure out why it is still looking there. |
From: Jason G. <jas...@cr...> - 2013-10-21 21:19:40
|
On 10/21/13 12:11 PM, Michael Droettboom wrote: > Yes -- I reached out to the author about exactly that this morning. It > would be great to closely collaborate on this. > Awesome. I saw this on HackerNews a few days ago and got really excited about it. So a big +1 from me. Thanks, Jason |
From: Todd <tod...@gm...> - 2013-10-21 21:12:52
|
On Mon, Oct 21, 2013 at 7:36 PM, Chris Barker <chr...@no...> wrote: > > To expand slightly, with the current situation the onus is on us to > ensure > > that mpl builds OK and passes all of our tests with and without each of > the > > external libraries. > > If you only have internal libs, then there is less to do -- it only > need to work with the version you bundle. And making sure it works > with any-old-version-that-may-not-exist-yet is a pretty formidable > challenge! > We have sonums for this very reason. And this could apply just as well to python itself. There is a reason not many distros ship SAGE packages. > > Linux distro packagers will choose to set up qhull as a > > required dependency for their mpl package, and once they have done this > can > > simply delete our directory containing the qhull source code in their mpl > > source package, > > If they are going to insist on doing this, then, yes you should > certainly do it this way. > Yes, they are. This is the whole point of having packages in the first place, as opposed to something like windows where every program just bundles everything.. > > we can all be confident that it will work correctly. > > only if you've tested against the version (maybe patched) of the > external lib they are using... > It is only matplotlib's responsibility to test against the unpatched versions specified, just like it is only matplotlib's responsibility to test against the unpatched python versions specified. Doing this isn't a particularly difficult task, there are easily tens of thousands of apps that have no problem with this. > > If we always used our internal version then distro packagers would have > to > > change our setup scripts to build using the external libraries. This > would > > be more time-consuming and error prone leading to less timely mpl distro > > releases. We need to make their job as easy as possible. > > it's easiest for them if they don't try to pull out an included > dependency -- but maybe you're right that that REALLY want to do that! > It would be easiest if matplotlib detected whether the library is present at build-time. That is what most packages do. > >The needs of the distro packagers, which are primarily security and > > stability, are sometimes at odds with the needs of scientific software, > > where the premium is on reproducibility. The output of matplotlib > depends > > on the versions of some of its dependencies, not the version of > matplotlib > > alone, and that's problematic for some... > > exactly -- if we know exactly which version of a lib is in use, we > know that it works the way we expect in the use cases we expect to use > it in. > > But I'm not maintaining this code, so have at it in the way that makes > sense to you. > > NOTE: it would be a different story if this were a netwroking protocol > lib, or something where security patches would be critical. Maybe I'm > naive, but this doesn't seem likely in this case. > You would be surprised what sort of packages can lead to security vulnerabilities. |
From: Ian T. <ian...@gm...> - 2013-10-21 19:53:22
|
On 21 October 2013 18:36, Chris Barker <chr...@no...> wrote: > > we can all be confident that it will work correctly. > > only if you've tested against the version (maybe patched) of the > external lib they are using... > Of course not. We provide the framework to build mpl and run tests. Distro developers choose how they want to build it and then run our tests. If the tests pass then both they and us are confident that it works correctly. We haven't had to test against anyone else's choice of library version. But I'm not maintaining this code, so have at it in the way that makes > sense to you. > This is nothing to do with what makes sense to me; it is about following the existing policy on C/C++ extensions when adding a new one. Just because I am taking time to answer your questions don't presume I am taking a particular stance. In fact I don't have a preference either way, I am just doing the work that is required in a way that is consistent with existing code. If there is a change of policy I am happy to do it a different way. Ian |
From: Benjamin R. <ben...@ou...> - 2013-10-21 17:41:42
|
On Mon, Oct 21, 2013 at 1:26 PM, Chris Barker <chr...@no...> wrote: > On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root <ben...@ou...> wrote: > > > FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013 > > struck a balance between pyplot and the OO interface. > > Grat, I'll take a look. > > Does the ipynb linked from the tutorial site have most of the > presentation material? > > Yup. Most of it is in the notebook. Here is the repo: https://github.com/WeatherGod/AnatomyOfMatplotlib > As it turns out, I need to give an intro to matplotlib class this week > -- I've been looking for some good materials to use -- why re-invent > the wheel? > > I'll be sure to give you any feedback I have. > > Thanks! That would be appreciated! I am glad this will (hopefully) save time and effort on your part to get others ramped up. > Hmmm.. this may be a time to put together a project of materials > designed to teach matplotlib in a classroom setting -- a little > different than a tutorial designed to be done on one's own. > > There is a bunch of stuff scattered among scipy tutorials, bootcamp > lectures, etc, but having a central place to develop materials would > be nice. > > -Chris > > I agree with you in principle, but I think the question is "central to whom?" The bootcamps are useful for their own purposes and audiences, while the scipy tutorial s are useful for their own things, etc. At this point, I think the bootcamps and SciPy and other conferences really should be the best venues for pushing out the "classroom-oriented" type of tutorials. Cheers! Ben Root |
From: Chris B. <chr...@no...> - 2013-10-21 17:36:55
|
> To expand slightly, with the current situation the onus is on us to ensure > that mpl builds OK and passes all of our tests with and without each of the > external libraries. If you only have internal libs, then there is less to do -- it only need to work with the version you bundle. And making sure it works with any-old-version-that-may-not-exist-yet is a pretty formidable challenge! > Linux distro packagers will choose to set up qhull as a > required dependency for their mpl package, and once they have done this can > simply delete our directory containing the qhull source code in their mpl > source package, If they are going to insist on doing this, then, yes you should certainly do it this way. > we can all be confident that it will work correctly. only if you've tested against the version (maybe patched) of the external lib they are using... > If we always used our internal version then distro packagers would have to > change our setup scripts to build using the external libraries. This would > be more time-consuming and error prone leading to less timely mpl distro > releases. We need to make their job as easy as possible. it's easiest for them if they don't try to pull out an included dependency -- but maybe you're right that that REALLY want to do that! >The needs of the distro packagers, which are primarily security and > stability, are sometimes at odds with the needs of scientific software, > where the premium is on reproducibility. The output of matplotlib depends > on the versions of some of its dependencies, not the version of matplotlib > alone, and that's problematic for some... exactly -- if we know exactly which version of a lib is in use, we know that it works the way we expect in the use cases we expect to use it in. But I'm not maintaining this code, so have at it in the way that makes sense to you. NOTE: it would be a different story if this were a netwroking protocol lib, or something where security patches would be critical. Maybe I'm naive, but this doesn't seem likely in this case. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Chris B. <chr...@no...> - 2013-10-21 17:27:07
|
On Fri, Oct 18, 2013 at 11:56 AM, Benjamin Root <ben...@ou...> wrote: > FWIW, I think my "Anatomy of Matplotlib" tutorial I gave at SciPy 2013 > struck a balance between pyplot and the OO interface. Grat, I'll take a look. Does the ipynb linked from the tutorial site have most of the presentation material? As it turns out, I need to give an intro to matplotlib class this week -- I've been looking for some good materials to use -- why re-invent the wheel? I'll be sure to give you any feedback I have. Hmmm.. this may be a time to put together a project of materials designed to teach matplotlib in a classroom setting -- a little different than a tutorial designed to be done on one's own. There is a bunch of stuff scattered among scipy tutorials, bootcamp lectures, etc, but having a central place to develop materials would be nice. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
From: Michael D. <md...@st...> - 2013-10-21 17:11:48
|
Yes -- I reached out to the author about exactly that this morning. It would be great to closely collaborate on this. Mike On 10/21/2013 01:06 PM, Todd wrote: > Seems like a lot of what they are doing could be upstreamed into > matplotlib. Then they could just wrap it in their own ggplot syntax. > That would improve matplotlib and simplify the maintainance for them. > > > On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom <md...@st... > <mailto:md...@st...>> wrote: > > I just learned about this today, and thought I'd share. It's an > implementation of the ggplot interface on top of matplotlib: > > http://blog.yhathq.com/posts/ggplot-for-python.html > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > > http://www.droettboom.com > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get > the most from > the latest Intel processors and coprocessors. See abstracts and > register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > <mailto:Mat...@li...> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: Todd <tod...@gm...> - 2013-10-21 17:06:52
|
Seems like a lot of what they are doing could be upstreamed into matplotlib. Then they could just wrap it in their own ggplot syntax. That would improve matplotlib and simplify the maintainance for them. On Mon, Oct 21, 2013 at 5:58 PM, Michael Droettboom <md...@st...> wrote: > I just learned about this today, and thought I'd share. It's an > implementation of the ggplot interface on top of matplotlib: > > http://blog.yhathq.com/posts/ggplot-for-python.html > > -- > _ > |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ > | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | > http://www.droettboom.com > > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
From: Michael D. <md...@st...> - 2013-10-21 16:13:37
|
On 10/19/2013 04:24 PM, Matthew Brett wrote: > Hi, > > On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom <md...@st...> wrote: >> On 10/18/2013 02:11 AM, Matthew Brett wrote: >>> Hi, >>> >>> I'm testing the binary installer build: >>> >>> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220 >>> >>> and I'm getting a test failure on Python 3.3 (not Python 2.7): >>> >>> ====================================================================== >>> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test >>> ---------------------------------------------------------------------- >>> Traceback (most recent call last): >>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py", >>> line 198, in runTest >>> self.test(*self.arg) >>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py", >>> line 73, in test >>> self._func() >>> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py", >>> line 54, in test_invisible_Line_rendering >>> assert_true(slowdown_factor < slowdown_threshold) >>> AssertionError: False is not true >>> >>> ---------------------------------------------------------------------- >>> Ran 1464 tests in 656.822s >>> >>> Is this a problem? What should I do to debug further? >>> >> I've never seen that failure before... >> >> I wonder if Pierre Haessig has any thoughts, as the author of that test... >> >> Mike > Thanks. I get the same error running under Python 2.7 on a clean 10.6 machine. > > Also I get: > > ====================================================================== > FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.test > ---------------------------------------------------------------------- > Traceback (most recent call last): > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", > line 197, in runTest > self.test(*self.arg) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", > line 40, in failer > result = f(*args, **kwargs) > File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", > line 159, in do_test > '(RMS %(rms).3f)'%err) > ImageComparisonFailure: images not close: > /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png > vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png > (RMS 15.521) > > The images look identical to me... Can you send me the failed image? If we both agree they are the same, it may just need to have the RMS increased to account for font differences. Also Cc'ing Pierre about the above issue. Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: Michael D. <md...@st...> - 2013-10-21 16:09:18
|
On 10/19/2013 04:14 AM, Ian Thomas wrote: > On 18 October 2013 19:18, Chris Barker <chr...@no... > <mailto:chr...@no...>> wrote: > > Ian, > > > I am working on a PR to replace the use of matplotlib.delaunay > with the > > Qhull library. > > nice! -- ( though I sure wish Qhull did constrained delaunay...) > > > Installation will be similar to the existing packages LibAgg > > and CXX in that if the system already has a sufficiently recent > version of > > Qhull installed then matplotlib will use that, otherwise it will > build the > > required library from the source code shipped with matplotlib. > > Why bother, why not just always build the internal version? > > (for that matter, same with agg) > > Wouldn't it be a lot easier and more robust to be sure that everyone > is running the exact same code? > > What are the odds that folks are using qhull for something else, and > even more to the point, what are the odds that the duplication of this > lib would matter one wit? > > This isn't like LAPACK, where folks have a compellling reason to run a > particular version. > > -- just my thoughts on how to keep things simpler. > > > Chris, > > Todd has hit the nail on the head. > > To expand slightly, with the current situation the onus is on us to > ensure that mpl builds OK and passes all of our tests with and without > each of the external libraries. Linux distro packagers will choose to > set up qhull as a required dependency for their mpl package, and once > they have done this can simply delete our directory containing the > qhull source code in their mpl source package, and it will build OK > without any further changes and we can all be confident that it will > work correctly. > > If we always used our internal version then distro packagers would > have to change our setup scripts to build using the external > libraries. This would be more time-consuming and error prone leading > to less timely mpl distro releases. We need to make their job as easy > as possible. Agreed on all of these points, and I'm not advocating a change from what Ian is doing. However, as get on in years, I'm starting to more and more feel like the needs of the distro packagers, which are primarily security and stability, are sometimes at odds with the needs of scientific software, where the premium is on reproducibility. The output of matplotlib depends on the versions of some of its dependencies, not the version of matplotlib alone, and that's problematic for some... Anyway, just food for thought. I still think the most practical approach is the one we're taking (shipping dependencies, but making it easy to use the system libraries when available). Mike -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: Michael D. <md...@st...> - 2013-10-21 15:59:08
|
I just learned about this today, and thought I'd share. It's an implementation of the ggplot interface on top of matplotlib: http://blog.yhathq.com/posts/ggplot-for-python.html -- _ |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _ | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | | http://www.droettboom.com |
From: mark <ma...@me...> - 2013-10-21 15:44:21
|
hi matplotlib developers as I previously posted, I have thought about structure and flow of the user guide my fist cut of a change set is viewable here: https://github.com/marqh/matplotlib/compare/userGuideShape it keeps all of the same content as the current user guide but subdivides some sections into categories: configuration beginner's guide advanced guide So, all feedback very gratefully received, but a particular focus requested on: - sub-section headings - sub-section contents (scope) - ordering I would like to focus on getting the categorisation and ordering helpful for this piece of work. I feel that this will give us more accessible ways into adding new sections or adapting sections but that this should wait for a follow up activity. many thanks mark On Wed, 25 Sep 2013 08:19:59 +0000 mark <ma...@me...> wrote: > hi matplotlib developers > > I have been considering the matplotlib user guide structure and it > has occured to me that there are two user guides interleaved here: > 1. Introduction for new users > 2. Library tour for developers > > I think that this structure makes it challenging for new users to > benefit from the user guide as much as they could. > > I would like to see the user guide separated into two sections, with > the two different audiences in mind. I feel this would enable new > users of the library to have a more targeted introduction to some of > the neat features without getting bogged down in details they are > unlikely to need (or comprehend). > > I am very happy to have a go at this and put up a set of suggested > changes but I would value input from the community on this approach > and my category suggestions before I submit a pull request. > > many thanks > mark > > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the > most from the latest Intel processors and coprocessors. See abstracts > and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ Matplotlib-devel > mailing list Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel |
From: Todd <tod...@gm...> - 2013-10-21 13:58:45
|
On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pie...@cr...>wrote: > Hi, > > Le 20/10/2013 09:45, Todd a écrit : > > I submitted a pull request #2522 [1]. It includes support for more > > basic spectrum plots like magnitude and phase spectrums. These are > > extremely commonly used in signal processing, acoustics, and many > > other fields, but are also very important for educational usage since > > pretty much anyone going through one of several engineering degrees > > like electrical engineering has to learn these types of plots. I have > > heard a number of colleagues complaining about the lack of these plots > > in matlab. > > Having specific signal processing functions is indeed important. I hust > have a question about "phase" vs. "angle" spectrum. From browsing > quickly through you doc, it seems that the difference is just about > *unwrapping the phase*. If that's indeed the case, I've two > questions/remarks: > > 1) is the terminology "phase" vs. "angle" spectrum standardized ? I must > say I've never heard of one meaning "wrapped" and the other "unwrapped". > I didn't find similar terms in Matlab docs, but I didn't search that > thoroughly. > The "angle" function in numpy returns the wrapped angle, while the "unwrap" function documentation talks about phase, so it is consistent with the usage in numpy. Further, in signal processing, phases can have any value, while "angle" often refers to the angle between two lines, which must be wrapped. There may be some ambiguity, but I made sure to explain it in the documentation and provide links between the two functions so people know what they should do if they want to use the other approach. > 2) Should there be two separate functions for these two, or just one > function, with a switch argument `unwrap` ? (I guess it would be True by > default) > I originally was going to do that, but decided against it. The problem is with specgram. Here, I thought it would be needlessly complicated to add an "unwrap" parameter that is only useful for one "mode". To make it obvious to users, I wanted to keep specgram as similar as possible to the other plot types, and that involved keeping the parameter. Further, this approach is simpler to code and easier to maintain. Having to deal with the "unwrap" parameter would have been more difficult to program. Dealing with both an "unwrap" parameter in some cases and a separate "mode" in others would have been even more complicated. Further, _spectral_helper and specgram already have a huge number of arguments. This way I was able to get away with just adding one new argument rather than two. |
From: Pierre H. <pie...@cr...> - 2013-10-21 13:32:17
|
Hi, Le 20/10/2013 09:45, Todd a écrit : > I submitted a pull request #2522 [1]. It includes support for more > basic spectrum plots like magnitude and phase spectrums. These are > extremely commonly used in signal processing, acoustics, and many > other fields, but are also very important for educational usage since > pretty much anyone going through one of several engineering degrees > like electrical engineering has to learn these types of plots. I have > heard a number of colleagues complaining about the lack of these plots > in matlab. Having specific signal processing functions is indeed important. I hust have a question about "phase" vs. "angle" spectrum. From browsing quickly through you doc, it seems that the difference is just about *unwrapping the phase*. If that's indeed the case, I've two questions/remarks: 1) is the terminology "phase" vs. "angle" spectrum standardized ? I must say I've never heard of one meaning "wrapped" and the other "unwrapped". I didn't find similar terms in Matlab docs, but I didn't search that thoroughly. 2) Should there be two separate functions for these two, or just one function, with a switch argument `unwrap` ? (I guess it would be True by default) best, Pierre |
From: Todd <tod...@gm...> - 2013-10-20 07:45:54
|
Hello, I submitted a pull request #2522 [1]. It includes support for more basic spectrum plots like magnitude and phase spectrums. These are extremely commonly used in signal processing, acoustics, and many other fields, but are also very important for educational usage since pretty much anyone going through one of several engineering degrees like electrical engineering has to learn these types of plots. I have heard a number of colleagues complaining about the lack of these plots in matlab. It has been up for 5 days, but I haven't received any comments on its content or structure. I understand that it is a pretty substantial patch, but I think the features are very useful. I am also a bit concerned that patches covering the same code might be submitted and accepted while I am waiting for this, since such changes would be hard to merge into my branch. So does anyone have any thoughts on the patch? [1] https://github.com/matplotlib/matplotlib/pull/2522 |
From: Matthew B. <mat...@gm...> - 2013-10-19 20:24:51
|
Hi, On Fri, Oct 18, 2013 at 4:47 AM, Michael Droettboom <md...@st...> wrote: > On 10/18/2013 02:11 AM, Matthew Brett wrote: >> Hi, >> >> I'm testing the binary installer build: >> >> https://travis-ci.org/matthew-brett/mpl-osx-binaries/builds/12703220 >> >> and I'm getting a test failure on Python 3.3 (not Python 2.7): >> >> ====================================================================== >> FAIL: matplotlib.tests.test_lines.test_invisible_Line_rendering.test >> ---------------------------------------------------------------------- >> Traceback (most recent call last): >> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/nose/case.py", >> line 198, in runTest >> self.test(*self.arg) >> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/testing/decorators.py", >> line 73, in test >> self._func() >> File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/matplotlib/tests/test_lines.py", >> line 54, in test_invisible_Line_rendering >> assert_true(slowdown_factor < slowdown_threshold) >> AssertionError: False is not true >> >> ---------------------------------------------------------------------- >> Ran 1464 tests in 656.822s >> >> Is this a problem? What should I do to debug further? >> > > I've never seen that failure before... > > I wonder if Pierre Haessig has any thoughts, as the author of that test... > > Mike Thanks. I get the same error running under Python 2.7 on a clean 10.6 machine. Also I get: ====================================================================== FAIL: matplotlib.tests.test_contour.test_contour_manual_labels.test ---------------------------------------------------------------------- Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/nose/case.py", line 197, in runTest self.test(*self.arg) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 40, in failer result = f(*args, **kwargs) File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/matplotlib/testing/decorators.py", line 159, in do_test '(RMS %(rms).3f)'%err) ImageComparisonFailure: images not close: /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels.png vs. /Users/mb312/mpkg-test/mpl-test/result_images/test_contour/contour_manual_labels-expected.png (RMS 15.521) The images look identical to me... Cheers, Matthew |
From: Ian T. <ian...@gm...> - 2013-10-19 08:14:52
|
On 18 October 2013 19:18, Chris Barker <chr...@no...> wrote: > Ian, > > > I am working on a PR to replace the use of matplotlib.delaunay with the > > Qhull library. > > nice! -- ( though I sure wish Qhull did constrained delaunay...) > > > Installation will be similar to the existing packages LibAgg > > and CXX in that if the system already has a sufficiently recent version > of > > Qhull installed then matplotlib will use that, otherwise it will build > the > > required library from the source code shipped with matplotlib. > > Why bother, why not just always build the internal version? > > (for that matter, same with agg) > > Wouldn't it be a lot easier and more robust to be sure that everyone > is running the exact same code? > > What are the odds that folks are using qhull for something else, and > even more to the point, what are the odds that the duplication of this > lib would matter one wit? > > This isn't like LAPACK, where folks have a compellling reason to run a > particular version. > > -- just my thoughts on how to keep things simpler. > Chris, Todd has hit the nail on the head. To expand slightly, with the current situation the onus is on us to ensure that mpl builds OK and passes all of our tests with and without each of the external libraries. Linux distro packagers will choose to set up qhull as a required dependency for their mpl package, and once they have done this can simply delete our directory containing the qhull source code in their mpl source package, and it will build OK without any further changes and we can all be confident that it will work correctly. If we always used our internal version then distro packagers would have to change our setup scripts to build using the external libraries. This would be more time-consuming and error prone leading to less timely mpl distro releases. We need to make their job as easy as possible. Ian |
From: Todd <tod...@gm...> - 2013-10-18 19:16:06
|
On Oct 18, 2013 8:20 PM, "Chris Barker" <chr...@no...> wrote: > > Ian, > > > I am working on a PR to replace the use of matplotlib.delaunay with the > > Qhull library. > > nice! -- ( though I sure wish Qhull did constrained delaunay...) > > > Installation will be similar to the existing packages LibAgg > > and CXX in that if the system already has a sufficiently recent version of > > Qhull installed then matplotlib will use that, otherwise it will build the > > required library from the source code shipped with matplotlib. > > Why bother, why not just always build the internal version? > > (for that matter, same with agg) > > Wouldn't it be a lot easier and more robust to be sure that everyone > is running the exact same code? > > What are the odds that folks are using qhull for something else, and > even more to the point, what are the odds that the duplication of this > lib would matter one wit? > > This isn't like LAPACK, where folks have a compellling reason to run a > particular version. > > -- just my thoughts on how to keep things simpler. > > > -Chris >From a Linux distro packaging perspective bundled external libs are a big no-no. If a patch is needed for whatever reason packagers don't want to have to go and hunt down dozens of copies of the same library. In some cases there is no alternative but it should be avoided whenever possible. |