matplotlib-devel Mailing List for matplotlib

Ryan May wrote:
> John Hunter wrote:
>   
>> On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <rm...@gm...> wrote:
>>
>>     
>>> 1) Have psd(x) call csd(x,x)
>>> 2) Have csd() check if y is x, and if so, avoid doing the extra work.
>>>
>>> Would this be an acceptable solution to reduce code duplication?
>>>       
>> Sure, that should work fine.
>>     
>
> Ok, I noticed that specgram() duplicated much of the same code, so I
> factored it all out and made a _spectral_helper() function, which pretty
> much implements a cross-spectrogram.  csd() and specgram() use this, and
> then psd still calls csd().  Now all of the spectral analysis stuff is
> using the same computational code base.
>
>   
>>> On a separate note, once I get done with these tweaks, are there any
>>> objections to submitting something based on this to scipy?
>>>       
>> No objections here -- if it were put into numpy though, we could
>> depend on it and avoid the duplication.  I would campaign for numpy
>> first, eg np.fft.psd, etc.
>>     
>
> I agree it'd be better for us if it went to numpy, but I've gotten the
> sense that they're not really receptive to adding things like this now.
> I'll give it a try, but I sense that scipy.signal would end up being a
> more likely home.  That wouldn't help us with duplication, but would
> help the community at large.  It's always bugged me that I can't just
> grab a psd() function from my general computing packages. (In my
> opinion, anything in mlab that doesn't involve plotting should really
> exist in a more general package.)
There's an interesting case to be made here for modules shared between
packages at the version-control-system and bug tracking level (e.g. in a
DVCS type system) but installed in separate namespaces and shipped
independently when it was time for source and binary distributions of
the package to be made. There'd be duplication at the install and
distribution level, but at least not at the source level. I'd guess the
linux packagers would also find a way to reduce duplication at those
other levels, too, for their systems.

It seems to me that this would reduce a lot of the developer angst about
having multiple sources for the same things, while still making things
easy on the users.

However, I don't know any VCS that would facilitate such a thing...

-Andrew

John Hunter wrote:
> On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <rm...@gm...> wrote:
> 
>> 1) Have psd(x) call csd(x,x)
>> 2) Have csd() check if y is x, and if so, avoid doing the extra work.
>>
>> Would this be an acceptable solution to reduce code duplication?
> 
> Sure, that should work fine.

Ok, I noticed that specgram() duplicated much of the same code, so I
factored it all out and made a _spectral_helper() function, which pretty
much implements a cross-spectrogram.  csd() and specgram() use this, and
then psd still calls csd().  Now all of the spectral analysis stuff is
using the same computational code base.

>> On a separate note, once I get done with these tweaks, are there any
>> objections to submitting something based on this to scipy?
> 
> No objections here -- if it were put into numpy though, we could
> depend on it and avoid the duplication.  I would campaign for numpy
> first, eg np.fft.psd, etc.

I agree it'd be better for us if it went to numpy, but I've gotten the
sense that they're not really receptive to adding things like this now.
I'll give it a try, but I sense that scipy.signal would end up being a
more likely home.  That wouldn't help us with duplication, but would
help the community at large.  It's always bugged me that I can't just
grab a psd() function from my general computing packages. (In my
opinion, anything in mlab that doesn't involve plotting should really
exist in a more general package.)

Ryan

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

On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <rm...@gm...> wrote:

> 1) Have psd(x) call csd(x,x)
> 2) Have csd() check if y is x, and if so, avoid doing the extra work.
>
> Would this be an acceptable solution to reduce code duplication?

Sure, that should work fine.

> On a separate note, once I get done with these tweaks, are there any
> objections to submitting something based on this to scipy?

No objections here -- if it were put into numpy though, we could
depend on it and avoid the duplication.  I would campaign for numpy
first, eg np.fft.psd, etc.

JDH

John Hunter wrote:
>> In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
>> the keyword args for psd() and csd(). In fact, csd() doesn't document
>> them itself, but just references psd().  Additionally, the csd() and
>> psd() Axes methods duplicate these docs, with a few additional
>> parameters.  Would it be a good thing to restructure the duplicated docs
>> into it's own string that can be incorporated when necessary?  Or is
>> this kind of "monkey patching" of the docs something we're trying to
>> minimize?
> 
> No, this is something we are doing more of lately (eg see the contour
> docs) but the psd, csd, cohere predated this docstring manipulation.
> So feel free to consolidate.

I've done psd and csd so far.  I might get to cohere (and spectrogram)
later.  It got a little ugly doing the axes methods, since you can only
use a single dictionary for string replacement.

On a separate note, there is *A LOT* of code duplication between psd()
and csd() in mlab.  It's bugged me while I've been doing these tweaks,
but the problem was that csd() would end up doing an extra FFT vs. the
same call to psd. I think I might finally have a solution:

1) Have psd(x) call csd(x,x)
2) Have csd() check if y is x, and if so, avoid doing the extra work.

Would this be an acceptable solution to reduce code duplication?

On a separate note, once I get done with these tweaks, are there any
objections to submitting something based on this to scipy?

Ryan

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

On Tue, Nov 11, 2008 at 10:35 AM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
> the keyword args for psd() and csd(). In fact, csd() doesn't document
> them itself, but just references psd().  Additionally, the csd() and
> psd() Axes methods duplicate these docs, with a few additional
> parameters.  Would it be a good thing to restructure the duplicated docs
> into it's own string that can be incorporated when necessary?  Or is
> this kind of "monkey patching" of the docs something we're trying to
> minimize?

No, this is something we are doing more of lately (eg see the contour
docs) but the psd, csd, cohere predated this docstring manipulation.
So feel free to consolidate.

JDH

Hi,

