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
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
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_*
[*] 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.
On Mon, Oct 21, 2013 at 3:13 PM,
Pierre Haessig <pierre.haessig@…804…>
1) is the terminology "phase" vs. "angle" spectrum
standardized ? I must
say I've never heard of one meaning "wrapped" and the
I didn't find similar terms in Matlab docs, but I didn't
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
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
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.