Re: [matplotlib-devel] Help with scatter
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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] Crosshai cursor or Selector with matplotlib.backends.backend_wxagg
[EMAIL PROTECTED] 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Repeating docs
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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
On Tue, Nov 11, 2008 at 10:35 AM, Ryan May <[EMAIL PROTECTED]> 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
John Hunter wrote: > On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Repeating docs
Ryan May wrote: > John Hunter wrote: > >> On Tue, Nov 11, 2008 at 1:38 PM, Ryan May <[EMAIL PROTECTED]> 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 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] modification of update_path_extents?
Mike, A bug was recently pointed out: axhline, axvline, axhspan, axvspan mess up the ax.dataLim. I committed a quick fix for axhline and axvline, but I don't think that what I did is a good solution, so before doing anything for axhspan and axvspan I want to arrive at a better strategy. What is needed is a clean way to specify that only the x or the y part of ax.dataLim be updated when a line or patch (or potentially anything else) is added. This is specifically for the case, as in *line, where one axis is in data coordinates and the other is in normalized coordinates--we don't want the latter to have any effect on the dataLim. This could be done in python in any of a variety of ways, but I suspect that to be most consistent with the way the transforms code is now written, relying on update_path_extends from _path.cpp, it might make sense to append two boolean arguments to that cpp function, "update_x" and "update_y", and use kwargs in Bbox.update_from_path and siblings to set these, with default values of True. What do you think? If you agree to the _path.cpp change strategy, do you prefer to do that yourself, or would you rather that I try it first? Any suggestions and/or contributions are welcome. Thanks. Eric - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Fwd: Re: Patch for scatter plot legend enhancement]
Patch against today's svn is attached. Sorry for the long delay... Right now, "scatterpoints" is just set to 3 in Legend.__init__, but presumably that should be an rcParam... On Fri, Oct 31, 2008 at 2:42 AM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: > Sorry Erik. > Can you make a new patch against the current SVN? > Some of the patch was applied (but without scatterpoints option) in the SVN. > Thanks, > > -JJ > > > > > On Thu, Oct 30, 2008 at 1:58 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: >> No more thoughts on this? Or was some version of the patch committed? >> >> On Mon, Oct 20, 2008 at 12:16 PM, Erik Tollerud <[EMAIL PROTECTED]> wrote: >>> Actually, looking more closely, there is one thing that's still >>> bothering me: as it is now, it's impossible to have, say, 2 points >>> for plotted values, and 3 points for scatter plots on the same legend >>> (you have to give a numpoints=# command that's shared by everything in >>> the legend, if I'm understanding it). It'd be nice to have a >>> property, say, "scatterpoints" (and presumably then an associated >>> rcParam "legend.scatterpoints" ) that sets the number of points to use >>> for scatter plots. That way, I can make plots just like in the >>> original form, but it can also be the same number for both if so >>> desired. I've attached a patch based on the last one that does this, >>> although it probably needs to be changed to allow for an rcParam >>> 'legend.scatterplot' (I don't really know the procedure for adding a >>> new rcParam). >>> >>> On Mon, Oct 20, 2008 at 3:22 AM, Erik Tollerud <[EMAIL PROTECTED]> wrote: The current patch looks good to me... it satisfies all the use cases I had in mind, and I can't think of much else that would be wanted. Thanks! I also very much like the idea of the "sizebar," although that's probably a substantially larger job to implement. I may look into it though, time permitting... On Sat, Oct 18, 2008 at 7:04 PM, Jae-Joon Lee <[EMAIL PROTECTED]> wrote: >> To help clarify the original purpose of "update_from": I wrote this >> method when writing the original legend implementation so the legend >> proxy objects could easily copy their style attributes from the >> underlying objects they were a proxy for (so not every property is >> copied, eg the xdata for line objects is not copied). So the >> operating question should be: what properties do I need to copy to >> make the legend representation of the object. While you are in >> there, perhaps you could clarify this in the docstrings of the >> update_from method. > > Thanks for clarifying this, John. > > Manuel, > The patch looks good to me. We may submit the patch (I hope Erik is > okay with the current patch) and it would be great if you handle the > submission. > > -JJ > > > > > > On Fri, Oct 17, 2008 at 9:45 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: >> Jae-Joon Lee wrote: >>> Thanks Manuel. >>> >>> Yes, we need rotation value and etc, but my point is, do we need to >>> update it within the update_from() method? Although my preference is >>> not to do it, it may not matter much as far as we state what this >>> method does clearly in the doc. >> >> Okay, it's probably better to create the object correctly (numsides ...) >> instead of copying the properties (see also JDHs mail !) >> >>> And, in your patch, I don't think updating the numsides value has any >>> effect as it does not recreate the paths. >>> >>> I'm attaching the revised patch. In this patch, update_from() only >>> update gc-related properties. And numsides, size, and rotations are >>> given during the object creation time. >> >> Yes, this looks better. But creating handle_sizes is a little bit too >> much effort. This is done internally. It will do passing a sizes list, >> that may or may not be shorter/longer than numpoints (see revised patch). >> >> I also changed the way the yoffsets are updated in _update_positions(). >> >> One additional thing I have in mind (for a later time) is a "sizesbar" >> similar to a colorbar where you can read off values corresponding to >> marker sizes... >> >> Cheers, >> Manuel >> >>> Erik, >>> I see your points. My main concern is that the yoffsets makes the >>> results a bit funny when numpoints is 2. The attached patch has a >>> varying sizes of [0.5*(max+min), max, min]. The yoffsets are only >>> introduced when numpints > 2 and you can also provide it as an >>> optional argument. >>> >>> Regards, >>> >>> -JJ >>> >>> >>> On Thu, Oct 16, 2008 at 8:43 PM, Manuel Metz <[EMAIL PROTECTED]> wrote: Manuel Metz wrote: > Jae-Joon Lee wrote: >> Hi Manuel, >> >> I think it is a good to introduce the update_from met
