matplotlib-devel Mailing List for matplotlib (Page 2)

On Thu, Dec 24, 2009 at 03:53:29PM -1000, Eric Firing wrote:
> It looks like someone already has, as part of additional changes. SVN 
> is now at 8052, and I don't see the problem in either the maintenance 
> branch or the trunk.
Indeed, my mistake. I thought that I had svn uped, but seems like not.
Thanks, and merry Christmas!
Gaël

Gael Varoquaux wrote:
> Line 157 of image.py, there is a typo:
> 
> Index: matplotlib/image.py
> ===================================================================
> --- matplotlib/image.py	(revision 8036)
> +++ matplotlib/image.py	(working copy)
> @@ -144,7 +144,7 @@
> sy = dyintv/viewlim.height
> numrows, numcols = A.shape[:2]
> if sx > 2:
> - x0 = (viewim.x0-xmin)/dxintv * numcols
> + x0 = (viewlim.x0-xmin)/dxintv * numcols
> ix0 = max(0, int(x0 - self._filterrad))
> x1 = (viewlim.x1-xmin)/dxintv * numcols
> ix1 = min(numcols, int(x1 + self._filterrad))
> 
> Could someone with check in rights fix this in SVN, please.
Gael,
It looks like someone already has, as part of additional changes. SVN 
is now at 8052, and I don't see the problem in either the maintenance 
branch or the trunk.
Eric
> 
> Cheers,
> 
> Gaël
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Line 157 of image.py, there is a typo:
Index: matplotlib/image.py
===================================================================
--- matplotlib/image.py	(revision 8036)
+++ matplotlib/image.py	(working copy)
@@ -144,7 +144,7 @@
 sy = dyintv/viewlim.height
 numrows, numcols = A.shape[:2]
 if sx > 2:
- x0 = (viewim.x0-xmin)/dxintv * numcols
+ x0 = (viewlim.x0-xmin)/dxintv * numcols
 ix0 = max(0, int(x0 - self._filterrad))
 x1 = (viewlim.x1-xmin)/dxintv * numcols
 ix1 = min(numcols, int(x1 + self._filterrad))
Could someone with check in rights fix this in SVN, please.
Cheers,
Gaël

Andrew Straw wrote:
> 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.
>
>
> 
I did something like this for the Sage project, but I did it on the tick 
formatter level. I just made a tick formatter that omitted specified 
positions. I've attached the "Selective Formatter" class. If anyone 
has comments, I'd appreciate them! Basically, I just replaced the 
formatter with the selective formatter, which passed things on to the 
previous formatter if the tick label was allowed.
It would be great if spines supported this sort of thing natively, but 
the flexibility of tick formatters seems like a nice place to handle it 
as well.
Thanks,
Jason

