matplotlib-devel Mailing List for matplotlib (Page 4)

On Wed, Jan 14, 2009 at 14:14, John Travers <jt...@gm...> wrote:
> On Wed, Jan 14, 2009 at 8:10 AM, Sandro Tosi <mo...@de...> wrote:
>> Hi all,
>> due to some requests came lately, I decided to upload the "temp"
>> Debian package for 0.98.5.2.
>>
>> They are available at [1].
>
> Any chance you could add them to your apt repository?
I was wondering that, for the time being, I could upload to
experimental: developers, do you have any plan to release .3 soon? If
not, and upload to our "experimental" area (that's a sort of unstable,
but with packages not ready for prime time) could be an easy way for
our users to have mpl on Debian system. Let me know, the package is
ready, just needs the upload.
Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Hi all,
due to some requests came lately, I decided to upload the "temp"
Debian package for 0.98.5.2.
They are available at [1]. If you're using an amd64 architecture, then
you can take all those python-matplotlib*.deb and "sudo dpkg -i
....deb" them, if you're using another architecture, then (needs
devscripts, build-essential installed):
dget -x http://people.debian.org/~morph/matplotlib_0.98.5.2-1.dsc
cd matplotlib-0.98.5.2
debuild -us -uc
At this stage, the command will fails because there are some missing
packages needed to build mpl. They are listed, so take them and
"aptitude install <package list>". You need both unstable and
experimental repository in your /etc/apt/sources.list. Reiterate this
process until the building proceeds.
After a while (30mins ~ 1.5h) you'll have in .. the deb files to
install on your machine.
The building "guidelines" above are not complete, as it can't be in
this email; in case of problem, reply to the lists, so other can
leverage the replies.
Cheers,
Sandro
[1] http://people.debian.org/~morph/
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

This is indeed a bug. In some places in the code, I was casting from double to float (which is used by Mac OS X quartz internally) too soon. This created a roundoff error, which shows up as the jagged plot. I am preparing a patch and will submit it as soon as possible.
Thanks for reporting this bug.
--Michiel.
--- On Mon, 1/12/09, Tony Yu <ts...@gm...> wrote:
> From: Tony Yu <ts...@gm...>
> Subject: [matplotlib-devel] Jagged plot in macosx backend
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, January 12, 2009, 2:59 PM
> There appears to be a bug in the macosx backend. When I plot
> large numbers with small variations in the value, the
> numbers seem to be coarsely rounded off. This bug
> doesn't appear with other backends (I tried WxAgg and
> TkAgg). Below is a simple script showing the problem and the
> resulting plot on the macosx backend.
> 
> Thanks,
> -Tony
> 
> Mac OS X 10.5.6
> Matplotlib svn r6779
> 
> #~~~~~~~~
> 
> import numpy as np
> import matplotlib.pyplot as plt
> 
> x = np.linspace(0, 1)
> plt.plot(x, x + 1e6)
> plt.show()------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

John Hunter wrote:
> On the issue of units (not unit testing but unit support which is
> motivating your writing of unit test) I think we may need a new
> approach. The current approach is to put unitized data into the
> artists, and update the converted data at the artist layer. I don't
> know that this is the proper design. For this approach to work, every
> scalar and array quantity must support units at the artist layer, and
> all the calculations that are done at the plotting layer (eg error
> bar) to setup these artists must be careful to preserve unitized data
> throughout. So it is burdensome on the artist layer and on the
> plotting function layer.
> 
> The problem is compounded because most of the other developers are not
> really aware of how to use the units interface, which I take
> responsibility for because they have oft asked for a design document,
> which I have yet to provide because I am unhappy with the design. So
> new code tends to break functions that once had unit support. Which
> is why we need unit tests ....
> 
> I think everything might be easier if mpl had an intermediate class
> layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we
> already do for Legend. The plotting functions would instantiate these
> objects with the input arguments and track unit data through the
> reference to the axis. These plot objects would contain all the
> artist primitives which would store their data in native floating
> point, which would remove the burden on the artists from handling
> units and put it all in the plot creation/update logic. The objects
> would store references to all of the original inputs, and would update
> the primitive artists on unit changes. The basic problem is that the
> unitized data must live somewhere, and I am not sure that the low
> level primitive artists are the best place for that -- it may be a
> better idea to keep this data at the level of a PlotItem and let the
> primitive artists handle already converted floating point data. This
> is analogous to the current approach of passing transformed data to
> the backends to make it easier to write new backends. I need to chew
> on this some more.
John,
I think that getting unit support out of the basic artists, and keeping 
it at a higher level, is an excellent idea. Right now, unit support is 
sprinkled all over, and one never knows exactly where it will be or what 
to expect. Most of it works, but some doesn't. (I just fixed a part 
that didn't.)
One could go a little farther with this and require that more of the 
argument checking and regularization be done above the artist level as 
well; so that the artists could count on arrays of coordinates being 
ndarrays or masked arrays, for example. Whether the resulting code 
simplification would be worth the extra care required in using the 
artists, I don't know.
I also like the PlotItem concept as a way to get Axes under control and 
slimmed down. It is the approach taken with Quiver, Contour, and 
Colorbar, so there is more precedent than just Legend.
I'm not sure that a complete PlotItem-ization is required for localizing 
the unit support at a higher level than the basic artists; maybe it can 
be done piecemeal. A complete one-shot reworking would be a big job, 
requiring a lot of testing.
Eric

