Re: [matplotlib-devel] Problem with Quiver+Basemap
Ryan May wrote: > Ping. Not sure if you missed it first time around or are just that busy. > I looked, but decided I needed to look again, and then lost it in the stack. See below. > Ryan > > On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: >> Eric, >> >> I just hit a problem with using quiver with Basemap when when >> angles='xy'. Because Basemap's x,y units are in meters, you end up >> with angles that are quantized due to floating point truncation >> (3. + 0.001*u = 3.). Changing to angles='uv' fixes the >> problem, but it probably should be automatically scaled, as noted in >> the comments: >> >>elif self.angles == 'xy' or self.scale_units == 'xy': >># We could refine this by calculating eps based on >># the magnitude of U, V relative to that of X, Y, >># to ensure we are always making small shifts in X, Y. >> >> I managed to fix the problem locally by setting: >> >>angles, lengths = self._angles_lengths(U, V, eps=0.0001 * >> self.XY.max()) >> I don't think this will work in all cases. For example, there could be a single arrow at (0,0). Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? Eric >> but I'm not sure if you would want a different fix. If you're happy >> with this fix, I'll go ahead an check in. > > Ryan > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: >> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: >>> I just hit a problem with using quiver with Basemap when when >>> angles='xy'. Because Basemap's x,y units are in meters, you end up >>> with angles that are quantized due to floating point truncation >>> (3. + 0.001*u = 3.). Changing to angles='uv' fixes the >>> problem, but it probably should be automatically scaled, as noted in >>> the comments: >>> >>> elif self.angles == 'xy' or self.scale_units == 'xy': >>> # We could refine this by calculating eps based on >>> # the magnitude of U, V relative to that of X, Y, >>> # to ensure we are always making small shifts in X, Y. >>> >>> I managed to fix the problem locally by setting: >>> >>> angles, lengths = self._angles_lengths(U, V, eps=0.0001 * >>> self.XY.max()) >>> > > I don't think this will work in all cases. For example, there could be a > single arrow at (0,0). Good point. > Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? Wouldn't this have problems if we zoom in sufficiently that the width is much less than magnitude of the values? Not exactly sure what data set would sensibly yield this, so I'm not sure if we should worry about it. If we do care, we could just put a minimum bound on eps: eps=max(1e-8, 0.0001 * self.XY.max()) Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
Ryan May wrote: > On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: >>> On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: I just hit a problem with using quiver with Basemap when when angles='xy'. Because Basemap's x,y units are in meters, you end up with angles that are quantized due to floating point truncation (3. + 0.001*u = 3.). Changing to angles='uv' fixes the problem, but it probably should be automatically scaled, as noted in the comments: elif self.angles == 'xy' or self.scale_units == 'xy': # We could refine this by calculating eps based on # the magnitude of U, V relative to that of X, Y, # to ensure we are always making small shifts in X, Y. I managed to fix the problem locally by setting: angles, lengths = self._angles_lengths(U, V, eps=0.0001 * self.XY.max()) >> I don't think this will work in all cases. For example, there could be a >> single arrow at (0,0). > > Good point. > >> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? > > Wouldn't this have problems if we zoom in sufficiently that the width > is much less than magnitude of the values? Not exactly sure what data > set would sensibly yield this, so I'm not sure if we should worry > about it. > > If we do care, we could just put a minimum bound on eps: > > eps=max(1e-8, 0.0001 * self.XY.max()) I don't like taking the max of a potentially large array every time; and one needs max absolute value in any case. I think the following is better: eps = np.abs(self.ax.dataLim.extents).max() * 0.001 Eric > > Ryan > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
On Fri, Apr 2, 2010 at 11:42 AM, Eric Firing wrote: > Ryan May wrote: >> >> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: > > I just hit a problem with using quiver with Basemap when when > angles='xy'. Because Basemap's x,y units are in meters, you end up > with angles that are quantized due to floating point truncation > (3. + 0.001*u = 3.). Changing to angles='uv' fixes the > problem, but it probably should be automatically scaled, as noted in > the comments: > > elif self.angles == 'xy' or self.scale_units == 'xy': > # We could refine this by calculating eps based on > # the magnitude of U, V relative to that of X, Y, > # to ensure we are always making small shifts in X, Y. > > I managed to fix the problem locally by setting: > > angles, lengths = self._angles_lengths(U, V, eps=0.0001 * > self.XY.max()) > >>> I don't think this will work in all cases. For example, there could be a >>> single arrow at (0,0). >> >> Good point. >> >>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? >> >> Wouldn't this have problems if we zoom in sufficiently that the width >> is much less than magnitude of the values? Not exactly sure what data >> set would sensibly yield this, so I'm not sure if we should worry >> about it. >> >> If we do care, we could just put a minimum bound on eps: >> >> eps=max(1e-8, 0.0001 * self.XY.max()) > > I don't like taking the max of a potentially large array every time; and one > needs max absolute value in any case. I think the following is better: > > eps = np.abs(self.ax.dataLim.extents).max() * 0.001 I hadn't thought about performance. I think that's more important than any worries about bounds being disproportionately smaller. I'll check this in. Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Problem with Quiver+Basemap
Ryan May wrote: > On Fri, Apr 2, 2010 at 11:42 AM, Eric Firing wrote: >> Ryan May wrote: >>> On Fri, Apr 2, 2010 at 1:23 AM, Eric Firing wrote: > On Fri, Mar 26, 2010 at 12:13 PM, Ryan May wrote: >> I just hit a problem with using quiver with Basemap when when >> angles='xy'. Because Basemap's x,y units are in meters, you end up >> with angles that are quantized due to floating point truncation >> (3. + 0.001*u = 3.). Changing to angles='uv' fixes the >> problem, but it probably should be automatically scaled, as noted in >> the comments: >> >> elif self.angles == 'xy' or self.scale_units == 'xy': >> # We could refine this by calculating eps based on >> # the magnitude of U, V relative to that of X, Y, >> # to ensure we are always making small shifts in X, Y. >> >> I managed to fix the problem locally by setting: >> >> angles, lengths = self._angles_lengths(U, V, eps=0.0001 * >> self.XY.max()) >> I don't think this will work in all cases. For example, there could be a single arrow at (0,0). >>> Good point. >>> Instead of self.XY.max(), how about abs(self.ax.dataLim.width)? >>> Wouldn't this have problems if we zoom in sufficiently that the width >>> is much less than magnitude of the values? Not exactly sure what data >>> set would sensibly yield this, so I'm not sure if we should worry >>> about it. >>> >>> If we do care, we could just put a minimum bound on eps: >>> >>> eps=max(1e-8, 0.0001 * self.XY.max()) >> I don't like taking the max of a potentially large array every time; and one >> needs max absolute value in any case. I think the following is better: >> >> eps = np.abs(self.ax.dataLim.extents).max() * 0.001 > > I hadn't thought about performance. I think that's more important > than any worries about bounds being disproportionately smaller. I'll > check this in. Sorry for the piecemeal approach in thinking about this--but now I realize that to do this right, as indicated by the comment in the original code, we need to take the magnitude of U and V into account. The maximum magnitude could be calculated once in set_UVC and then saved so that it does not have to be recalculated every time it is used in make_verts. Maybe I am still missing some simpler way to handle this well. Eric > > Ryan > -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] toolbar
Any feedback on the submitted patch ? I've now added the possibility to switch autoscale off. On Sun, Mar 28, 2010 at 9:26 PM, Peter Butterworth wrote: > please find attached the 2 patched files and the diff vs trunk. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Use of Color Cycles for Hist
Jeff Klukas wrote: > Alright, I have attached a top-level diff that contains the changes to > axes.py that allow sending multiple colors to the 'color' argument in > Axes.hist. > > Below is a short examples that passes lists to 'colors' and 'labels'. Jeff, Thanks. I find that both hist and the patch need some additional reworking, which I will try to get done this weekend. Eric > > Cheers, > Jeff > > || Jeff Klukas, Research Assistant, Physics > || University of Wisconsin -- Madison > || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype > || http://www.hep.wisc.edu/~jklukas/ > > -- > import pylab as P > > mu, sigma = 200, 25 > x0 = mu + sigma*P.randn(1) > x1 = mu + sigma*P.randn(7000) > x2 = mu + sigma*P.randn(3000) > > P.figure() > > colors = ['crimson', 'burlywood', 'chartreuse'] > labels = ['Crimson', 'Burlywood', 'Chartreuse'] > n, bins, patches = P.hist([x0,x1,x2], 10, histtype='bar', > color=colors, label=labels) > > P.legend() > P.show() > - > > > > On Wed, Mar 31, 2010 at 1:27 PM, Eric Firing wrote: >> Jeff Klukas wrote: >>> When plotting multiple data with one Axes.hist call, the method's >>> interface allows you to specify a list of labels to the 'label' kwarg >>> to distinguish between the datasets. To get different colors, >>> however, you cannot give a list of colors to 'color'; instead, you >>> have to leave out the 'color' kwarg and change the color cycle. >>> >>> Is there any reason why the color kwarg can't work like label? I >>> spent an hour or two trying to debug a script before I realized that >>> 'color' wasn't being interpreted as I expected. I realize that there >>> is some ambiguity since a color argument can be an rgb or rgba >>> sequence. My proposal would be that 'color' would be interpreted as a >>> list of distinct colors only when multiple datasets are given as input >>> and len(color) equals the number of datasets. >>> >>> I find it hard to imagine a case where you would want to set all >>> datasets to be the same color, so I don't think the ambiguity would be >>> a major issue. I would be happy to write and submit an implementation >>> if others think this is a reasonable idea. >> Sounds good to me. I agree that it makes no sense to have to set the color >> cycle for hist (although using the color cycle as a default is reasonable), >> and I think it is just an artifact of the way hist has evolved. >> >> Eric >> >>> Cheers, >>> Jeff >>> >>> || Jeff Klukas, Research Assistant, Physics >>> || University of Wisconsin -- Madison >>> || jeff.klu...@gmail | jeffyklu...@aim | jeffklu...@skype >>> || http://www.hep.wisc.edu/~jklukas/ >>> -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] [Matplotlib-users] toolbar
On Fri, Apr 2, 2010 at 1:25 PM, Peter Butterworth wrote: > Any feedback on the submitted patch ? > > > I've now added the possibility to switch autoscale off. > > On Sun, Mar 28, 2010 at 9:26 PM, Peter Butterworth > wrote: > > please find attached the 2 patched files and the diff vs trunk. > Hi Peter, Your previous addition looks fine here. Keep pinging probably someone should commit your additions. I would like to see your further editions. Maybe you can use google-code or somewhere to host the code and continue making additions there. Once some important steps are completed changes can integrated into matplotlib back. -- Gökhan -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
