matplotlib-devel Mailing List for matplotlib

I was just about to put together a PR to whitelist the test_mplot3d.py so
that Travis would do these tests by default, when I discovered that the
test wasn't even available via the packaged install.
In setupext.py, we have a mpl_toolkits OptionalPackage as well as a tests
OptionalPackage, which are tests for mpl proper, and not mpl_toolkits.
Should the tests for mpl_toolkits be considered a separate OptionalPackage
with dependencies on mpl_toolkits and tests?
I am already pushing the amount of free time I have to work on this,
unfortunately.
Cheers!
Ben Root

How many matplotlib developers are planning to attend SciPy this year?
If we used some of our funds to support an extra hotel night, would any 
of you be interested in spending an extra day for a "matplotlib 
developer summit" to discuss matplotlib projects? This would be in 
addition to the sprints, which I see probably being a larger group. Your 
response isn't a committment at this point, I'm just trying to gauge how 
much interest there might be.
Mike
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

To this end, I have renamed the current 1.4.x milestone -> 1.4.0 and
created a new 1.4.x mile stone. Issues that are bug
fixes/enhancements that should target the _next_ maintenance release,
but may not get into shape in the very near future should be moved to
the new mile stone.
Do we want to do a 1.3.2 at the same time?
Tom
On Tue, Feb 18, 2014 at 9:36 AM, Michael Droettboom <md...@st...> wrote:
> I'm well aware that we were scheduled to get a 1.4.0 release out in
> January. Unfortunately, other work commitments and travel have kept me
> from matplotlib over recent weeks, and it doesn't look like it's going
> to get much better in the short term either. If anyone wants to
> volunteer to take up the release manager role this time around, I, for
> one, would certainly be appreciative. But if no one else is available,
> I'd be glad for any help "around the edges".
>
> The time consuming part of making the release is triaging all of the
> pending bugs and pull requests. It looks like we have 62 for 1.4.x and
> another 12 on 1.3.x at the moment. Then ideally we make sure all
> important changes are in What's New.
>
> Beyond that, the release is essentially mechanical and pretty well
> documented (though the new wrinkle this time around is uploading files
> to PyPI since pip is no longer trusting of files on SourceForge).
>
> Mike
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

Unless someone else really wants to do this, I will volunteer.
Tom
On Tue, Feb 18, 2014 at 9:36 AM, Michael Droettboom <md...@st...> wrote:
> I'm well aware that we were scheduled to get a 1.4.0 release out in
> January. Unfortunately, other work commitments and travel have kept me
> from matplotlib over recent weeks, and it doesn't look like it's going
> to get much better in the short term either. If anyone wants to
> volunteer to take up the release manager role this time around, I, for
> one, would certainly be appreciative. But if no one else is available,
> I'd be glad for any help "around the edges".
>
> The time consuming part of making the release is triaging all of the
> pending bugs and pull requests. It looks like we have 62 for 1.4.x and
> another 12 on 1.3.x at the moment. Then ideally we make sure all
> important changes are in What's New.
>
> Beyond that, the release is essentially mechanical and pretty well
> documented (though the new wrinkle this time around is uploading files
> to PyPI since pip is no longer trusting of files on SourceForge).
>
> Mike
>
> --
> _
> |\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
> | ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
>
> http://www.droettboom.com
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas Caswell
tca...@gm...

Thanks. This link never got moved over after github shut down their 
download service. Your PR looks correct to me.
Mike
On 02/19/2014 12:46 AM, Matthew Brett wrote:
> Hi,
>
> I just noticed that the installation page points to the old github
> download page:
>
> http://matplotlib.org/users/installing.html
>
> https://github.com/matplotlib/matplotlib/downloads
>
> I think it should point to the website download page:
>
> http://matplotlib.org/downloads.html
>
> Is that right?
>
> https://github.com/matplotlib/matplotlib/pull/2821
>
> If so - what should happen to the github downloads page?
>
> Cheers,
>
> Matthew
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