Paul Kienzle wrote:
> 
> 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.
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
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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

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
>>
>> On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson <dpe...@en...> 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. :-)
>>> 
>
> 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

There appears to be a bug in the macosx backend. When I plot large 
numbers with small variations in the value, the numbers seem to be 
coarsely rounded off. This bug doesn't appear with other backends (I 
tried WxAgg and TkAgg). Below is a simple script showing the problem 
and the resulting plot on the macosx backend.
Thanks,
-Tony
Mac OS X 10.5.6
Matplotlib svn r6779
#~~~~~~~~
import numpy as np
import matplotlib.pyplot as plt
x = np.linspace(0, 1)
plt.plot(x, x + 1e6)
plt.show()

On Mon, Jan 12, 2009 at 3:29 AM, T J <tj...@gm...> wrote:
> It looks like mincnt is used only when C is not None. For the default
> histogram method, I've found it useful to be able to turn off cells
> with fewer then *mincnt* points. Attached is a diff which implements
> this. Also, should *marginals* be True by default? It seems that
> hexbin is an alternative to scatter and since scatter doesn't have it,
> then hexbin should not have it either.
Thanks for the mincnt patch, I've applied it to svn head and made
marginals False -- I *thought* I made it False when adding it, so this
was just a screwup.
JDH

It looks like mincnt is used only when C is not None. For the default
histogram method, I've found it useful to be able to turn off cells
with fewer then *mincnt* points. Attached is a diff which implements
this. Also, should *marginals* be True by default? It seems that
hexbin is an alternative to scatter and since scatter doesn't have it,
then hexbin should not have it either.

While trying to track down the zoom bug reported by David Trem, I got 
all tangled up in what appear to be completely obsolete and unneeded 
"zoom" etc. methods. These are left over from the original 
NavigationToolbar and the pre-transforms code. I would like to see all 
of this, including the entire original NavigationToolbar, deprecated and 
then removed. My guess is that no one is actually using any of it.
Comments? Does anyone know of other cruft that we might be able to 
clean out?
Eric

It works perfectly now using svn 6776
Thanks very much to be so efficient in killing bugs !
Less than three hours after my small bug report... I'm really impressed!
David
Eric Firing a écrit :
> John Hunter wrote:
>> On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...>
>> wrote:
>>> Hi,
>>>
>>> I've just discover a problem with the pan/zoom tool.
>>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>>> zoom does not work correctly.
>>> To visualize the problem launch the small script in attachment press the
>>> pan/zoom button and use the zoom on the x axis direction -> you will see
>>> the button part of the curve directly jumping at the bottom of the graph
>>> whereas you would expected it not to move...
>>> I evidence this problem using GTKAgg but also with the OSX backend (did
>>> not try other backend).
>>> Matplotlib version is the latest svn on a MacOS X platform.
>>
>> I don't think I see this -- if you hold down the 'x' while you are
>> panning, the zoom will be constrained in the x direction and I see no
>> unusual movement. If I release the 'x' but still zoom horizontally,
>> there is some motion in the vertical direction, but that is because I
>> cannot move precisely horizontally. Could you be more precise about
>> the artifact you are seeing. For me, the bottom part of the curve is
>> at (0, 10^0) and and I do not see any unusual behavior there
> 
> John,
> 
> I reproduced the problem (jumpy boundary with log scale and zoom) and
> fixed it in my last two commits (6773 to maint and 6775 merging to trunk).
> 
> Eric
> 
> 
>>
>> ------------------------------------------------------------------------------
>>
>> Check out the new SourceForge.net Marketplace.
>> It is the best place to buy or sell services for
>> just about anything Open Source.
>> http://p.sf.net/sfu/Xq1LFB
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 

