Re: [matplotlib-devel] auto range limits for spines: please kick the tires
Andrew Straw writes: > if you update from svn and play around with the demo, especially by > panning and zooming in the figures, you'll get an idea of what I've > done. Neat! One small thing: in Figure 2 (the four subplots with differently placed spines) if I zoom and pan subplot 4, I can make its spines appear in subplots 2 and 3. Curiously enough, they don't show up in subplot 1. -- Jouni K. Seppänen http://www.iki.fi/jks -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
[matplotlib-devel] notes on Windows 7 cygwin 1.7 installation
Hi all. With some effort, I've managed to get matplotlib-0.99.1.1 with cygwin 1.7 (beta) on Windows 7. Since Google didn't turn up any instructions specifically addressing the problems I had, maybe these notes will be helpful to others. - System details - Windows 7, 32-bit, AMD Athlon II Dual-Core M300 2.00 GHz - Full cygwin 1.7 (beta) installation, updated same day prior to matplotlib installation - Downloaded matplotlib-0.99.1.2.tar.gz on 12/20 from a link on the matplotlib homepage - $ tar -xzvf matplotlib-0.99.1.2.tar.gz --> matplotlib-0.99.1.1/ (??) - $ python setup.py build - get IndexError in line 908 of setupext.py - failing to parse tclConfig.sh, tkConfig.sh correctly - easiest solution seems to simply abort this function, causing the script to fall back on defaults: - setupext.py, line 904 just inside try block, insert: return None - note one more hack later when linking tcl/tk libs - Now 'python setup.py build' eventually fails with: - "Unable to free colormap, palette is still selected." and - "gcc: vfork: Resource temporarily unavailable" - not sure what is the root cause - "rebaseall" doesn't seem to fix it - though it seems to have caused failure via some memory error instead - (I don't remember exactly) - Painful solution to above: - copy-and-paste gcc command printed by script - command usually executes fine fine, but see exceptions below - repeat 'python setup.py build', which will fail the same way, but prints a new command - rinse and repeat - unfortunately, there are a couple dozen compiler commands - the script takes several seconds each time - Two cases require more than the simple copy/paste - several commands with '-c src/xxx.cpp' fail, missing the .cpp file - solution: - $ cp -r src/_xxx.cpp src/xxx.cpp - mimics function 'temp_copy()' in setupext.cpp - files xxx.cpp are later deleted by script, using temp_copy() - applies to: path.cpp, backend_agg.cpp, image.cpp, backend_gdk.cpp - two commands link with -ltk8.4 -ltcl8.4 - solution: - '-ltk8.4' --> '-ltk84' - '-ltcl8.4' --> '-ltcl84' - Caveat: I initially thought there was a problem with freetype2, so I tried adding -I/usr/include/freetype2/freetype, -I/usr/include/freetype2/freetype/config after -I/usr/include/freetype2 in compiler commands. I suppose it's possible that this actually fixed something, but I don't think it did. I wouldn't be surprised if there was a simpler way to get things going, but the steps above seemed to work. After 'python setup.py install', matplotlib seems to work as expected. I hope this is helpful to someone. Sorry I don't have time to put together a proper patch, but maybe someone else will have done so by the next time I need to install it. I use matplotlib daily and I'm very grateful to the people who put it together. Regards, GW -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] notes on Windows 7 cygwin 1.7 installation
On Sun, Dec 20, 2009 at 4:19 PM, Glen Nixon wrote: > Hi all. With some effort, I've managed to get matplotlib-0.99.1.1 with > cygwin 1.7 (beta) on Windows 7. Since Google didn't turn up any > instructions specifically addressing the problems I had, maybe these > notes will be helpful to others. FYI, we have a Makefile in release/win32/ in the svn repo which we use for building mpl under cygwin. Haven't tried it under Windows 7, but ideally we like to codify all the Windows/Cygwin specific build info in a Makefile to smooth the path for the next person. So you may want to try this and/or submit patches against it if you have time. Thanks, JDH -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] boxplot notch
Andrew Straw wrote: > Also, I think that formula is only for normally distributed data. Which, > especially if you're using boxplots, medians, and quartiles, may not be > a valid assumption. > > Maybe we should at least raise a warning when someone uses notch=1. The > current implementation seems dubious, at best, IMO. > I read the following reference: McGill, R., Tukey, J.W., and Larsen, W.A. (1978) "Variations of Boxplots", The American Statistician, 32:12-16. McGill et al. have an entire section devoted to "Choice of Notch Size", starting with: "In notched box plots, one is, of course, faced with the question of how best to determine the widths of the notches. Many methods, both classical and non-parametric, might be considered. None will likely be best in all cases." They then describe a suggestion based on the Gaussian-based asymptotic appoximation (Kendall and Stuart, 1967) given by s = 1.25*R / (1.35 * sqrt(N)) And the notch around each median should be M +/- Cs where C is a constant and R is the interquartile range. It seems any value between 1.386 and 1.96 could be justified depending on the standard deviations, and they choose C=1.7 empirically as preferable and ultimately give the full equation for notches to be M +/- 1.7* (1.25*R / (1.35 * sqrt(N))) But they end the section with: "Clearly, a variety of other choices, such as a single less conservative value (<1.7) or one dependent upon the data (chosen to compromise over the range of the ratios of the spreads involved), are possible and may be preferable in certain cases." The thing not done in this article is to display outliers -- they refer the reader to "schematic plots" in Tukey's 1977 book titled Exploratory Data Analysis (Addison-Wesley). In the version of boxplots described in this paper, the whiskers go to the data extremes. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] boxplot notch
Andrew Straw wrote: > Also, I think that formula is only for normally distributed data. Which, > especially if you're using boxplots, medians, and quartiles, may not be > a valid assumption. > > Maybe we should at least raise a warning when someone uses notch=1. The > current implementation seems dubious, at best, IMO. > (I sent the previous version of this email a bit too early -- this is slightly edited for clarity.) I read the following reference: McGill, R., Tukey, J.W., and Larsen, W.A. (1978) "Variations of Boxplots", The American Statistician, 32:12-16. McGill et al. have an entire section devoted to "Choice of Notch Size", starting with: "In notched box plots, one is, of course, faced with the question of how best to determine the widths of the notches. Many methods, both classical and non-parametric, might be considered. None will likely be best in all cases." They then describe a suggestion based on the Gaussian-based asymptotic approximation (Kendall and Stuart, 1967). Here the standard deviation of the median is given by s = 1.25*R / (1.35 * sqrt(N)) where R is the interquartile range and N is the number of observations. Using this value for s, the notch around each median should be M +/- Cs where C is a constant. To summarize this section of their paper, values of C between 1.386 and 1.96 could be justified depending on the standard deviations, and they choose C=1.7 empirically as preferable and ultimately give the full equation for notches to be M +/- 1.7* (1.25*R / (1.35 * sqrt(N))) But they end the section with: "Clearly, a variety of other choices, such as a single less conservative value (<1.7) or one dependent upon the data (chosen to compromise over the range of the ratios of the spreads involved), are possible and may be preferable in certain cases." The thing not done in this article is to display outliers -- they refer the reader to "schematic plots" in Tukey's 1977 book titled Exploratory Data Analysis (Addison-Wesley). In the version of boxplots described in this paper, the whiskers go to the data extremes. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] auto range limits for spines: please kick the tires
This looks nice Andrew, I haven't tried it, but I wonder whether it's possible to add a keyword arg to suppress the 0's at the origin which are cut through by the axes in the zeroed case (and/or possibly shift the 0 on the horizontal axis left). The same thing is happening in the (1,2) case on the vertical axis. Gary Andrew Straw wrote: > I have implemented something I'm calling "smart bounds" for the axis > spines, and have just committed it to svn r8048. I modified > examples/pylab_examples/spine_placement_demo.py to illustrate the basic > idea -- the spines and ticks should be able to automatically limit > themselves to the data range. There are some subtleties beyond that in > terms of the algorithmic details, but I think if you update from svn and > play around with the demo, especially by panning and zooming in the > figures, you'll get an idea of what I've done. I've attached two images > from such a session. > > The key API addition is this: > > spine.set_smart_bounds(True) > > Doing so turns on the smart bounds mode in the spine and the axis. > > Anyhow, I'd be happy to receive any feedback on this new feature. > > -Andrew -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] auto range limits for spines: please kick the tires
Gary Ruben wrote: > This looks nice Andrew, > I haven't tried it, but I wonder whether it's possible to add a > keyword arg to suppress the 0's at the origin which are cut through by > the axes in the zeroed case (and/or possibly shift the 0 on the > horizontal axis left). The same thing is happening in the (1,2) case > on the vertical axis. Hi Gary, John also suggested something like this. I don't think it's impossible, but it's outside the scope of the work I have done and beyond my immediate familiarity with the code base. I think it would involve looking at the tick label bounding boxes, finding overlaps, and then deciding which label was less important and removing it. I don't think it would be impossible, and maybe not even hard, but I haven't investigated at all. Thanks for keeping it on the queue. -Andrew -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] auto range limits for spines: please kick the tires
On Mon, Dec 21, 2009 at 3:46 PM, Andrew Straw wrote: > John also suggested something like this. I don't think it's impossible, > but it's outside the scope of the work I have done and beyond my > immediate familiarity with the code base. I think it would involve > looking at the tick label bounding boxes, finding overlaps, and then > deciding which label was less important and removing it. I don't think > it would be impossible, and maybe not even hard, but I haven't > investigated at all. Thanks for keeping it on the queue. One easy-ish approach would be to do this at the Axes layer, which knows all the Axis contained within. We could have some property like hide_tick_overlaps and have a zorder on the axis, so if an axis is "above" another, and any of the "lower" axis ticks overlap any of the above ticks, then the lower ticks would be rendered invisible giving the user some control of which get shown. This would probably need to be a draw time operation, with something like a before_draw_hook handling the visibility and an after_draw_hook restoring the default visibility. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
