matplotlib-devel Mailing List for matplotlib

On Mon, Dec 21, 2009 at 3:46 PM, Andrew Straw <str...@as...> 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.

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 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

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.

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.

On Sun, Dec 20, 2009 at 4:19 PM, Glen Nixon <gle...@gm...> 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

Andrew Straw <str...@as...> 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

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

John Hunter wrote:
> On Fri, Aug 7, 2009 at 11:54 AM, Andrew Straw<str...@as...> wrote:
>
> 
>>> But would this also make the spine have the larger limits? Basically,
>>> I want know if the spines can be used to create Tufte-style
>>> range-frames. Am I correct in thinking that these spines provide that?
>>> 
>> Although I don't have a precise definition of "Tufte-style range
>> frame"to go by, I think my intention was to do exactly what you're after.
>> 
>
> One thing you want with range frames is to have the length of the
> spine equal the span of your dataset. Can we currently or with not
> too much effort define the line segment of the spine to be in data
> coords? 
This is implemented in r8044.
> Then we could make the axes as wide as we want with the ylim
> to maintain the clipping region, but the spine would cover just the
> span of the data (or whatever the user specified) rather than always
> being ymin...ymax if it is defined as 0..1 in axes coords.
> 
Currently, if you want to limit the spine range, you'll have to call
spine.set_bounds(low,high) manually. I think one would almost always
want the spine endpoints at tick locations, so perhaps a better default
behavior than we now have is that in any case in which the spines are
not forming an old-style axes frame, they are automatically limited to
the outermost ticks. I haven't implemented that, but I don't think it
would be too hard to build on top of what I just committed.
-Andrew