On Sat, Jan 10, 2009 at 2:49 PM, Darren Dale <dsd...@gm...> wrote:
>> Never had any luck getting a tester, so I went ahead and committed
>> this to the trunk. I should probably get a working qt backend for
>> testing on one of the machines I use....
>
> I'm sorry John, I didnt see your original request for testing.
>
> I tried running the following with interactive on and off:
> I didnt notice any significant diffference in speed in the two modes with
> the qt4agg backend, and the figures looked fine. Is there anything else I
> should be looking for?
No, that should do it -- thanks for taking a look.
JDH

John Hunter wrote:
> On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...> wrote:
>> Hi,
>>
>> I've just discover a problem with the pan/zoom tool.
>> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
>> zoom does not work correctly.
>> To visualize the problem launch the small script in attachment press the
>> pan/zoom button and use the zoom on the x axis direction -> you will see
>> the button part of the curve directly jumping at the bottom of the graph
>> whereas you would expected it not to move...
>> I evidence this problem using GTKAgg but also with the OSX backend (did
>> not try other backend).
>> Matplotlib version is the latest svn on a MacOS X platform.
> 
> I don't think I see this -- if you hold down the 'x' while you are
> panning, the zoom will be constrained in the x direction and I see no
> unusual movement. If I release the 'x' but still zoom horizontally,
> there is some motion in the vertical direction, but that is because I
> cannot move precisely horizontally. Could you be more precise about
> the artifact you are seeing. For me, the bottom part of the curve is
> at (0, 10^0) and and I do not see any unusual behavior there
John,
I reproduced the problem (jumpy boundary with log scale and zoom) and 
fixed it in my last two commits (6773 to maint and 6775 merging to trunk).
Eric
> 
> ------------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for
> just about anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Sat, Jan 10, 2009 at 3:09 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Dec 30, 2008 at 10:57 AM, John Hunter <jd...@gm...> wrote:
> > On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon <mjl...@ya...>
> wrote:
> >
> >> I have written such a function for the qt4 backend; see patch #2468809
> at
> >>
> >>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2468809&group_id=80706&atid=560722
> >>
> >> I am not a big qt4 user, so it would be good if somebody else could look
> at this patch before adding it to the trunk.
> >
> > I would like to apply this patch, but I am not a qt user either, so if
> > someone could test this and get back to us, that would be great.
>
> Never had any luck getting a tester, so I went ahead and committed
> this to the trunk. I should probably get a working qt backend for
> testing on one of the machines I use....
>
I'm sorry John, I didnt see your original request for testing.
I tried running the following with interactive on and off:
from pylab import *
import numpy
figure()
x=numpy.arange(20)
y=1+x**2
n = 4
for i in range(n*n):
 subplot(n,n,i+1)
 bar(x,y,log=True)
 xlim(-5,25)
 ylim(1,1e4)
I didnt notice any significant diffference in speed in the two modes with
the qt4agg backend, and the figures looked fine. Is there anything else I
should be looking for?
Darren

On Tue, Dec 30, 2008 at 10:57 AM, John Hunter <jd...@gm...> wrote:
> On Fri, Dec 26, 2008 at 8:40 AM, Michiel de Hoon <mjl...@ya...> wrote:
>
>> I have written such a function for the qt4 backend; see patch #2468809 at
>>
>> https://sourceforge.net/tracker/index.php?func=detail&aid=2468809&group_id=80706&atid=560722
>>
>> I am not a big qt4 user, so it would be good if somebody else could look at this patch before adding it to the trunk.
>
> I would like to apply this patch, but I am not a qt user either, so if
> someone could test this and get back to us, that would be great.
Never had any luck getting a tester, so I went ahead and committed
this to the trunk. I should probably get a working qt backend for
testing on one of the machines I use....
JDH

On Sat, Jan 10, 2009 at 9:28 AM, Michiel de Hoon <mjl...@ya...> wrote:
> I've written a patch for the Mac OS X native backend to make use of the new hatching support; see patch #2497785 at
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=2497785&group_id=80706&atid=560722
>
> I tested this with the new hatch_demo.py in SVN trunk, and it seems to work fine.
Thanks Michiel, I committed this patch to the trunk and closed the
item on the sf tracker.
JDH