Hey all,
I thought I'd throw out that a tool I'm working on, Plotly <http://plot.ly>,
also does box plots with the option to show jittered points. Instead of
passing in stats you pass in an array of values.
Here is a notebook with the box plots with jitter:
nbviewer.ipython.org/gist/fperez/8930306.
You can also view the mean of the array (the dashed line), +/- 1.5 standard
deviations around the median, and the outliers of the set (the hollow
points): https://plot.ly/~ChrisPP/49.
More generally, we're hoping to soon let folks convert matplotlib scripts
into a Plotly graph (GitHub
Issue<https://github.com/plotly/python-api/issues/3>).
We'd love your advice and thoughts.
Thanks a bunch,
M
On Sun, Feb 16, 2014 at 9:39 PM, Yaroslav Halchenko <sf...@on...>wrote:
> On 2014年2月15日, Thomas A Caswell wrote:
> > As a side note, adding jitter has been discussed before
> > (https://github.com/matplotlib/matplotlib/issues/2750) in a slightly
> > different context and the consensus was to _not_ add it to mpl (as it
> > is a non-deterministic data transformation).
>
> interesting discussion -- thanks for pointing it out Tom
>
> well -- for scatter plot it does make sense to demand jittering
> "outside". For boxplot -- nope. x-axis (in standard vertical
> boxplots) doesn't represent informative dimension anyways, besides
> "groupping" and jitter imho would be only for visualization purpose.
> Also any non-deterministic jitter could be made deterministic and
> reproducible by seeding. Since, once again, here randomization would be
> added only for visualization purpose, it could e.g. always be produced
> by the rng state seeded with 0 ;-)
>
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Senior Research Associate, Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi,
I just noticed that the installation page points to the old github
download page:
http://matplotlib.org/users/installing.html
https://github.com/matplotlib/matplotlib/downloads
I think it should point to the website download page:
http://matplotlib.org/downloads.html
Is that right?
https://github.com/matplotlib/matplotlib/pull/2821
If so - what should happen to the github downloads page?
Cheers,
Matthew

I'm well aware that we were scheduled to get a 1.4.0 release out in 
January. Unfortunately, other work commitments and travel have kept me 
from matplotlib over recent weeks, and it doesn't look like it's going 
to get much better in the short term either. If anyone wants to 
volunteer to take up the release manager role this time around, I, for 
one, would certainly be appreciative. But if no one else is available, 
I'd be glad for any help "around the edges".
The time consuming part of making the release is triaging all of the 
pending bugs and pull requests. It looks like we have 62 for 1.4.x and 
another 12 on 1.3.x at the moment. Then ideally we make sure all 
important changes are in What's New.
Beyond that, the release is essentially mechanical and pretty well 
documented (though the new wrinkle this time around is uploading files 
to PyPI since pip is no longer trusting of files on SourceForge).
Mike
-- 
 _
|\/|o _|_ _. _ | | \.__ __|__|_|_ _ _ ._ _
| ||(_| |(_|(/_| |_/|(_)(/_|_ |_|_)(_)(_)| | |
http://www.droettboom.com

On 2014年2月15日, Thomas A Caswell wrote:
> As a side note, adding jitter has been discussed before
> (https://github.com/matplotlib/matplotlib/issues/2750) in a slightly
> different context and the consensus was to _not_ add it to mpl (as it
> is a non-deterministic data transformation).
interesting discussion -- thanks for pointing it out Tom
well -- for scatter plot it does make sense to demand jittering
"outside". For boxplot -- nope. x-axis (in standard vertical
boxplots) doesn't represent informative dimension anyways, besides
"groupping" and jitter imho would be only for visualization purpose.
Also any non-deterministic jitter could be made deterministic and
reproducible by seeding. Since, once again, here randomization would be
added only for visualization purpose, it could e.g. always be produced
by the rng state seeded with 0 ;-)
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

As a side note, adding jitter has been discussed before
(https://github.com/matplotlib/matplotlib/issues/2750) in a slightly
different context and the consensus was to _not_ add it to mpl (as it
is a non-deterministic data transformation).
Tom
On Sat, Feb 15, 2014 at 10:45 PM, Yaroslav Halchenko <sf...@on...> wrote:
>
> On 2014年2月15日, Paul Hobson wrote:
>> Those figures look great. Seaborn has some similar functionality (scroll
>> down a bit):
>> [1]http://nbviewer.ipython.org/github/mwaskom/seaborn/blob/master/examples/plotting_distributions.ipynb#Comparing-distributions:-boxplot-and-violinplot
>
> right -- seaborn looks really nice and I am yet to take advantage of it.
>
> BUT that is why we are talking here, at matplotlib list: seaborn (and
> few others) while aiming to provide high level convenience, specific to
> e.g. using pandas as the core datastructures, add improvements which
> could easily go into stock matplotlib and thus benefit all of the users.
> That is why I thought that improving boxplot itself could be of
> more generic benefit, while allowing all the dependent projects take
> advantage of it without requiring unnecessary fragmentation (e.g. "use
> seaborn for paired plots", which could easily go straight into stock
> boxplot operating on arrays).
>
> Even violin plots could probably could be done in matplotlib with
> some basic density estimator (with parameter for a custom one) as an
> option within boxplot function itself.
>
>> The main point of the most recent overhaul of boxplots was to allow users
>> to just what you describe. The methods plt.boxplot and ax.boxplot now do
>> very little on their own. Input data are passed to
>> matplotlib.cbook.boxplot_stats, that function returns a list of
>> dictionaries of statistics, and then ax.bxp actually does the drawing. All
>> of this is to say that you can write your own function to modify
>> boxplot_stats' output or generate independently the list of dictionaries
>> expected by ax.bxp.
>> The keys of those dictionaries can include:
>> - label -> tick label for the boxplot
>> - mean -> mean value (can plot as a line or point)
>> - median -> 50th percentile
>> - q1 -> first quartile (25th pctl)
>> - q3 -> third quartile (75 (pctl)
>> - cilo -> lower notch around the median
>> - ciho -> upper notch around the median
>> - whislo -> end of the lower whisker
>> - whishi -> end of the upper whisker
>> - fliers -> outliers
>> Basically, you can set the appropriate values to whatever you want to draw
>> boxplots however you wish (like open/close diagrams for pandas).
>> Also, the `whis` kwarg accepted by boxplot and cbook.boxplot_stats can
>> either be a float (1.5 by default), a list of integer percentiles (like 5,
>> 95), or the strings 'range', 'limits', or 'min/max', all of which will
>> extend the whiskers to over all of the data.
>> Since you're running off of master, you should access to this new
>> functionality.
>
> ;-) usually I run off the releases and even more often from releases in
> Debian stable. But yes -- I have the master and this new functionality
> looks neat -- thanks again. But those few enhancements, such as
>
> - plot actual datapoints with the jitter
> - plot pairing lines across boxplots
>
> seems to be not there and I would consider them worthwhile enhancement
>
>> Feel free to hit me up with any other questions!
>
> sorry that I have hit with not really a question above ;-)
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Senior Research Associate, Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Thomas A Caswell
PhD Candidate University of Chicago
Nagel and Gardel labs
tca...@uc...
jfi.uchicago.edu/~tcaswell
o: 773.702.7204

On 2014年2月15日, Paul Hobson wrote:
> Those figures look great. Seaborn has some similar functionality (scroll
> down a bit):
> [1]http://nbviewer.ipython.org/github/mwaskom/seaborn/blob/master/examples/plotting_distributions.ipynb#Comparing-distributions:-boxplot-and-violinplot
right -- seaborn looks really nice and I am yet to take advantage of it.
BUT that is why we are talking here, at matplotlib list: seaborn (and
few others) while aiming to provide high level convenience, specific to
e.g. using pandas as the core datastructures, add improvements which
could easily go into stock matplotlib and thus benefit all of the users.
That is why I thought that improving boxplot itself could be of
more generic benefit, while allowing all the dependent projects take
advantage of it without requiring unnecessary fragmentation (e.g. "use
seaborn for paired plots", which could easily go straight into stock
boxplot operating on arrays). 
Even violin plots could probably could be done in matplotlib with
some basic density estimator (with parameter for a custom one) as an
option within boxplot function itself.
> The main point of the most recent overhaul of boxplots was to allow users
> to just what you describe. The methods plt.boxplot and ax.boxplot now do
> very little on their own. Input data are passed to
> matplotlib.cbook.boxplot_stats, that function returns a list of
> dictionaries of statistics, and then ax.bxp actually does the drawing. All
> of this is to say that you can write your own function to modify
> boxplot_stats' output or generate independently the list of dictionaries
> expected by ax.bxp.
> The keys of those dictionaries can include:
> - label -> tick label for the boxplot
> - mean -> mean value (can plot as a line or point)
> - median -> 50th percentile
> - q1 -> first quartile (25th pctl)
> - q3 -> third quartile (75 (pctl)
> - cilo -> lower notch around the median
> - ciho -> upper notch around the median 
> - whislo -> end of the lower whisker
> - whishi -> end of the upper whisker
> - fliers -> outliers
> Basically, you can set the appropriate values to whatever you want to draw
> boxplots however you wish (like open/close diagrams for pandas).
> Also, the `whis` kwarg accepted by boxplot and cbook.boxplot_stats can
> either be a float (1.5 by default), a list of integer percentiles (like 5,
> 95), or the strings 'range', 'limits', or 'min/max', all of which will
> extend the whiskers to over all of the data.
> Since you're running off of master, you should access to this new
> functionality.
;-) usually I run off the releases and even more often from releases in
Debian stable. But yes -- I have the master and this new functionality
looks neat -- thanks again. But those few enhancements, such as
- plot actual datapoints with the jitter
- plot pairing lines across boxplots
seems to be not there and I would consider them worthwhile enhancement
> Feel free to hit me up with any other questions!
sorry that I have hit with not really a question above ;-)
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

Yaroslav,
Those figures look great. Seaborn has some similar functionality (scroll
down a bit):
http://nbviewer.ipython.org/github/mwaskom/seaborn/blob/master/examples/plotting_distributions.ipynb#Comparing-distributions:-boxplot-and-violinplot
The main point of the most recent overhaul of boxplots was to allow users
to just what you describe. The methods plt.boxplot and ax.boxplot now do
very little on their own. Input data are passed to
matplotlib.cbook.boxplot_stats, that function returns a list of
dictionaries of statistics, and then ax.bxp actually does the drawing. All
of this is to say that you can write your own function to modify
boxplot_stats' output or generate independently the list of dictionaries
expected by ax.bxp.
The keys of those dictionaries can include:
 - label -> tick label for the boxplot
 - mean -> mean value (can plot as a line or point)
 - median -> 50th percentile
 - q1 -> first quartile (25th pctl)
 - q3 -> third quartile (75 (pctl)
 - cilo -> lower notch around the median
 - ciho -> upper notch around the median
 - whislo -> end of the lower whisker
 - whishi -> end of the upper whisker
 - fliers -> outliers
Basically, you can set the appropriate values to whatever you want to draw
boxplots however you wish (like open/close diagrams for pandas).
Also, the `whis` kwarg accepted by boxplot and cbook.boxplot_stats can
either be a float (1.5 by default), a list of integer percentiles (like 5,
95), or the strings 'range', 'limits', or 'min/max', all of which will
extend the whiskers to over all of the data.
Since you're running off of master, you should access to this new
functionality.
Here's a link to the PR that overhauled ax.boxplot and created ax.bxp:
https://github.com/matplotlib/matplotlib/pull/2643
Looking at it now -- it looks like cbook.boxplot_stats' docstring got
cutoff. I'll pull together a PR to fix that soon.
Feel free to hit me up with any other questions!
-paul
On Sat, Feb 15, 2014 at 2:20 PM, Yaroslav Halchenko <sf...@on...>wrote:
> Hi Paul,
>
> On 2014年2月15日, Paul Hobson wrote:
> > As the author of the fix and the recent overhaul to boxplots
>
> Thanks for that!
>
> > I can say with certainty that R is wrong! ;-)
>
> phew -- thanks ;)
>
> > More seriously, the main thing that I take away from Tukey's paper
> about
> > boxplots, is that there are many valid ways to draw them. I
> personally set
> > up the new boxplot functionality to take the most basic boxplot
> definition
> > very literally. My guess is that R is fudging those rules a bit for
> the
> > purpose of completeness, or aesthetics, or ...(?)
>
> well -- I was trying to figure out why the divergence from R's boxplot
> help, but so far it seemed to match description/definition for boxplot
> as in matplotlib. I guess the next step would be to look "inside"
> (running apt-get source r-base now ;-) )
>
> > Perhaps one can look at the purpose of boxplots in two different
> fashions:
> > 1) Matplotlib: show some of the data and some basic stats
> > 2) R (I'm guession): show how the data are /probably/ distributed.�
> > Obviously, I prefer #1. But I'm not going to say that #2 is wrong just
> > yet.
>
> would you may be interested to adopt (or just do independently) an
> option to e.g. plot the data point? once I shared this one
> http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
> and the actual code https://gist.github.com/yarikoptic/9023331
>
> I just never got to formalize it into mpl pull request :-/
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Senior Research Associate, Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi Paul,
On 2014年2月15日, Paul Hobson wrote:
> As the author of the fix and the recent overhaul to boxplots
Thanks for that!
> I can say with certainty that R is wrong! ;-)
phew -- thanks ;)
> More seriously, the main thing that I take away from Tukey's paper about
> boxplots, is that there are many valid ways to draw them. I personally set
> up the new boxplot functionality to take the most basic boxplot definition
> very literally. My guess is that R is fudging those rules a bit for the
> purpose of completeness, or aesthetics, or ...(?)
well -- I was trying to figure out why the divergence from R's boxplot
help, but so far it seemed to match description/definition for boxplot
as in matplotlib. I guess the next step would be to look "inside"
(running apt-get source r-base now ;-) )
> Perhaps one can look at the purpose of boxplots in two different fashions:
> 1) Matplotlib: show some of the data and some basic stats
> 2) R (I'm guession): show how the data are /probably/ distributed.�
> Obviously, I prefer #1. But I'm not going to say that #2 is wrong just
> yet.
would you may be interested to adopt (or just do independently) an
option to e.g. plot the data point? once I shared this one
http://nbviewer.ipython.org/url/www.onerussian.com/tmp/run_plots.ipynb
and the actual code https://gist.github.com/yarikoptic/9023331
I just never got to formalize it into mpl pull request :-/
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

Hey Yaroslav,
As the author of the fix and the recent overhaul to boxplots, I can say
with certainty that R is wrong! ;-)
More seriously, the main thing that I take away from Tukey's paper about
boxplots, is that there are many valid ways to draw them. I personally set
up the new boxplot functionality to take the most basic boxplot definition
very literally. My guess is that R is fudging those rules a bit for the
purpose of completeness, or aesthetics, or ...(?)
Perhaps one can look at the purpose of boxplots in two different fashions:
1) Matplotlib: show some of the data and some basic stats
2) R (I'm guession): show how the data are /probably/ distributed.
Obviously, I prefer #1. But I'm not going to say that #2 is wrong just yet.
On Sat, Feb 15, 2014 at 5:00 AM, Yaroslav Halchenko <sf...@on...>wrote:
> Dear Matplotlib gurus,
>
> Following the code to demonstrate recent(ish) fix for whiskers in boxplots:
> https://github.com/matplotlib/matplotlib/pull/1855 I have compared it
> against
> R's boxplot. Description seems to correspond, and all the percentiles are
> the
> same in numpy and R (3.0.1) but R's boxplot seems to have extended IQR box
> and
> still have an upper whisker (corresponds to 9000, which is not within
> 75%+1.5*IQR), when it shouldn't:
>
> http://nbviewer.ipython.org/url/www.onerussian.com/tmp/boxplot-Python-vs-R.ipynb
>
> is R's plot incorrect or am I missing something (e.g. documented feature
> in R's boxplot) warranting such a difference?
>
> Thanks in advance
> --
> Yaroslav O. Halchenko, Ph.D.
> http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
> Senior Research Associate, Psychological and Brain Sciences Dept.
> Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
> Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
> WWW: http://www.linkedin.com/in/yarik
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Dear Matplotlib gurus,
Following the code to demonstrate recent(ish) fix for whiskers in boxplots:
https://github.com/matplotlib/matplotlib/pull/1855 I have compared it against
R's boxplot. Description seems to correspond, and all the percentiles are the
same in numpy and R (3.0.1) but R's boxplot seems to have extended IQR box and
still have an upper whisker (corresponds to 9000, which is not within
75%+1.5*IQR), when it shouldn't:
http://nbviewer.ipython.org/url/www.onerussian.com/tmp/boxplot-Python-vs-R.ipynb
is R's plot incorrect or am I missing something (e.g. documented feature
in R's boxplot) warranting such a difference?
Thanks in advance
-- 
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik 

Hi
> Just to elaborate on what Ben said, all matplotlib artists have a "set"
> method. E.g.:
> 
> ax.set(xlim=[min, max], ylim=[min, max], xlabel='blah')
> 
> "plt.setp" basically just calls "set", but it will also operate on
> sequences of artists. Therefore you can do things like:
great! exactly what I was looking for :)
Thanks
Arun

