medians for degree measurements

[Bas]

> >> On 2010-01-25 10:16 AM, Bas wrote:
> >>> P.S.
> >>> Slightly off-topic rant against both numpy and matlab implementation
> >>> of unwrap: They always assume data is in radians. There is some option
> >>> to specify the maximum jump size in radians, but to me it would be
> >>> more useful to specify the interval of a complete cycle, so that you
> >>> can do

[snip]

> > I never saw a use case for the discontinuity argument, so in my
> > preferred version it would be removed. Of course this breaks old code
> > (by who uses this option anyhow??) and breaks compatibility between
> > matlab and numpy.

On Jan 25, 6:39 pm, Robert Kern <robert.k... at gmail.com> wrote:
> Sometimes legitimate features have phase discontinuities greater than pi.

We are dwelling more and more off-topic here, but anyhow: According to
me, the use of unwrap is inherently related to measurement instruments
that wrap around, like rotation encoders, interferometers or up/down
counters. Say you have a real phase step of +1.5 pi, how could you
possibly discern if from a real phase step of -pi/2? This is like an
aliasing problem, so the only real solution would be to increase the
sampling speed of your system. To me, the discontinuity parameter is
serving some hard to explain corner case (see matlab manual), which is
better left to be solved by hand in cases it appears. I regret matlab
ever added the feature.

> If you want your feature to be accepted, please submit a patch that does not break
> backwards compatibility and which updates the docstring and tests appropriately.
> I look forward to seeing the complete patch! Thank you.

I think my 'cycle' argument does have real uses, like the degrees in
this thread and the digital-counter example (which comes from own
experience and required me to write my own unwrap). I'll try to submit
a non-breaking patch if I ever have time.

Bas