matplotlib-devel Mailing List for matplotlib

> PH...@Ge... wrote:
> > Hey folks,
> >
> > I recently modified the Axes method boxplot so that the confidence
> intervals around the mean are computed not with a static formula, but by
> bootstrapping the median as many times as the user specifies. Also, I
> commented out the lines that prevent the boxplots from folding around the
> hinges (but that's obviously minor and in the current SVN if I'm not
> mistaken).
> >
> > Is this something that would be worth including in matplotlib? I've
> never contributed to a project like this before and my code is probably
> pretty sloppy by MPL standards. I'm not really sure what's appropriate to
> contribute and what's not.
> >
> -----Original Message-----
> From: Andrew Straw [mailto:str...@as...]
> Sent: Wednesday, February 10, 2010 2:20 PM
> To: Paul Hobson
> Cc: mat...@li...
> Subject: Re: [matplotlib-devel] Boxplots with Bootstrapped Intervals
> ...
> I think the best thing to do is to post the patch so that it can be
> reviewed. Sending the output of "svn diff" as an attachment to this
> email list would be easy from our end. (A github based submission --
> fork the repo and push your commits -- would also work well for me, but
> I'm not sure about the other MPL devs.)
Andrew,
Thanks for the reply. At the risk of embarrassment, I'm going to admit that I'm not at all familiar with SVN other than I know that it's version control software. Nonetheless I gave it a shot.
I guess I should add that I didn't account for the fact that the user might want to have the CIs output with the other boxplot properties. Shouldn't be too hard to add in though. Also, I'm using the percentile method -- meaning that after I get my "normal" distribution of medians, I simply use mlab's percentile function to get the 2.5th and 97.5th percentile of that distribution. The other method (bias-corrected and accelerated) was too complex for me to code up quickly without using Rpy2, and that just seemed silly.
Thanks again,
-paul

PH...@Ge... wrote:
> Hey folks,
>
> I recently modified the Axes method boxplot so that the confidence intervals around the mean are computed not with a static formula, but by bootstrapping the median as many times as the user specifies. Also, I commented out the lines that prevent the boxplots from folding around the hinges (but that's obviously minor and in the current SVN if I'm not mistaken). 
>
> Is this something that would be worth including in matplotlib? I've never contributed to a project like this before and my code is probably pretty sloppy by MPL standards. I'm not really sure what's appropriate to contribute and what's not.
> 
Hi Paul,
This sounds interesting.
I think the best thing to do is to post the patch so that it can be
reviewed. Sending the output of "svn diff" as an attachment to this
email list would be easy from our end. (A github based submission --
fork the repo and push your commits -- would also work well for me, but
I'm not sure about the other MPL devs.)
-Andrew

Hey folks,
I recently modified the Axes method boxplot so that the confidence intervals around the mean are computed not with a static formula, but by bootstrapping the median as many times as the user specifies. Also, I commented out the lines that prevent the boxplots from folding around the hinges (but that's obviously minor and in the current SVN if I'm not mistaken). 
Is this something that would be worth including in matplotlib? I've never contributed to a project like this before and my code is probably pretty sloppy by MPL standards. I'm not really sure what's appropriate to contribute and what's not.
Regards,
-paul h.

Hi folks,
the message below is an important discussion on which we'd like
feedback/ideas both from Enthought.traits experts and matplotlib ones.
 It would be great if we could keep things in one list, so it seems
most sensible to hold the discussion in the ipython-dev list, but this
is a heads-up in case one of you is interested but may not monitor
ipython-dev.
Thanks!
f
---------- Forwarded message ----------
From: Brian Granger <ell...@gm...>
Date: Tue, Feb 9, 2010 at 11:59 PM
Subject: [IPython-dev] GUI support: conflicts between IPython 0.11 and
Matplotlib/ETS
To: IPython Development list <ipy...@sc...>
Hello all,
As many of you know, we have been working hard on IPython 0.11. One
of the big new features of 0.11 is a refactored integration with GUI
event loops.
We are very excited about this as it is much more stable and add new
capabilities, like being able to enable pylab *after* starting IPython
(it is a magic: %pylab).
BUT, as Fernando and I have started to use the IPython 0.11 alpha for
our daily work, we have found some subtle issue with IPython 0.11 and
the current
versions of matplotlib and Enthought tool suite (traits, chaco,
mayavi). All of these packages rely on IPython's previous way of
handling GUI
integration. Because of this, current versions of matplotlib and ets
don't work fully with IPython 0.11. In some cases, they work OK, but
there are a whole class
of bugs that keep popping up. We don't want to release IPython 0.11
until these issues are resolved.
All of these bugs are related to a few aspects of creating the main
GUI app objects and starting event loops. We think we understand the
issues, but we will
need to work with the devs of matplotlib and ets to decide on how we
all want to handle these things. Here is where we are at...
Current situation
=============
Both matplotlib and ets have code that tries to:
* See what GUI toolkit is being used
* Get the global App object if it already exists, if not create it.
* See if the main loop is running, if not possibly start it.
All of this logic makes many assumptions about how IPython affects the
answers to these
questions. Because IPython's GUI support has changed in significant
ways, current matplotlib
and ets make incorrect decisions about these issues (such as trying to
start the event loop
a second time, creating a second main App ojbect, etc.) under IPython
0.11. This leads to crashes...
Description of GUI support in 0.11
==========================
IPython allows GUI event loops to be run in an interactive IPython session.
This is done using Python's PyOS_InputHook hook which Python calls
when the :func:`raw_input` function is called and is waiting for user input.
IPython has versions of this hook for wx, pyqt4 and pygtk. When the inputhook
is called, it iterates the GUI event loop until a user starts to type
again. When
the user stops typing, the event loop iterates again. This is how tk works.
When a GUI program is used interactively within IPython, the event loop of
the GUI should *not* be started. This is because, the PyOS_Inputhook itself
is responsible for iterating the GUI event loop.
IPython has facilities for installing the needed input hook for each GUI
toolkit and for creating the needed main GUI application object. Usually,
these main application objects should be created only once and for some
GUI toolkits, special options have to be passed to the application object
to enable it to function properly in IPython.
What we need to decide
===================
We need to answer the following questions:
* Who is responsible for creating the main GUI application object, IPython
 or third parties (matplotlib, enthought.traits, etc.)?
* What is the proper way for third party code to detect if a GUI application
 object has already been created? If one has been created, how should
 the existing instance be retrieved?
* In a GUI application object has been created, how should third party code
 detect if the GUI event loop is running. It is not sufficient to call the
 relevant function methods in the GUI toolkits (like ``IsMainLoopRunning``)
 because those don't know if the GUI event loop is running through the
 input hook.
* We might need a way for third party code to determine if it is running
 in IPython or not. Currently, the only way of running GUI code in IPython
 is by using the input hook, but eventually, GUI based versions of IPython
 will allow the GUI event loop in the more traditional manner. We will need
 a way for third party code to distinguish between these two cases.
Thanks for participating in this discussion!
Cheers,
Brian
_______________________________________________
IPython-dev mailing list
IPy...@sc...
http://mail.scipy.org/mailman/listinfo/ipython-dev

Hi - mea culpa - as pointed out by a colleague (and documented in the help
document for "hanning" in Matlab), this function produces the same window,
but without the first and last zero-weighted samples.
Cheers -- Ariel
On Tue, Feb 9, 2010 at 4:58 PM, Ariel Rokem <ar...@be...> wrote:
> Hi everyone,
>
> Mystery solved (I think)! It turns out that matlab has two functions, one
> called "hann" and the other called "hanning". They both purport to produce
> the hanning window, but they produce two (slightly) different things. Only
> one of these (the one given by "hann") actually produces the hanning window
> as it is defined in the standard reference on this (Harris 1978. And also
> Wikipedia ;D). When using the "hann" function in Matlab in this little
> experiment, the difference between the python and the matlab results, is on
> the order of %10e-6. I think I am willing to live with that.
>
> The only mystery that remains (I think) is - what is Matlab's "hanning"
> supposed to be doing? Are there two different windows: hann and hanning (not
> "hamming" - I know that's a different one)?
>
> Cheers,
>
> Ariel
>
>
> On Mon, Feb 8, 2010 at 9:32 AM, Ariel Rokem <ar...@be...> wrote:
>
>> Hi -
>>
>> the maximal difference in this case is of about 6 (units?), which is an
>> approximately 50% difference. This is in one point in the spectrum which has
>> a relatively small value - the maximal peaks in the spectra are on the order
>> of 1200, so in the grand scheme of things, not that horrible. Other large
>> differences are on the order of 4, which is approximately 5% or less of
>> those points.
>>
>> Thanks - Ariel
>>
>> PS for some reason, matplotlib-devel will not get your email unless you
>> hit "reply all", so they have been getting my emails, but not yours. I am
>> not sure whether that is what you intended, so I thought I would mention it.
>>
>>
>>
>> On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt <
>> lud...@gm...> wrote:
>>
>>> Hi,
>>>
>>> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
>>> > I don't think that the cause of the discrepancy is because of the
>>> > hamming/hanning window difference. I do set the window in the matlab
>>> part to
>>> > also be a hanning window of length nfft.
>>>
>>> I suspected you gave the same window to both, but I was just
>>> checking... :-) To find those smaller discrepancies might be a bit
>>> harder then, requiring a careful comparison of the various steps
>>> involved. Just for interest's sake, how big are the differences we are
>>> talking about?
>>>
>>> Regards,
>>> Ludwig
>>>
>>
>>
>>
>> --
>> Ariel Rokem
>> Helen Wills Neuroscience Institute
>> University of California, Berkeley
>> http://argentum.ucbso.berkeley.edu/ariel
>>
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel

Hi everyone,
Mystery solved (I think)! It turns out that matlab has two functions, one
called "hann" and the other called "hanning". They both purport to produce
the hanning window, but they produce two (slightly) different things. Only
one of these (the one given by "hann") actually produces the hanning window
as it is defined in the standard reference on this (Harris 1978. And also
Wikipedia ;D). When using the "hann" function in Matlab in this little
experiment, the difference between the python and the matlab results, is on
the order of %10e-6. I think I am willing to live with that.
The only mystery that remains (I think) is - what is Matlab's "hanning"
supposed to be doing? Are there two different windows: hann and hanning (not
"hamming" - I know that's a different one)?
Cheers,
Ariel
On Mon, Feb 8, 2010 at 9:32 AM, Ariel Rokem <ar...@be...> wrote:
> Hi -
>
> the maximal difference in this case is of about 6 (units?), which is an
> approximately 50% difference. This is in one point in the spectrum which has
> a relatively small value - the maximal peaks in the spectra are on the order
> of 1200, so in the grand scheme of things, not that horrible. Other large
> differences are on the order of 4, which is approximately 5% or less of
> those points.
>
> Thanks - Ariel
>
> PS for some reason, matplotlib-devel will not get your email unless you hit
> "reply all", so they have been getting my emails, but not yours. I am not
> sure whether that is what you intended, so I thought I would mention it.
>
>
> On Mon, Feb 8, 2010 at 1:24 AM, Ludwig Schwardt <lud...@gm...
> > wrote:
>
>> Hi,
>>
>> On Mon, Feb 8, 2010 at 5:25 AM, Ariel Rokem <ar...@be...> wrote:
>> > I don't think that the cause of the discrepancy is because of the
>> > hamming/hanning window difference. I do set the window in the matlab
>> part to
>> > also be a hanning window of length nfft.
>>
>> I suspected you gave the same window to both, but I was just
>> checking... :-) To find those smaller discrepancies might be a bit
>> harder then, requiring a careful comparison of the various steps
>> involved. Just for interest's sake, how big are the differences we are
>> talking about?
>>
>> Regards,
>> Ludwig
>>
>
>
>
> --
> Ariel Rokem
> Helen Wills Neuroscience Institute
> University of California, Berkeley
> http://argentum.ucbso.berkeley.edu/ariel
>
-- 
Ariel Rokem
Helen Wills Neuroscience Institute
University of California, Berkeley
http://argentum.ucbso.berkeley.edu/ariel