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’m not sure what’s going on with my subscription request e-mail. So
I’ll reply-all and see what happens…

I can’t speak too strongly about what should be there but I certainly
like Ryan’s 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’t result in a “yes, we’ll apply it”
response, we’ll hold off on applying this patch to the matplotlib build
we ship inside EPD until you guys figure out which way you’re
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