On Sat, Jan 10, 2009 at 12:28 PM, David Trem <dav...@gm...> wrote:
> Hi,
>
> I've just discover a problem with the pan/zoom tool.
> When using the pan/zoom tool (in the toolbar) on a semilogy plot the
> zoom does not work correctly.
> To visualize the problem launch the small script in attachment press the
> pan/zoom button and use the zoom on the x axis direction -> you will see
> the button part of the curve directly jumping at the bottom of the graph
> whereas you would expected it not to move...
> I evidence this problem using GTKAgg but also with the OSX backend (did
> not try other backend).
> Matplotlib version is the latest svn on a MacOS X platform.
I don't think I see this -- if you hold down the 'x' while you are
panning, the zoom will be constrained in the x direction and I see no
unusual movement. If I release the 'x' but still zoom horizontally,
there is some motion in the vertical direction, but that is because I
cannot move precisely horizontally. Could you be more precise about
the artifact you are seeing. For me, the bottom part of the curve is
at (0, 10^0) and and I do not see any unusual behavior there

Hi,
 I've just discover a problem with the pan/zoom tool.
When using the pan/zoom tool (in the toolbar) on a semilogy plot the
zoom does not work correctly.
To visualize the problem launch the small script in attachment press the
pan/zoom button and use the zoom on the x axis direction -> you will see
the button part of the curve directly jumping at the bottom of the graph
 whereas you would expected it not to move...
I evidence this problem using GTKAgg but also with the OSX backend (did
not try other backend).
Matplotlib version is the latest svn on a MacOS X platform.
Thanks in advance,
David

I've written a patch for the Mac OS X native backend to make use of the new hatching support; see patch #2497785 at
https://sourceforge.net/tracker/index.php?func=detail&aid=2497785&group_id=80706&atid=560722
I tested this with the new hatch_demo.py in SVN trunk, and it seems to work fine.
--Michiel
--- On Mon, 12/29/08, Michael Droettboom <md...@st...> wrote:
> From: Michael Droettboom <md...@st...>
> Subject: [matplotlib-devel] Hatching support
> To: "matplotlib development list" <mat...@li...>
> Date: Monday, December 29, 2008, 9:20 AM
> I've refactored hatching support to move the hatch
> design itself to the 
> core, added support for them in the Agg and SVG backends,
> and simplified 
> their usage in the PDF and PS backends. It should now be
> easier to add 
> new hatch styles if anyone ever feels artistic.
> 
> In order to use the same general approach in all backends,
> the PS 
> backend now uses the makepattern command rather than a loop
> to draw each 
> hatch line. That may be a regression in certain situations
> (eg., old PS 
> printers without enough memory). So those who were using
> the old PS 
> backend with hatches should test the new approach and
> report any problems.
> 
> Mike
> 
> -- 
> Michael Droettboom
> Science Software Branch
> Operations and Engineering Division
> Space Telescope Science Institute
> Operated by AURA for NASA
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
 

I noticed today, through a fault in my own code, that imshow produces a
maximum recursion error if passed an extents list of strings instead of
numbers. Its kind of a rediculous scenario, but I thought I should bring it
up just in case.
Darren

Hi,
I'm sending a little module I use to force a particular version of 
matplotlib and backend in my library.
This is imported in my package __init__.py to make sure the 
environment is sane. It can also be imported in the beginning of the 
app to set up a sane environment, which may be necessary if the app 
uses matplotlib outside my library.
I don't think there is anything we can do within matplotlib to 
address the version requirements.
The backend check could be a little easier if we modify matplotlib.use 
() to be silent if the backend is already in use, or raise an error 
if it isn't. ImportError seems appropriate, since use() is kind of 
like an import. Calling switch_backend() is another option.
 - Paul

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
> 
> On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson <dpe...@en...> 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. :-)
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
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

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
On Fri, Jan 9, 2009 at 2:45 PM, Dave Peterson <dpe...@en...> 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. :-)
>
>
> -- Dave
>
>

Howdy,
On Tue, Jan 6, 2009 at 7:58 AM, Drain, Theodore R
<the...@jp...> wrote:
> OK - nose it is. How do you want to handle the dependency? My opinion is that since tests are development tools, it's not unreasonable to require that nose be installed by the developer and not as an embedded dependency in MPL (or at least that should be an option).
Don't forget to have a look at numpy's extra nose support, which may
come in handy for you (and since you already have a numpy dependency,
you can use it at will):
http://projects.scipy.org/scipy/numpy/browser/trunk/numpy/testing
There's a lot of handy stuff in there. Suitable use of decorators
make it very easy to tag tests for skipping under certain conditions
(no X, no WX, etc). I've improved the code in numpy in my local
ipython tree for that but haven't pushed it yet, ping me for the code
if you need it quickly.
Yay for testing!
f