matplotlib-users Mailing List for matplotlib

    	I noticed that the boxplot function incorrectly calculates the 
location of the median line in each box.  As a simple example, plotting 
the dataset [1, 2, 3, 4] incorrectly plots the median line at 3.

    	It also seems that the quartile calculations for the box are a 
little peculiar.  I have seen some discussion in old mailing list 
postings about mlab.prctile and its ways of calculating percentiles, 
which are different than those of some other software.

    	I'm aware that there is legitimate disagreement about the "best" 
way to calculate the quartiles.  However, it seems to me that mlab's way 
is still not any of these possibly-correct ways, because it uses int() 
or nparray.astype(int) to coerce the percentile result to an integer 
index.  This TRUNCATES the floating-point result.  No accepted quantile-
calculating method that I'm aware of does this; they all ROUND instead 
of truncating (if they want to coerce to an integer index at all, in 
order to produce a quantile value that is an element of the data set), 
or in some cases they round uniformly up for the lower quartile and 
down for the upper.  You can see a summary of different methods at 
http://www.amstat.org/publications/jse/v14n3/langford.html ; the method 
used by mlab does not appear to agree with any of these.

    	I would suggest that mlab.prctile be fixed to conform to some one 
or other of these methods, rather than adding to the proliferation of 
approaches to quantile-calculation.  Is there any motivation for always 
truncating to integer (other that "it's quicker to type" :-)?

    	Also, regardless of these quartile issues, there is, as far as I'm 
aware, no one who denies that the median of a (sorted) data set with an 
even number of values is the mean of the middle two values.  Since numpy 
is already a dependency for matplotlib, boxplot shouldn't use 
mlab.prctile at all to decide where to plot the median line -- just use 
numpy.median.

Thanks,
-- 
--OKB (not okblacke)
Brendan Barnwell
"Do not follow where the path may lead.  Go, instead, where there is
no path, and leave a trail."
	--author unknown

On Fri, Dec 31, 2010 at 11:42 AM, Benjamin Root <ben...@ou...> wrote:
>
> On Sun, Dec 19, 2010 at 3:34 AM, Sylvain Munaut <24...@gm...> wrote:
>>
>> Hi,
>>
>> I was wondering if you ever found a solution to this problem ?
>>
>> I have the exact same issue with GTK (Agg or cairo) and WX backends
>> ... I'm also under gentoo using ipython-0.10.1 and matplotlib-1.0.0
>> I don't have the warnings you have but same behavior, I have to call
>> show (if I don't a blank 'frozen' window is all that appears) but then
>> the ipython doesn't have control anymore.
>>
>> Cheers,
>>
>>   Sylvain
>>
>
> It is very possible that this problem was fixed shortly after the 1.0.0 release.  Another possibility is that ipython might be causing an issue where it is loading some older matplotlib codes before the rest of matplotlib 1.0.0 is loaded (I have seen this happen once).
>
> You can test for this theory by seeing if you have the same problem when using the regular python shell.  If not, then it is likely to be a problem with ipython.  If you do have the same problem in regular python, then the problem is with matplotlib and you will need to build the latest from svn.
>
> Ben Root
>

If the issue was GTK only - it is a known problem with IPython 0.10.1
for which the fix is waiting to be merged here:

https://github.com/ipython/ipython/issues/issue/237

but if you think the WX backend is also affected - it might just be
that you're not starting ipython with the -pylab flag to get the
threading to work without blocking. Can you try starting "ipython
-pylab -gthread" and "ipython -pylab -wthread"  to see if that fixes
the issue? Make sure that you change the backend accordingly - and use
plt.get_backend() to ensure the appropriate one is being used.

-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7