Stéfan van der Walt wrote:
> Hi all,
> 
> According to the `spy` docstring, it can display sparse matrices from
> scipy. The following code snippet seems to break, however:
Fixed in the trunk.
Eric
> 
> In [20]: import scipy.sparse as sp
> In [21]: d = sp.lil_eye((15, 15))
> In [22]: plt.spy(d)
> 
> Am I using the `spy` function correctly? I've also tried forcing
> marker mode by setting marker='s' and markersize=1, but I still get
> the same error message:
> 
> --> 160 gca()._sci(im)
> 161
> 162
> 
> /Users/stefan/lib/python2.6/site-packages/matplotlib/axes.pyc in _sci(self, im)
> 1336 elif im not in self.images and im not in self.collections:
> 1337 raise ValueError(
> -> 1338 "Argument must be an image, collection, or
> ContourSet in this Axes")
> 1339 self._current_image = im
> 1340
> 
> ValueError: Argument must be an image, collection, or ContourSet in this Axes
> 
> 
> 
> Kind regards and a happy festive season!
> Stéfan
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Stéfan van der Walt wrote:
> Hi all,
> 
> According to the `spy` docstring, it can display sparse matrices from
> scipy. The following code snippet seems to break, however:
> 
> In [20]: import scipy.sparse as sp
> In [21]: d = sp.lil_eye((15, 15))
> In [22]: plt.spy(d)
> 
> Am I using the `spy` function correctly? I've also tried forcing
> marker mode by setting marker='s' and markersize=1, but I still get
> the same error message:
It's a bug. The problem is that spy can return in image or a line with 
markers, but the pyplot wrapper is assuming it is returning an image. It 
will need a custom wrapper instead of the standard wrapper for functions 
returning a mappable. I'll fix it.
Eric
> 
> --> 160 gca()._sci(im)
> 161
> 162
> 
> /Users/stefan/lib/python2.6/site-packages/matplotlib/axes.pyc in _sci(self, im)
> 1336 elif im not in self.images and im not in self.collections:
> 1337 raise ValueError(
> -> 1338 "Argument must be an image, collection, or
> ContourSet in this Axes")
> 1339 self._current_image = im
> 1340
> 
> ValueError: Argument must be an image, collection, or ContourSet in this Axes
> 
> 
> 
> Kind regards and a happy festive season!
> Stéfan
> 
> ------------------------------------------------------------------------------
> 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
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Hi all,
According to the `spy` docstring, it can display sparse matrices from
scipy. The following code snippet seems to break, however:
In [20]: import scipy.sparse as sp
In [21]: d = sp.lil_eye((15, 15))
In [22]: plt.spy(d)
Am I using the `spy` function correctly? I've also tried forcing
marker mode by setting marker='s' and markersize=1, but I still get
the same error message:
--> 160 gca()._sci(im)
 161
 162
/Users/stefan/lib/python2.6/site-packages/matplotlib/axes.pyc in _sci(self, im)
 1336 elif im not in self.images and im not in self.collections:
 1337 raise ValueError(
-> 1338 "Argument must be an image, collection, or
ContourSet in this Axes")
 1339 self._current_image = im
 1340
ValueError: Argument must be an image, collection, or ContourSet in this Axes
Kind regards and a happy festive season!
Stéfan

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

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

On Sat, Dec 19, 2009 at 2:03 PM, Eric Firing <ef...@ha...> wrote:
> Exactly. I *strongly* oppose any move in this direction. It would be
> enabling bad workflow strategy on the part of users, providing no
> benefit that cannot be achieved better with a good workflow strategy,
> and adding complexity. We have enough of that already. We need to
> think about how to clean up mpl and make it easier to maintain and
> improve, not clutter it with ever more complexity.
+1 That pretty much sums up how I feel.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Jouni K. Seppänen wrote:
> Christopher Barker <Chr...@no...> writes:
> 
>> Joey Wilson wrote:
>>> I would like to be able to save the figures from 
>>> matplotlib in an editable form, without flattening down to an image 
>>> file. 
>> I think to do this right, you'd need to completely re-design MPL to be 
>> based on a more declarative structure: [...] but it seems that MPL is 
>> built to be used from a scripting interface instead: a series of 
>> commands that builds the figure.
> 
> I don't think that is the real problem. How matplotlib works is that the
> plotting commands build up a data structure consisting of various
> objects pointing to each other, and when you call show or savefig, the
> data structure is traversed and the appropriate backend functions are
> called. In principle it should not be very difficult to serialize this
> data structure, but since extension objects are involved, some work
> might be needed to get it right.
> 
> What I think is the really difficult part is keeping the serialized
> format somehow usable across different versions of matplotlib. When
> anything changes in the various classes, the developers would need to
> decide how the change is reflected in the on-disk format, how files
> corresponding to the old class should be read in using the new class,
> etc. Perhaps something like Google's protocol buffers could be used to
> make this easier, but it would still be an burden on all subsequent
> development.
> 
Exactly. I *strongly* oppose any move in this direction. It would be 
enabling bad workflow strategy on the part of users, providing no 
benefit that cannot be achieved better with a good workflow strategy, 
and adding complexity. We have enough of that already. We need to 
think about how to clean up mpl and make it easier to maintain and 
improve, not clutter it with ever more complexity.
Eric

Christopher Barker <Chr...@no...> writes:
> Joey Wilson wrote:
>> I would like to be able to save the figures from 
>> matplotlib in an editable form, without flattening down to an image 
>> file. 
>
> I think to do this right, you'd need to completely re-design MPL to be 
> based on a more declarative structure: [...] but it seems that MPL is 
> built to be used from a scripting interface instead: a series of 
> commands that builds the figure.
I don't think that is the real problem. How matplotlib works is that the
plotting commands build up a data structure consisting of various
objects pointing to each other, and when you call show or savefig, the
data structure is traversed and the appropriate backend functions are
called. In principle it should not be very difficult to serialize this
data structure, but since extension objects are involved, some work
might be needed to get it right.
What I think is the really difficult part is keeping the serialized
format somehow usable across different versions of matplotlib. When
anything changes in the various classes, the developers would need to
decide how the change is reflected in the on-disk format, how files
corresponding to the old class should be read in using the new class,
etc. Perhaps something like Google's protocol buffers could be used to
make this easier, but it would still be an burden on all subsequent
development.
-- 
Jouni K. Seppänen
http://www.iki.fi/jks

Pierre GM wrote:
> On Dec 18, 2009, at 10:34 PM, Andrew Straw wrote:
> 
>> Fernando Perez wrote:
>> 
>>> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
>>>
>>> 
>>>> (This still leaves open the question of what the notches actually _are_...)
>>>>
>>>> 
>>> No idea. I'd still leave the code instead written as
>>>
>>> notch_max = med + (iq/2) * (pi/np.sqrt(row))
>>>
>>> 
>> Further searching turned this up: 
>> http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf
>>
>> It says that
>>
>> median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard error.
>>
>>
>> I can't find any further support for this notion, though.
>> 
>
>
> Looks like the std error of the median is (1.253*std error of the mean=1.253*std dev/sqrt(nb of obs)).
> The 1.57 looks like it's 1.253^2, but I wouldn't bet anything on it...
>
> 
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.
-Andrew

Fernando Perez wrote:
> On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
> 
>> (This still leaves open the question of what the notches actually _are_...)
>> 
>
> No idea. I'd still leave the code instead written as
>
> notch_max = med + (iq/2) * (pi/np.sqrt(row))
> 
Further searching turned this up: 
http://seismo.berkeley.edu/~kirchner/eps_120/Toolkits/Toolkit_01.pdf
It says that
median +/- 1.57 * (iq / sqrt(n)) is the median, plus or minus its standard error.
I can't find any further support for this notion, though.
I've decided not to use notches on my own plots, so I'm leaving this 
issue for now...
-Andrew

On Fri, Dec 18, 2009 at 2:28 PM, Andrew Straw <str...@as...> wrote:
> (This still leaves open the question of what the notches actually _are_...)
No idea. I'd still leave the code instead written as
notch_max = med + (iq/2) * (pi/np.sqrt(row))
as that's what it appears to be doing (unless 1.57 is *not* pi/2 in
this case). That might help someone spot what formula the factors
come from. Even better would be to get from the original author an
explanation of where those factors come from :) I did look around
some more, couldn't find an answer...
Cheers,
f

Andrew Straw wrote:
> The following (uncommitted) test currently fails. The reason is that 
> mlab.prctile(x,50) doesn't handle even length sequences according to the 
> numpy and wikipedia convention for the definition of median. Do we agree 
> that it should pass?
> 
I'll take the silence as +0. Therefore, I committed the test in r8038 
and the bugfix in r8039.
-Andrew

Fernando Perez wrote:
> Note that the code below does:
>
> if notch_max > q3:
> notch_max = q3
> if notch_min < q1:
> notch_min = q1
>
> though matlab explicitly states in:
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/stats/boxplot.html
>
> that
>
> """
> Interval endpoints are the extremes of the notches or the centers of
> the triangular markers. When the sample size is small, notches may
> extend beyond the end of the box.
> """
>
> So it seems to me that the more principled thing to do would be to
> leave those notch markers outside the box if they land there, because
> that's a warning of the robustness of the estimation. Clipping them to
> q1/q3 is effectively hiding a problem...
>
> 
I agree. I disabled the boxplot notch shortening in r8040.
(This still leaves open the question of what the notches actually _are_...)
-Andrew