Matplotlib patch on EPD trac?

Ryan May has been doing all the heavy lifting with respect to PSD and
specgram, so I am going to turf this to him :slight_smile: It may be that the
bug filer's problems are resolved in the recent changes in 98.5.2, but
Ryan should confirm

路路路

On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson <dpeterson@...492...> wrote:

Hi John,

Sorry for sending this directly, but I'm still waiting for my matplotlib
devel mailing subscription to go through....

We've just had an EPD user submit a patch for matplotlib to 'fix' a problem
they were seeing with the PSD function. Is this a known issue or something
that you'd be interested in including in future versions of matplotlib? Or
is it something that you disagree is 'right'?

聽聽https://svn.enthought.com/epd/ticket/581

I'd like to know to do the right thing with the matplotlib we include in
EPD. :slight_smile:

-- Dave

John Hunter wrote:

Ryan May has been doing all the heavy lifting with respect to PSD and
specgram, so I am going to turf this to him :slight_smile: It may be that the
bug filer's problems are resolved in the recent changes in 98.5.2, but
Ryan should confirm

Hi John,

Sorry for sending this directly, but I'm still waiting for my matplotlib
devel mailing subscription to go through....

We've just had an EPD user submit a patch for matplotlib to 'fix' a problem
they were seeing with the PSD function. Is this a known issue or something
that you'd be interested in including in future versions of matplotlib? Or
is it something that you disagree is 'right'?

聽聽https://svn.enthought.com/epd/ticket/581

I'd like to know to do the right thing with the matplotlib we include in
EPD. :slight_smile:

Specgram specifically handles the case of moving frequencies to -Fs/2 to Fs/2,
instead of 0 to Fs. It was this way before I did any of my changes and I just
left it as it was. Psd returns frequencies 0 to Fs for Matlab compatibility (I
think anyways, John?). Personally, I'd also prefer to have -Fs/2 to Fs/2
returned as well, so I don't have to do it in my own code. However, I'm also
loath to add yet another flag to toggle Matlab compatibility.

As far as the patch goes, it looks fine. It won't work as is with the
refactoring I've already done in SVN, but it wouldn't be hard to implement the
changes, if we decide to go that way.

Maybe it's time to refactor here to get routine(s) that operate how we want (IMO
more sanely than Matlab), and we provide wrappers that give Matlab-like behavior.
聽聽Maybe we can also get these sane routines upstream into Scipy. At that point,
however, I'm not sure what to do about the plotting functions, since there's a
variety of behavior.

Thoughts?

Ryan

路路路

On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson <dpeterson@...492...> wrote:

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Ryan May wrote:

John Hunter wrote:
 Ryan May has been doing all the heavy lifting with respect to PSD and
specgram, so I am going to turf this to him :-) It may be that the
bug filer's problems are resolved in the recent changes in 98.5.2, but
Ryan should confirm

Hi John,
Sorry for sending this directly, but I'm still waiting for my matplotlib
devel mailing subscription to go through....
We've just had an EPD user submit a patch for matplotlib to 'fix' a problem
they were seeing with the PSD function. Is this a known issue or something
that you'd be interested in including in future versions of matplotlib? Or
is it something that you disagree is 'right'?
I'd like to know to do the right thing with the matplotlib we include in
EPD. :-)

Specgram specifically handles the case of moving frequencies to -Fs/2 to Fs/2,
instead of 0 to Fs. It was this way before I did any of my changes and I just
left it as it was. Psd returns frequencies 0 to Fs for Matlab compatibility (I
think anyways, John?). Personally, I'd also prefer to have -Fs/2 to Fs/2
returned as well, so I don't have to do it in my own code. However, I'm also
loath to add yet another flag to toggle Matlab compatibility.
As far as the patch goes, it looks fine. It won't work as is with the
refactoring I've already done in SVN, but it wouldn't be hard to implement the
changes, if we decide to go that way.
Maybe it's time to refactor here to get routine(s) that operate how we want (IMO
more sanely than Matlab), and we provide wrappers that give Matlab-like behavior.
Maybe we can also get these sane routines upstream into Scipy. At that point,
however, I'm not sure what to do about the plotting functions, since there's a
variety of behavior.
Thoughts?
Ryan