In tweaking mlab.psd(), I'm noticing there is a lot of overlap between
the keyword args for psd() and csd(). In fact, csd() doesn't document
them itself, but just references psd().  Additionally, the csd() and
psd() Axes methods duplicate these docs, with a few additional
parameters.  Would it be a good thing to restructure the duplicated docs
into it's own string that can be incorporated when necessary?  Or is
this kind of "monkey patching" of the docs something we're trying to
minimize?

Ryan

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

ja...@be... schrieb:
> Dear all,
>
> after looking around for a plotting library I found Matplotlib and I tried to create a gray scale image in a wxpython application. Looks good!
>
> Now I have to find a line in the image with mainly vertical orientation. To do this a crosshair cursor would be fine. In Pylab I found a SpanSelector which also looks promising. 
>
> Unfortunately I failed in adding a crosshair cursor or a SpanSelector into my wxpython application figure.
>
>   
try

from matplotlib.widgets import Cursor
help(Cursor)

If this is not enough, I have once written a Crosshair very similar to 
SpanSelector - but I don't have it at hand at the moment.

Gregor

Eric Firing wrote:
> Ryan,
> 
> I hope you don't mind--I took care of the "FIXME" that I had put in, and
> committed the whole thing.  Your test passes, and the backend_driver.py
> seems happy, so it should be OK.

You have stolen my glory! :)  Actually, I was thinking at this point it
was more your patch anyways, and I had just done the work of tracking
down all the problem spots. Saves me the effort of doing the checkin. :)

Ryan

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

Ryan May wrote:
> On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <ef...@ha... 
> <mailto:ef...@ha...>> wrote:
> 
>     Ryan May wrote:
> 
>         Ok, here's a patch that fixes the problem for me, as well as a test
>         script that tests a bunch of the color options along with having
>         more,
>         the same, and less than the number of points passed in.
> 
>         This is triggered by passing in a sequence of strings of the
>         same length
>         as x, which matplotlib interprets as needing colormapping.
>          Colormapping
>         an array of strings explodes nicely.  I've fixed this issue by:
> 
>         1) Make scatter() check if c is a sequence of strings.  If it
>         is, use
>         the colorConverter as expected.
> 
>         2) This requires changing is_string_like() to recognize elements
>         from
>         numpy string arrays (type numpy.string_) as strings.  These
>         elements are
>         actually instances of a subclass of python strings
>         (isinstance(<element>, str is True), but fail because they have
>         a shape
>         attribute (which is explicitly checked).
> 
>         3) Changing colorConverter.to_rgba_array() to accept a 1D numpy
>         array
>         containing strings.  Currently, there is an explicit check for a 2D
>         array, and if it is not, and exception is thrown.
> 
>         Since this is my first mucking around in internals with which I
>         am not
>         familiar, I'd like someone to double check me.  It's only a 3
>         line diff,
>         but each line is in a different file, so it's got a pretty wide
>         (though
>         thin) footprint.
> 
> 
>     Ryan,
> 
>     Here is a modification of your patch that I think will be very
>     slightly more efficient and general.
> 
> 
> Thanks.  That does look a lot more clean.  It would have helped if I had 
> known about dtype.kind for ease of testing for arrays of strings and 
> numpy string scalars.
> 
> Anyone else?

Ryan,

I hope you don't mind--I took care of the "FIXME" that I had put in, and 
committed the whole thing.  Your test passes, and the backend_driver.py 
seems happy, so it should be OK.

Eric

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

On Mon, Nov 10, 2008 at 5:54 PM, Eric Firing <ef...@ha...> wrote:

> Ryan May wrote:
>
>> Ok, here's a patch that fixes the problem for me, as well as a test
>> script that tests a bunch of the color options along with having more,
>> the same, and less than the number of points passed in.
>>
>> This is triggered by passing in a sequence of strings of the same length
>> as x, which matplotlib interprets as needing colormapping.  Colormapping
>> an array of strings explodes nicely.  I've fixed this issue by:
>>
>> 1) Make scatter() check if c is a sequence of strings.  If it is, use
>> the colorConverter as expected.
>>
>> 2) This requires changing is_string_like() to recognize elements from
>> numpy string arrays (type numpy.string_) as strings.  These elements are
>> actually instances of a subclass of python strings
>> (isinstance(<element>, str is True), but fail because they have a shape
>> attribute (which is explicitly checked).
>>
>> 3) Changing colorConverter.to_rgba_array() to accept a 1D numpy array
>> containing strings.  Currently, there is an explicit check for a 2D
>> array, and if it is not, and exception is thrown.
>>
>> Since this is my first mucking around in internals with which I am not
>> familiar, I'd like someone to double check me.  It's only a 3 line diff,
>> but each line is in a different file, so it's got a pretty wide (though
>> thin) footprint.
>>
>
> Ryan,
>
> Here is a modification of your patch that I think will be very slightly
> more efficient and general.
>

Thanks.  That does look a lot more clean.  It would have helped if I had
known about dtype.kind for ease of testing for arrays of strings and numpy
string scalars.

Anyone else?

Ryan

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

On Ubuntu 8.10 (Intrepid Ibex) I'm using matplotlib 0.98.3 and would
like to use the markerscale to make my legend points smaller (e.g.
0.6).  However, it does not appear to be working.  The following code:

plot(arange(0, 100, .1), cos(arange(0, 100, .1)), 'ro', markersize=20,
lable='test')
legend(markerscale=0.5)

draws a legend that has markers the same size as the original plot.  I
saw someone posted on September 24, and had a response from someone.
For some reason, the response was blank (at least as it appears in the
list archives), so I thought I'd send another message to see if anyone
had figured out what needs to be done to get markerscale working?

Thanks
Orest