On Wed, Feb 5, 2014 at 3:46 PM, Benjamin Root <ben...@ou...> wrote:
> IIRC, you can use plt.setp() for this purpose:
> http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.setp
>
> Essentially, anything that would come after the "set_" part of an object's
> method can be a keyword. So, I think this would work:
> plt.setp(ax, xlim=[-0.2, 0.9], ylim=[-100,100], zlim=[-0.3, 0.4])
> plt.setp(ax, xlabel='Time [$\mu$s]', ylabel='Bias [V]',
> zlabel='Voltage[V]')
>
<snip>
Just to elaborate on what Ben said, all matplotlib artists have a "set"
method. E.g.:
 ax.set(xlim=[min, max], ylim=[min, max], xlabel='blah')
"plt.setp" basically just calls "set", but it will also operate on
sequences of artists. Therefore you can do things like:
fig, axes = plt.subplots(nrows=2, ncols=2)
plt.setp(axes.flat, aspect=2, ...)
Some people prefer the "Tk-style" set method to using "setp" if you're
operating on a single artist.
Keep in mind that it also works for other artists, not just axes. At any
rate, "setp" and the "set" method are certainly handy to know about!
Cheers,
-Joe

IIRC, you can use plt.setp() for this purpose:
http://matplotlib.org/api/pyplot_api.html#matplotlib.pyplot.setp
Essentially, anything that would come after the "set_" part of an object's
method can be a keyword. So, I think this would work:
plt.setp(ax, xlim=[-0.2, 0.9], ylim=[-100,100], zlim=[-0.3, 0.4])
plt.setp(ax, xlabel='Time [$\mu$s]', ylabel='Bias [V]', zlabel='Voltage[V]')
Note, you no longer need to say "xlim3d" and the likes, it is just "xlim",
"ylim" and "zlim" (as of v1.1, IIRC).
Again, completely untested, and off the top of my head.
Cheers!
Ben Root
On Wed, Feb 5, 2014 at 3:49 PM, Arun Persaud <ape...@lb...> wrote:
> Hi
>
> Hope this is the right place to post a request for enhancement.
>
> I often create a bunch of relatively basic plots using matplotlib and
> the commands to set the labels and limits take up more space than the
> actual plotting commands (figure, plot, show), so I was wondering if
> there is a shorter way of doing this (I couldn't find one) and if not,
> if a shortcut notation could be added.
>
> Here are some code lines I use at the moment:
>
> 3d plot:
>
> ax.set_xlabel('Time [$\mu$s]')
> ax.set_xlim3d(-0.2, 0.9)
> ax.set_ylabel('Bias [V]')
> ax.set_ylim3d(-100, 100)
> ax.set_zlabel('Voltage[V]')
> ax.set_zlim3d(-0.3, 0.4)
>
> 2d plot:
>
> plt.xlabel('Time [$\mu$s]')
> plt.ylabel('Voltage [V]')
> plt.xlim(0, 100)
> plt.ylim(0, 50)
>
>
>
> proposed syntax:
>
> # Z being optional
> plt.labels(X='Time [$\mu$s]', Y='Bias [V]', Z='Voltage[V]')
> plt.limits(X=[-0.2, 0.9], Y=[-100,100], Z=[-0.3, 0.4])
>
>
>
> label could also have a **kwargs that would be handed on to all
> [xyz]label, in case one needs to set fontsize for all labels.
>
> label could also have an optional title=''.
>
> limits could test for 2d or 3d plots and call the correct functions
> automatically.
>
> Arun
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Hi
Hope this is the right place to post a request for enhancement.
I often create a bunch of relatively basic plots using matplotlib and
the commands to set the labels and limits take up more space than the
actual plotting commands (figure, plot, show), so I was wondering if
there is a shorter way of doing this (I couldn't find one) and if not,
if a shortcut notation could be added.
Here are some code lines I use at the moment:
3d plot:
ax.set_xlabel('Time [$\mu$s]')
ax.set_xlim3d(-0.2, 0.9)
ax.set_ylabel('Bias [V]')
ax.set_ylim3d(-100, 100)
ax.set_zlabel('Voltage[V]')
ax.set_zlim3d(-0.3, 0.4)
2d plot:
plt.xlabel('Time [$\mu$s]')
plt.ylabel('Voltage [V]')
plt.xlim(0, 100)
plt.ylim(0, 50)
proposed syntax:
# Z being optional
plt.labels(X='Time [$\mu$s]', Y='Bias [V]', Z='Voltage[V]')
plt.limits(X=[-0.2, 0.9], Y=[-100,100], Z=[-0.3, 0.4])
label could also have a **kwargs that would be handed on to all
[xyz]label, in case one needs to set fontsize for all labels.
label could also have an optional title=''.
limits could test for 2d or 3d plots and call the correct functions
automatically.
Arun

I noticed that when you offset the spines of an Axes object, the labels,
ticks, and ticklabels/formatting get mostly cleared. Is this intentional
and is there a way to prevent (or undo) it?
It's probably easiest to just look at a notebook:
http://nbviewer.ipython.org/gist/phobson/8818648
That notebook contains a proposed solution from Stack Overflow.
Unfortunately, minor ticks and labels are missed (and I can't understand
why as the values are contained in the properties dictionary of the spines).
Background: I'm trying to add an offset kwarg to the despine function in
seaborn (https://github.com/mwaskom/seaborn/pull/92). Point of mentioning
that is that to make this work, we need to be able to offset the spines
*after* plotting and formatting ticks.
Alternatively, if there was a way to specify a default offset in rcParams
before a figure and axes were even created, that might work too.
------
Related to that, when I use the SO solution, about 50% of the time the axes
labels are rendered as the label objects, not text. Whatever triggers that
doesn't seem to be deterministic. Resetting the notebook will fix it or
break it -- there's no telling how it's going to go. Here's the exact same
notebook as above, with the mangled figure at the bottom.
http://nbviewer.ipython.org/gist/phobson/8818680
Cheers,
-Paul

On 31 January 2014 22:43, Benjamin Root <ben...@ou...> wrote:
> Thanks for bringing this back onto the mailing list.
>
> I am excited for the prospect of new algorithms for contouring. My company
> has actually been using the contourf() function for the past few years to
> generate the polygons from gridded data to then make shapefiles from those
> polygons. Having an rcParam and a kwarg for controlling which algorithm
> gets used for contouring would be good for us when we transition to any new
> algorithms.
>
It is good to hear that it will be useful.
> I also advocate strongly for better separation between the plotting and
> the contouring. I made an attempt awhile back for my work to not have to
> call contourf() so that my shapefile library code wouldn't interfere with
> anybody's plotting that they happen to be doing, but I just couldn't get a
> clean separation. I ended up having to wrap my contouring code as a
> sub-process.
>
This is not in the scope of the work I am doing - see my previous answer to
Eric.
> Do keep me in the loop about this, as I have a fairly substantial data
> source for testing.
>
Excellent, testing by others will be much appreciated. I won't submit a PR
on this until after the impending release so there is plenty of time for
testing before the release after that.
Ian

On 31 January 2014 19:51, Eric Firing <ef...@ha...> wrote:
> Would the new code be substantially simpler if the blocky capability were
> omitted from it? If so, then it seems like it would makes sense to leave
> the blocky form to the old code.
>
Simpler, yes, but not substantially so. I would prefer to keep both blocky
and corner-cutting algorithms together so that there is only one extension
to maintain when we eventually remove the old code.
One thing to keep in mind is the desire for a cleaner separation between
> the generation of the contours and their plotting. Sometimes one actually
> wants the polygons themselves; for example, topographic contours can be
> used to define boundaries for internal wave flux calculations. A student
> here at UH is doing exactly this.
>
That is certainly desirable, but not part of the work I am doing. I am
rewriting the C/C++ code that calculates the contours, but the interface
between that and the python contour code remains the same, apart from some
trivial changes of course.
Ian

Hi Mauricio,
Patch objects are a bit more difficult to work with than line objects,
because unlike line objects are a step removed from the input data supplied
by the user. There is an example similar to what you want to do here:
http://matplotlib.org/examples/animation/histogram.html
Basically, you need to modify the vertices of the path at each frame. It
might look something like this:
from matplotlib import animation
import numpy as np
import matplotlib.pyplot as plt
fig, ax = plt.subplots()
ax.set_xlim([0,10000])
x = np.linspace(6000.,7000., 5)
y = np.ones_like(x)
collection = plt.fill_between(x, y)
def animate(i):
 path = collection.get_paths()[0]
 path.vertices[:, 1] *= 0.9
animation.FuncAnimation(fig, animate,
 frames=25, interval=30)
Take a look at path.vertices to see how they're laid out.
Hope that helps,
 Jake
On Sat, Feb 1, 2014 at 7:44 AM, Mauricio Calvao <moc...@gm...> wrote:
> Hi there,
>
> I have the following simple code to plot a (static) fill_between region
> in a given plot.
>
>
> import numpy as np
> import matplotlib. pyplot as plt
>
> plt.figure()
> ax=plt.axes()
> ax.set_xlim([0,10000])
>
> x = np.linspace(6000.,7000.)
> y = np.ones(np.shape(x))
>
> plt.fill_between(x,y)
>
>
> I would like now to animate this band (which is a PolyCollection object,
> and not a Line2D one) so that it moves smoothly to the right up together
> with being stretched, that is, to the new x positions: .7200, 8400. I saw
> several animations in the matplotlib homepage, but they only looped over
> line or image objects, not polycollection ones, such as fill_between... Is
> this possible?
>
> In stackoverflow there is this link:
> http://stackoverflow.com/questions/16120801/matplotlib-animate-fill-between-shape,
> which might solve this question but I was not able to understand it fully
> in order to have a simple minmal working example. If that is the right
> direction, I would appreciate immensely if someone could provide such an
> example!
>
> Thanks in advance
>
> --
> #######################################
> Prof. Mauricio Ortiz Calvao
> Federal University of Rio de Janeiro
> Institute of Physics, P O Box 68528
> CEP 21941-972 Rio de Janeiro, RJ
> Brazil
>
> Email: or...@if...
> Phone: (55)(21)25627483
> Homepage: http://www.if.ufrj.br/~orca
> #######################################
>
>
> ------------------------------------------------------------------------------
> WatchGuard Dimension instantly turns raw network data into actionable
> security intelligence. It gives you real-time visual feedback on key
> security issues and trends. Skip the complicated setup - simply import
> a virtual appliance and go from zero to informed in seconds.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Thank you Jake.
I will take a look at this example with care.
Cheers!
On Sun, Feb 2, 2014 at 2:10 PM, Jacob Vanderplas
<ja...@cs...>wrote:
> Hi Mauricio,
> Patch objects are a bit more difficult to work with than line objects,
> because unlike line objects are a step removed from the input data supplied
> by the user. There is an example similar to what you want to do here:
> http://matplotlib.org/examples/animation/histogram.html
>
> Basically, you need to modify the vertices of the path at each frame. It
> might look something like this:
>
> from matplotlib import animation
> import numpy as np
> import matplotlib.pyplot as plt
>
> fig, ax = plt.subplots()
> ax.set_xlim([0,10000])
>
> x = np.linspace(6000.,7000., 5)
> y = np.ones_like(x)
>
> collection = plt.fill_between(x, y)
>
> def animate(i):
> path = collection.get_paths()[0]
> path.vertices[:, 1] *= 0.9
>
> animation.FuncAnimation(fig, animate,
> frames=25, interval=30)
>
> Take a look at path.vertices to see how they're laid out.
> Hope that helps,
> Jake
>
>
> On Sat, Feb 1, 2014 at 7:44 AM, Mauricio Calvao <moc...@gm...>wrote:
>
>> Hi there,
>>
>> I have the following simple code to plot a (static) fill_between region
>> in a given plot.
>>
>>
>> import numpy as np
>> import matplotlib. pyplot as plt
>>
>> plt.figure()
>> ax=plt.axes()
>> ax.set_xlim([0,10000])
>>
>> x = np.linspace(6000.,7000.)
>> y = np.ones(np.shape(x))
>>
>> plt.fill_between(x,y)
>>
>>
>> I would like now to animate this band (which is a PolyCollection object,
>> and not a Line2D one) so that it moves smoothly to the right up together
>> with being stretched, that is, to the new x positions: .7200, 8400. I saw
>> several animations in the matplotlib homepage, but they only looped over
>> line or image objects, not polycollection ones, such as fill_between... Is
>> this possible?
>>
>> In stackoverflow there is this link:
>> http://stackoverflow.com/questions/16120801/matplotlib-animate-fill-between-shape,
>> which might solve this question but I was not able to understand it fully
>> in order to have a simple minmal working example. If that is the right
>> direction, I would appreciate immensely if someone could provide such an
>> example!
>>
>> Thanks in advance
>>
>> --
>> #######################################
>> Prof. Mauricio Ortiz Calvao
>> Federal University of Rio de Janeiro
>> Institute of Physics, P O Box 68528
>> CEP 21941-972 Rio de Janeiro, RJ
>> Brazil
>>
>> Email: or...@if...
>> Phone: (55)(21)25627483
>> Homepage: http://www.if.ufrj.br/~orca
>> #######################################
>>
>>
>> ------------------------------------------------------------------------------
>> WatchGuard Dimension instantly turns raw network data into actionable
>> security intelligence. It gives you real-time visual feedback on key
>> security issues and trends. Skip the complicated setup - simply import
>> a virtual appliance and go from zero to informed in seconds.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>
>>
>
-- 
#######################################
Prof. Mauricio Ortiz Calvao
Federal University of Rio de Janeiro
Institute of Physics, P O Box 68528
CEP 21941-972 Rio de Janeiro, RJ
Brazil
Email: or...@if...
Phone: (55)(21)25627483
Homepage: http://www.if.ufrj.br/~orca
#######################################

Hi there,
I have the following simple code to plot a (static) fill_between region in
a given plot.
import numpy as np
import matplotlib. pyplot as plt
plt.figure()
ax=plt.axes()
ax.set_xlim([0,10000])
x = np.linspace(6000.,7000.)
y = np.ones(np.shape(x))
plt.fill_between(x,y)
I would like now to animate this band (which is a PolyCollection object,
and not a Line2D one) so that it moves smoothly to the right up together
with being stretched, that is, to the new x positions: .7200, 8400. I saw
several animations in the matplotlib homepage, but they only looped over
line or image objects, not polycollection ones, such as fill_between... Is
this possible?
In stackoverflow there is this link:
http://stackoverflow.com/questions/16120801/matplotlib-animate-fill-between-shape,
which might solve this question but I was not able to understand it fully
in order to have a simple minmal working example. If that is the right
direction, I would appreciate immensely if someone could provide such an
example!
Thanks in advance
-- 
#######################################
Prof. Mauricio Ortiz Calvao
Federal University of Rio de Janeiro
Institute of Physics, P O Box 68528
CEP 21941-972 Rio de Janeiro, RJ
Brazil
Email: or...@if...
Phone: (55)(21)25627483
Homepage: http://www.if.ufrj.br/~orca
#######################################