[matplotlib-devel] hexbin, mincnt
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. Index: lib/matplotlib/axes.py === --- lib/matplotlib/axes.py (revision 6777) +++ lib/matplotlib/axes.py (working copy) @@ -5395,9 +5395,6 @@ d1 = (x-ix1)**2 + 3.0 * (y-iy1)**2 d2 = (x-ix2-0.5)**2 + 3.0 * (y-iy2-0.5)**2 bdist = (d1-- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] hexbin, mincnt
On Mon, Jan 12, 2009 at 3:29 AM, T J 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 -- 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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] Jagged plot in macosx backend
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 Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Matplotlib patch on EPD trac?
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 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 -- 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
Re: [matplotlib-devel] Matplotlib patch on EPD trac?
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
Re: [matplotlib-devel] Matplotlib patch on EPD trac?
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 -- 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
[matplotlib-devel] refactoring for units; was Re: John: Thoughts on a standard test system
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 -- 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
