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.
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 ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
