Re: [matplotlib-devel] Problem compiling master
On 22 October 2013 07:53, Todd 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
--
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=60135991&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem compiling master
On Tue, Oct 22, 2013 at 9:30 AM, Ian Thomas wrote:
> On 22 October 2013 07:53, Todd 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.
--
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=60135991&iu=/4140/ostg.clktrk___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Sun, Oct 20, 2013 at 9:45 AM, Todd 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? -- 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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] weak behavior of the home button in figure() (version 1.3.1)
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. -- 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=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
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 signature.asc Description: OpenPGP digital signature -- 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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] OS-X binaries?
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 -- 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=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
Hi, Le 21/10/2013 15:58, Todd a écrit : > On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig > mailto:[email protected]>> wrote: > > 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. > Thanks for the feedback. I agree that your documentation does make clear the distinction between "phase" and "angle" and that it has a consistency. I just feel that this distinction does not exist "outside" ... But beyond this question of phase vs. angle, I must say I don't see that big a use case for phase/angle spectrums[*] (as opposed to magnitude which are much used). Also, in many cases, "spectrum" is synonymous with spectral density, which implies "magnitude". In the end I wonder whether the notion of phase even makes sense for a spectrogram ? That's the reason why I'm a bit skeptical with the many new "mode switches" in the spec helper, along with the new phase/angle_* functions. best, Pierre [*] On the other hand I do see a usecase of magnitude and phase for plotting transfer functions (i.e. Bode diagrams). Those are not fft based plots, so it's a different topic I guess. Bode/Nyquist/Black diagrams could be nice to have. signature.asc Description: OpenPGP digital signature -- 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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Tue, Oct 22, 2013 at 5:41 PM, Pierre Haessig wrote: > 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 > I considered that solution as well, but it seemed ugly. However, I think having it available is important, so I will add it. The current behavior can probably be deprecated at some point, allowing for a smoother transition. -- 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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OS-X binaries?
Matthew Brett has an experimental installer that includes the Python dependencies: http://matplotlib.1069221.n5.nabble.com/Any-progress-on-binary-installer-for-OSX-td42163.html Once the remaining issues are ironed out, we'll definitely link to this from matplotlib.org/downloads.html Mike On 10/22/2013 12:03 PM, Chris Barker - NOAA Federal wrote: 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 -- 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=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- _ |\/|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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Pull request
On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig wrote: > Hi, > > Le 21/10/2013 15:58, Todd a écrit : > > On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig > wrote: > >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. > > Thanks for the feedback. I agree that your documentation does make clear > the distinction between "phase" and "angle" and that it has a consistency. > I just feel that this distinction does not exist "outside" ... > > But beyond this question of phase vs. angle, I must say I don't see that > big a use case for phase/angle spectrums[*] (as opposed to magnitude which > are much used). > I personally use phase and angle spectrums a huge amount. In signal processing it is extremely important. It is a critical component in acoustics. It is also used a lot to separate out signals that have been mixed together. Knowing the phases of signals can also be very important in certain optics applications and for radio signals and RADAR. Changes in the phase spectrum over time (like you would get from a phase spectrogram) is important for doppler analysis both with optical and acoustic signals. Also, from an educational perspective, anyone taking a digital signal processing course will need to produce magnitude/phase plots, probably both with and without wrapping (since any decent digital signal processing course will teach you about the pitfalls that occur due to phase wrapping). So this will make matplotlib much more useful for such courses. > Also, in many cases, "spectrum" is synonymous with spectral density, which > implies "magnitude". In the end I wonder whether the notion of phase even > makes sense for a spectrogram ? > Yes, particularly electrical engineering. But there are many other fields where spectral density is rarely used, and where more "ordinary" magnitude and phase plots are the norm, as I explained in the previous paragraphs. -- 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=60135991&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] OS-X binaries?
Hi Chris, On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal wrote: > 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. I hope I have this cracked now, at least in principle. The latest versions are here: http://nipy.bic.berkeley.edu/scipy_installers/ Following Matt Terry's example, I'm testing the builds and then the installers here: https://travis-ci.org/matthew-brett/mpl-osx-binaries It would be great if you could give them a try. Cheers, Matthew -- 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=60135991&iu=/4140/ostg.clktrk ___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
