matplotlib-devel Mailing List for matplotlib

Hi Chris,

On Tue, Oct 22, 2013 at 9:03 AM, Chris Barker - NOAA Federal
<chr...@no...> 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

On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig <pie...@cr...>wrote:

>  Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
>  On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pie...@cr...
> > 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.

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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel


-- 
                    _
|\/|o _|_  _. _ | | \.__  __|__|_|_  _  _ ._ _
|  ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |

http://www.droettboom.com

On Tue, Oct 22, 2013 at 5:41 PM, Pierre Haessig <pie...@cr...>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.

Hi,

Le 21/10/2013 15:58, Todd a écrit :
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig
> <pie...@cr... <mailto:pie...@cr...>> 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.

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

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

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.

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?

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.

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

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.