Hi Guys,

I鈥檓 not sure what鈥檚 going on with my subscription request e-mail. So
I鈥檒l reply-all and see what happens鈥

I can鈥檛 speak too strongly about what should be there but I certainly
like Ryan鈥檚 idea of getting more sane behavior and simultaneously
providing a wrapper / second API entry point to get the Matlab
compatible behavior.

As far as EPD goes, since this didn鈥檛 result in a 鈥測es, we鈥檒l apply it鈥
response, we鈥檒l hold off on applying this patch to the matplotlib build
we ship inside EPD until you guys figure out which way you鈥檙e
headed. It clearly seems wrong to have different, non-bug, behavior
between your releases and EPD.

鈥 Dave

路路路

<dpeterson@鈥492鈥>https://svn.enthought.com/epd/ticket/581

My policy when working on Octave was to avoid inventing new interfaces when the existing interfaces are good enough. This doesn't apply to the same degree in pylab of course because there is little hope of running matlab code directly off the net, but it still helps users if things with the same name share the same interface. It would not be good if importing psd from the matlab compatibility package gave a different interface than the same function name imported directly from mpl or scipy.

In terms of refactoring, consider having a spectral density object. The following properties of psd naturally lends itself to an object interface:

聽聽聽* a number of related functions (psd, csd, transfer function, coherence) can be calculated from the same internal state
聽聽聽* the state can be fed new inputs and updated frame by frame,
聽聽聽* confidence intervals may or may not be requested,
聽聽聽* data can be plotted in multiple ways
聽聽聽* users may want to extract the data for further processing

It would be pretty easy to build the matlab interface on top of such an object.

聽聽聽- Paul

路路路

On Jan 9, 2009, at 6:12 PM, Ryan May wrote:

Maybe it's time to refactor here to get routine(s) that operate how we want (IMO
more sanely than Matlab), and we provide wrappers that give Matlab-like behavior.
聽聽Maybe we can also get these sane routines upstream into Scipy. At that point,
however, I'm not sure what to do about the plotting functions, since there's a
variety of behavior.

Paul Kienzle wrote:

Maybe it's time to refactor here to get routine(s) that operate how we
want (IMO
more sanely than Matlab), and we provide wrappers that give
Matlab-like behavior.
聽聽Maybe we can also get these sane routines upstream into Scipy. At
that point,
however, I'm not sure what to do about the plotting functions, since
there's a
variety of behavior.

My policy when working on Octave was to avoid inventing new interfaces
when the existing interfaces are good enough. This doesn't apply to the
same degree in pylab of course because there is little hope of running
matlab code directly off the net, but it still helps users if things
with the same name share the same interface. It would not be good if
importing psd from the matlab compatibility package gave a different
interface than the same function name imported directly from mpl or scipy.

I agree 100%. My thoughts were having a flexible, yet simple and straightforward
implementation in scipy/matplotlib, and reimplement psd() on top of that. I
don't think psd is a good name anyways, since it is specifically based on the
welch method. While general, this is only 1 way of estimating the psd of the signal.

In terms of refactoring, consider having a spectral density object. The
following properties of psd naturally lends itself to an object interface:

聽聽* a number of related functions (psd, csd, transfer function,
coherence) can be calculated from the same internal state
聽聽* the state can be fed new inputs and updated frame by frame,
聽聽* confidence intervals may or may not be requested,
聽聽* data can be plotted in multiple ways
聽聽* users may want to extract the data for further processing

It would be pretty easy to build the matlab interface on top of such an
object.

I hadn't thought of an OO interface, but that's not usually my primary way of
thinking. It actually sounds like a good way to go, and is, in fact, the way
MatLab has gone now. It would also allow making a class hierarchy that uses
different methods for doing these calculation (plain periodogram, welch's method,
etc.).

Some food for thought anyways.

Ryan

路路路

On Jan 9, 2009, at 6:12 PM, Ryan May wrote:

--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma