On Tue, Oct 22, 2013 at 6:06 PM, Pierre Haessig <pierre.haes...@crans.org>wrote:
> Hi,
>
> Le 21/10/2013 15:58, Todd a écrit :
>
> On Mon, Oct 21, 2013 at 3:13 PM, Pierre Haessig <pierre.haes...@crans.org
> > 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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
