matplotlib-devel — matplotlib developers

Re: [matplotlib-devel] is R wrong? (boxplot)

[Yaroslav H. <sf...@on...>]

On Sat, 15 Feb 2014, 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        

Re: [matplotlib-devel] is R wrong? (boxplot)

[Thomas A C. <tca...@uc...>]

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 Sat, 15 Feb 2014, 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

Re: [matplotlib-devel] is R wrong? (boxplot)

[Yaroslav H. <sf...@on...>]

On Sat, 15 Feb 2014, 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        

Re: [matplotlib-devel] is R wrong? (boxplot)

[Paul H. <pmh...@gm...>]

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 Sat, 15 Feb 2014, 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
>

Re: [matplotlib-devel] is R wrong? (boxplot)

[Yaroslav H. <sf...@on...>]

Hi Paul,

On Sat, 15 Feb 2014, 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        

Re: [matplotlib-devel] is R wrong? (boxplot)

[Paul H. <pmh...@gm...>]

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
>

[matplotlib-devel] is R wrong? (boxplot)

[Yaroslav H. <sf...@on...>]

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        

Re: [matplotlib-devel] RFE: shortcut for [xyz|]label and [xyz]lim?

[Arun P. <ape...@lb...>]

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

Re: [matplotlib-devel] RFE: shortcut for [xyz|]label and [xyz]lim?

[Joe K. <jki...@ge...>]

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

Re: [matplotlib-devel] RFE: shortcut for [xyz|]label and [xyz]lim?

[Benjamin R. <ben...@ou...>]

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
>

[matplotlib-devel] RFE: shortcut for [xyz|]label and [xyz]lim?

[Arun P. <ape...@lb...>]

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

[matplotlib-devel] Axes properties are cleared after offsetting spines

[Paul H. <pmh...@gm...>]

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

Re: [matplotlib-devel] New contouring algorithm

[Ian T. <ian...@gm...>]

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

Re: [matplotlib-devel] New contouring algorithm

[Ian T. <ian...@gm...>]

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

Re: [matplotlib-devel] animation of a fill_between region

[Jacob V. <ja...@cs...>]

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

Re: [matplotlib-devel] animation of a fill_between region

[Mauricio C. <moc...@gm...>]

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

[matplotlib-devel] animation of a fill_between region

[Mauricio C. <moc...@gm...>]

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

Re: [matplotlib-devel] New contouring algorithm

[Benjamin R. <ben...@ou...>]

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.

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.

Do keep me in the loop about this, as I have a fairly substantial data
source for testing.

Cheers!
Ben Root



On Fri, Jan 31, 2014 at 2:51 PM, Eric Firing <ef...@ha...> wrote:

> On 2014/01/30 10:22 PM, Ian Thomas wrote:
>
> > (Taking this away from the mailing list as it is going off topic).
>
> I'm putting it on the devel list; it will be good for others to know
> this is in the works, and be able to advise on strategy before it gets
> to the PR stage.
>
> >
> > The new contour code can do both the old blocky form of contouring and
> > the new corner-cutting.  As you suggest, I was going to leave the old
> > algorithm in mpl as well (perhaps undocumented), so there will be three
> > choices for contouring in the short term, eventually reduced to two when
> > we can safely remove the old algorithm.  I was going to opt for a kwarg
> > to contour(f) to specify which of the three algorithms, as this will
> > allow easy automated testing and a comparison example that shows the
> > blocky and corner-cutting results side-by-side.  I like the idea of an
> > rcParam though, which could be used as a default if the kwarg is not
> > specified in a particular contour(f) call.  Does this sound like a good
> > plan?
>
> Yes, I think this is ideal.
>
> 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.
>
> >
> > By the way, the reason it is yet again slow to progress is that I've had
> > to do a partial rewrite.  If you remember I had taken the approach of
> > using a single large numpy array of points per pair of contourf levels
> > that was really fast for the contouring algorithm to produce but
> > potentially slow for rendering and would eventually hit some backend
> > limit of max number of points rendered at any one time.  Well now I've
> > reverted to the same output as the old algorithm, i.e. a numpy array for
> > each polygon and its contained holes, which is obviously much safer.  It
> > turned out that my naive changes to do this scaled really badly so I had
> > to rewrite some of the algorithm to calculate the hole containment as it
> > progresses.  Because of this It is much less elegant than it was and I
> > need to put in a bit more time to make it easier to understand before
> > release.
>
> Less elegant--too bad!
>
> 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.
>
> Eric
> >
> > Ian
>
>
>
> ------------------------------------------------------------------------------
> 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
>

[matplotlib-devel] New contouring algorithm

[Eric F. <ef...@ha...>]

On 2014/01/30 10:22 PM, Ian Thomas wrote:

> (Taking this away from the mailing list as it is going off topic).

I'm putting it on the devel list; it will be good for others to know 
this is in the works, and be able to advise on strategy before it gets 
to the PR stage.

>
> The new contour code can do both the old blocky form of contouring and
> the new corner-cutting.  As you suggest, I was going to leave the old
> algorithm in mpl as well (perhaps undocumented), so there will be three
> choices for contouring in the short term, eventually reduced to two when
> we can safely remove the old algorithm.  I was going to opt for a kwarg
> to contour(f) to specify which of the three algorithms, as this will
> allow easy automated testing and a comparison example that shows the
> blocky and corner-cutting results side-by-side.  I like the idea of an
> rcParam though, which could be used as a default if the kwarg is not
> specified in a particular contour(f) call.  Does this sound like a good
> plan?

Yes, I think this is ideal.

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.

>
> By the way, the reason it is yet again slow to progress is that I've had
> to do a partial rewrite.  If you remember I had taken the approach of
> using a single large numpy array of points per pair of contourf levels
> that was really fast for the contouring algorithm to produce but
> potentially slow for rendering and would eventually hit some backend
> limit of max number of points rendered at any one time.  Well now I've
> reverted to the same output as the old algorithm, i.e. a numpy array for
> each polygon and its contained holes, which is obviously much safer.  It
> turned out that my naive changes to do this scaled really badly so I had
> to rewrite some of the algorithm to calculate the hole containment as it
> progresses.  Because of this It is much less elegant than it was and I
> need to put in a bit more time to make it easier to understand before
> release.

Less elegant--too bad!

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.

Eric
>
> Ian

Re: [matplotlib-devel] MEP22 doc

[Federico A. <ari...@gm...>]

@tacaswell I have been thinking about what we discussed last time.

Again, sorry for the long email

Locks:
I reduced the number of locks to 2.
This is what navigation actually uses,:
* keypress: to know if it can process the keypress
* message: to know if it can print stuff to the message area.

Radio/toggling logic inside GUI toolkit:
We can put it inside the toolbar because the toolkit already have the
mechanics (as you mentionned),
The problem is that we have to replicate all this logic inside the
navigation in case there is no toolbar. And we have to make sure the
two are in sync all the time.
Think of sequence, click to trigger tool1, keypress to trigger
tool2.... According to me, it becomes messy to know exactly what is
going to happen in the toolbar.

Radio/toggling logic inside the tools:
This can be done, but I don't like the idea of the tools knowing about
the other tools, all the tools of the same group have to be registered
with the other tools, and adding and removing them at runtime can
become messy, if navigation keeps a central register of all the tools,
it can make changes without a problem.
If a tool wants to know about other tools, they can acces them
throught self.navigation.

Use tool instances instead of tool clases
For this one I am almost on your side.
The only downside that I see with this, is:
To make GUI tools, it becomes a little bit more work.
The tool has to keep track of the window state (open/close) and
recreate its gui if it has been closed/destroyed etc..
If we instantiate at first trigger time (as it is right now), the tool
can be a standard GUI window with a trigger method, and calling
unregister at destroy. No open/close state.


Federico



On Tue, Jan 28, 2014 at 9:51 PM, Federico Ariza
<ari...@gm...> wrote:
> The idea to pass the reference of the tool, is just to have a
> collection of instantiable classes.
> This allows me to create the toolbar and keymap with their class
> attributes without instantiating the classes. And leave the __init__
> method available for more important things, as window creation and
> that kind of things.
>
> If I don't handle the tool trigger in navigation then I have to check
> for toggled tools, to untoggle others. And if toggled from keypress
> then toggle toolbar without calling callback, etc...... Right now this
> problem doesn't exist because the buttons are not toggle, but I
> definitively want to use Toggle buttons, I hate that I don't know if
> zoom is active or not.
>
> Why to keep the instances alive? take the example of configuresuplots,
> in this case if I don't keep the instance alive, I will end with many
> windows, or having to deal with singletons that I think is not a good
> idea. Other examples comes to mind, for example if you want to make a
> logger, you want it to be alive in the background and not being a
> toggle.
>
> Federico
>
>
> On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell <tca...@gm...> wrote:
>> On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza
>> <ari...@gm...> wrote:
>>> activate: I agree with you, renamed to trigger
>>>
>>> [I don't understand. The `__init__` gets called when the tool object
>>> is created (and it gets registered with a particular
>>> `NavigationBase`/`Figure`/`canvas`.  The tool object then sits around
>>> doing nothing waiting to be triggered.  I can see wanting to remove
>>> one of these buttons, in which case it will need to be un-registered]
>>>
>>> I am not expressing myself correctly, what I am trying to say is that
>>> the Tool object is only created when the tool is triggered.
>>> The tool.trigger method is called in the ToolBase.__init__ method
>>> For ToolBase tools, the object is not registered, so there is no
>>> reference to it anywhere, so it should be garbage collected. I can add
>>> a del to the object but I think is unnecesary.
>>> ToolPersistentBase
>>> [shouldn't `__init__` be called when the tool is created?
>>> I think the confusion here is that I don't create the tools until they
>>> are triggered, until then, is just a reference to the class. in the
>>> navitaion._tools dict.
>>
>> If you do not instantiate the object until the button get pushed, why
>> even bother with a class, can't this just be a function?  I still
>> think it would be better create the `Tool` objects when you create the
>> figure and then call their `trigger` function when the button gets
>> pushed.  For one thing, this makes it dead-simple to rig up the gui
>> side of things (at least in Qt, I would assume the others are similar
>> `button.clicked.connect(self._home_tool.trigger)` ) as the functions
>> we care about already look like call-backs.   I am not sure that the
>> benefit of doing it the way you wrote it (with the button-push-time
>> object creation) is worth the added complexity.
>>
>>
>> I think we only need two kinds of tools, the kind you push once and
>> they fire off an action (simple push button, need one public function
>> `trigger` this works for simple actions home, quit, back and things
>> that create extra windows) and the kind you can toggle on and off
>> (need two public functions `enable` and `disable` which are what they
>> do when you turn them on (set up call backs to grab input) and turn
>> them off (tear down/disconnect the canvas call backs) which eliminates
>> much of the need for keeping track of locks (I think).  The toggle
>> kind may or may not be group in to exclusion groups (pan/zoom) but I
>> could see doing 'toggle grid lines' as this type as well.
>>
>> Tom
>>
>> --
>> Thomas Caswell
>> tca...@gm...
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] Replacing matplotlib.delaunay natural neighbor interpolation

[Chris B. <chr...@no...>]

On Tue, Jan 28, 2014 at 12:59 AM, Ian Thomas <ian...@gm...> wrote:

> I expect we will add more triangular grid interpolators to matplotlib in
> due course and I am happy to receive suggestions on this.  However, this
> will not include natural neighbour.  Natural neighbour interpolation is
> specific to delaunay triangulation, and as we also support user-specified
> triangulations I am only interested in interpolation that covers all
> triangulations.
>

I appreciate the separation of the triangulation from the interpolation,
but I also like natural neighbor.

But is it really only usable with delauney triangulations  I can see that
it may not have very nice properties when applied with a very
non-delaunay triangulation, but I can't see why it it wouldn't  be
computable. Or am I missing something?

-Chris

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chr...@no...

Re: [matplotlib-devel] MEP22 doc

[Federico A. <ari...@gm...>]

The idea to pass the reference of the tool, is just to have a
collection of instantiable classes.
This allows me to create the toolbar and keymap with their class
attributes without instantiating the classes. And leave the __init__
method available for more important things, as window creation and
that kind of things.

If I don't handle the tool trigger in navigation then I have to check
for toggled tools, to untoggle others. And if toggled from keypress
then toggle toolbar without calling callback, etc...... Right now this
problem doesn't exist because the buttons are not toggle, but I
definitively want to use Toggle buttons, I hate that I don't know if
zoom is active or not.

Why to keep the instances alive? take the example of configuresuplots,
in this case if I don't keep the instance alive, I will end with many
windows, or having to deal with singletons that I think is not a good
idea. Other examples comes to mind, for example if you want to make a
logger, you want it to be alive in the background and not being a
toggle.

Federico


On Tue, Jan 28, 2014 at 9:32 PM, Thomas Caswell <tca...@gm...> wrote:
> On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza
> <ari...@gm...> wrote:
>> activate: I agree with you, renamed to trigger
>>
>> [I don't understand. The `__init__` gets called when the tool object
>> is created (and it gets registered with a particular
>> `NavigationBase`/`Figure`/`canvas`.  The tool object then sits around
>> doing nothing waiting to be triggered.  I can see wanting to remove
>> one of these buttons, in which case it will need to be un-registered]
>>
>> I am not expressing myself correctly, what I am trying to say is that
>> the Tool object is only created when the tool is triggered.
>> The tool.trigger method is called in the ToolBase.__init__ method
>> For ToolBase tools, the object is not registered, so there is no
>> reference to it anywhere, so it should be garbage collected. I can add
>> a del to the object but I think is unnecesary.
>> ToolPersistentBase
>> [shouldn't `__init__` be called when the tool is created?
>> I think the confusion here is that I don't create the tools until they
>> are triggered, until then, is just a reference to the class. in the
>> navitaion._tools dict.
>
> If you do not instantiate the object until the button get pushed, why
> even bother with a class, can't this just be a function?  I still
> think it would be better create the `Tool` objects when you create the
> figure and then call their `trigger` function when the button gets
> pushed.  For one thing, this makes it dead-simple to rig up the gui
> side of things (at least in Qt, I would assume the others are similar
> `button.clicked.connect(self._home_tool.trigger)` ) as the functions
> we care about already look like call-backs.   I am not sure that the
> benefit of doing it the way you wrote it (with the button-push-time
> object creation) is worth the added complexity.
>
>
> I think we only need two kinds of tools, the kind you push once and
> they fire off an action (simple push button, need one public function
> `trigger` this works for simple actions home, quit, back and things
> that create extra windows) and the kind you can toggle on and off
> (need two public functions `enable` and `disable` which are what they
> do when you turn them on (set up call backs to grab input) and turn
> them off (tear down/disconnect the canvas call backs) which eliminates
> much of the need for keeping track of locks (I think).  The toggle
> kind may or may not be group in to exclusion groups (pan/zoom) but I
> could see doing 'toggle grid lines' as this type as well.
>
> Tom
>
> --
> Thomas Caswell
> tca...@gm...



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] MEP22 doc

[Thomas C. <tca...@gm...>]

On Tue, Jan 28, 2014 at 7:27 PM, Federico Ariza
<ari...@gm...> wrote:
> activate: I agree with you, renamed to trigger
>
> [I don't understand. The `__init__` gets called when the tool object
> is created (and it gets registered with a particular
> `NavigationBase`/`Figure`/`canvas`.  The tool object then sits around
> doing nothing waiting to be triggered.  I can see wanting to remove
> one of these buttons, in which case it will need to be un-registered]
>
> I am not expressing myself correctly, what I am trying to say is that
> the Tool object is only created when the tool is triggered.
> The tool.trigger method is called in the ToolBase.__init__ method
> For ToolBase tools, the object is not registered, so there is no
> reference to it anywhere, so it should be garbage collected. I can add
> a del to the object but I think is unnecesary.
> ToolPersistentBase
> [shouldn't `__init__` be called when the tool is created?
> I think the confusion here is that I don't create the tools until they
> are triggered, until then, is just a reference to the class. in the
> navitaion._tools dict.

If you do not instantiate the object until the button get pushed, why
even bother with a class, can't this just be a function?  I still
think it would be better create the `Tool` objects when you create the
figure and then call their `trigger` function when the button gets
pushed.  For one thing, this makes it dead-simple to rig up the gui
side of things (at least in Qt, I would assume the others are similar
`button.clicked.connect(self._home_tool.trigger)` ) as the functions
we care about already look like call-backs.   I am not sure that the
benefit of doing it the way you wrote it (with the button-push-time
object creation) is worth the added complexity.


I think we only need two kinds of tools, the kind you push once and
they fire off an action (simple push button, need one public function
`trigger` this works for simple actions home, quit, back and things
that create extra windows) and the kind you can toggle on and off
(need two public functions `enable` and `disable` which are what they
do when you turn them on (set up call backs to grab input) and turn
them off (tear down/disconnect the canvas call backs) which eliminates
much of the need for keeping track of locks (I think).  The toggle
kind may or may not be group in to exclusion groups (pan/zoom) but I
could see doing 'toggle grid lines' as this type as well.

Tom

-- 
Thomas Caswell
tca...@gm...

Re: [matplotlib-devel] MEP22 doc

[Federico A. <ari...@gm...>]

@tacaswell regarding your last comments on the wiki

Again, please let me know if something is not clear or you have suggestions

Again, sorry for the long email, but please don't forget the previous
one about the locks.....

activate: I agree with you, renamed to trigger

[I don't understand. The `__init__` gets called when the tool object
is created (and it gets registered with a particular
`NavigationBase`/`Figure`/`canvas`.  The tool object then sits around
doing nothing waiting to be triggered.  I can see wanting to remove
one of these buttons, in which case it will need to be un-registered]

I am not expressing myself correctly, what I am trying to say is that
the Tool object is only created when the tool is triggered.
The tool.trigger method is called in the ToolBase.__init__ method
For ToolBase tools, the object is not registered, so there is no
reference to it anywhere, so it should be garbage collected. I can add
a del to the object but I think is unnecesary.


ToolPersistentBase
[shouldn't `__init__` be called when the tool is created?
I think the confusion here is that I don't create the tools until they
are triggered, until then, is just a reference to the class. in the
navitaion._tools dict.

ToolToggleBase
[I would give them enable/disable methods, and make their `triggered`
action to call their own `enable`]
Actually it makes more sense, thanks.

On Tue, Jan 28, 2014 at 6:17 PM, Federico Ariza
<ari...@gm...> wrote:
> Hello again
>
> I have been playing with the locks to find a solution.
> What we need is a way to let tools absorb the events (lock its use).
>
> The problem that I'm facing is that Navigation itself needs to capture
> two different events.
>
> key_press_event for tool triggering
> motion_notify_event for setting the message with the pointer position
> and cursor changing.
>
> Now the options that I see are:
>
> Let the tools disconnect and reconnect this signals in navigation.
> self.figure.canvas.mpl_disconnect(self.navigation.id_move)
> ....
> self.navigation.id_move =
> self.figure.canvas.mpl_connect('motion_notify_event',
> self.navigation.mouse_move)
>
> Create helper methods to disconnect and reconnect this signals in navigation
> self.navigation.disconnect('mouse_move')
> ....
> self.navigation.connect('mouse_move')
>
> Use locks and let navigation redirect these events to the appropiate
> place (what I'm doing right now).
> self.navigation.movelock(self)
> self.navigation.movelock.release(self)
>
> Do you see other options?
>
> One thing that is clear, is that for the moment Navigation needs only
> two handlers, so I can reduce the number of locks to two....
>
> Thanks
> Federico
>
> On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza
> <ari...@gm...> wrote:
>> @tacaswell I modified the wiki reflecting the changes and trying to
>> answer the questions.
>> Please let me know if I answered your questions/concerns. We can
>> iterate as muchs as needed on this, I have no problem modifying the
>> names or functionnality.
>>
>> Sorry for the long email
>> Here a list of things that I changed
>>
>> ToolBase
>> description = '': Small description of the tool
>>
>> persistent = False: If True, the instance of the Tool is registered
>> with Navigation for reuse.
>> This is needed because some tools are keept alive in the background,
>> for example SubplotTool.
>>
>> position = None: Where is it positionned in the toolbar?. -1 = at the
>> end, None = Not in the toolbar.
>> The default tools are all ordered by their position in the Navigation
>> _default_tools array. This argument is mainly used by User created
>> tools that are added after the Toolbar creation.
>> My idea was that for the user created tools, the user could set the
>> position without having to subclass the Navigation class.
>> So this information has to be included in the Tool.
>>
>>
>> activate(self, event): This is the main method of the Tool, it is
>> called when the Tool is triggered by:
>>   * Toolbar button click
>>   * keypress associated with the Tool Keymap
>>   * Call to navigation.click_tool(name)
>>
>>
>> ToolPersistentBase
>> unregister(self, *args): ... Because ToolBase is intened for single
>> use, there is no need of registration for the instances, persistent
>> tools, need to be registered so __init__ is called only onece during
>> the first trigger
>>
>>
>> NavigationBase
>> locks.... I tend to agree with you.
>> The idea that I had in mind, and maybe was more complex than expected.
>> Was to redirect the events to the tool without need to call the
>> mpl_connect within the tool. So I provided the methods to handle those
>> events directly.
>> This is also from the idea that if we implement the
>> MultiFigureManager, when there is a change on the 'active_figure'
>> Navigation knows about the change and changes the event handlers, in
>> this case the Tools don't need to do anything.
>> It was just to simplify the Tool creation eliminating the need for
>> basic event connection in case of figure changes.
>>
>> Even if we remove the locks we need two locks:
>> canvaslock (for the input)
>> keypress lock, to give the tool the option to absorb the keypress
>> completely. (Tool for anotations comes to mind)
>>
>> I didn't remove the comment for the locks, because I am not sure what
>> is the best option.
>>
>>
>> ToolbarBase
>> I tried to clarify the use of the methods. Most of the methods that
>> you mentionned, are for internal use only but are mandatory for
>> backend implementation.
>> Also I updated the wiki with the "_" that was missing from the private methods.
>>
>> On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tca...@uc...> wrote:
>>> I left some comments on the wiki (in []).  Not sure what the best way
>>> to leave comments is.
>>>
>>> On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza
>>> <ari...@gm...> wrote:
>>>> Hello everybody
>>>>
>>>> I just added  "click_tool" to simulate a click programatically.
>>>> https://github.com/matplotlib/matplotlib/pull/2759
>>>>
>>>> Is there anything missing or that you want to change?
>>>> I'm saturated so I don't see anything anymore.
>>>>
>>>> I would like to have some input specially in the `ToolbarBase` class.
>>>> I am ready to start the implementation on the other backends, and this
>>>> is the "new class" that have to be implemented for all the backends.
>>>> `Navigation` is mostly copy paste from existing toolbar
>>>>
>>>> Thanks
>>>> Federico
>>>>
>>>> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote:
>>>>> Hi Federico,
>>>>>
>>>>> I just wanted to say that I've been a little busy lately, but your MEP is
>>>>> really shaping up - I really like the concepts that are being proposed and
>>>>> think it will make a huge difference to people who want to implement custom
>>>>> UIs.
>>>>>
>>>>> Keep up the great work, and continue trying to get feedback from all of us
>>>>> on this!
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>> On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote:
>>>>>>
>>>>>> Hello everybody
>>>>>>
>>>>>> I just added some documentation for the MEP22 new classes and methods.
>>>>>> Please take a look https://github.com/matplotlib/matplotlib/pull/2759
>>>>>>
>>>>>> I ran into some problems, when trying to decide if some methods where
>>>>>> public or not.
>>>>>>
>>>>>> If the method was used only for backend implementation pourposes I put
>>>>>> it as private (name starts with underscore) but still documented them
>>>>>> in the Notes section of the class.
>>>>>> I don't know if this is the correct way to do it, but I couldn't decide.
>>>>>> If you prefer any other way to do it, please let me know.
>>>>>>
>>>>>> Thank you
>>>>>> Federico
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>>>
>>>>>> -- Antonio Alducin --
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>>> Get a Quote or Start a Free Trial Today.
>>>>>>
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>>> _______________________________________________
>>>>>> Matplotlib-devel mailing list
>>>>>> Mat...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>
>>>> -- Antonio Alducin --
>>>>
>>>> ------------------------------------------------------------------------------
>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>> Critical Workloads, Development Environments & Everything In Between.
>>>> Get a Quote or Start a Free Trial Today.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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
>>
>>
>>
>> --
>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>
>> -- Antonio Alducin --
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --

Re: [matplotlib-devel] MEP22 doc

[Federico A. <ari...@gm...>]

Hello again

I have been playing with the locks to find a solution.
What we need is a way to let tools absorb the events (lock its use).

The problem that I'm facing is that Navigation itself needs to capture
two different events.

key_press_event for tool triggering
motion_notify_event for setting the message with the pointer position
and cursor changing.

Now the options that I see are:

Let the tools disconnect and reconnect this signals in navigation.
self.figure.canvas.mpl_disconnect(self.navigation.id_move)
....
self.navigation.id_move =
self.figure.canvas.mpl_connect('motion_notify_event',
self.navigation.mouse_move)

Create helper methods to disconnect and reconnect this signals in navigation
self.navigation.disconnect('mouse_move')
....
self.navigation.connect('mouse_move')

Use locks and let navigation redirect these events to the appropiate
place (what I'm doing right now).
self.navigation.movelock(self)
self.navigation.movelock.release(self)

Do you see other options?

One thing that is clear, is that for the moment Navigation needs only
two handlers, so I can reduce the number of locks to two....

Thanks
Federico

On Tue, Jan 28, 2014 at 11:05 AM, Federico Ariza
<ari...@gm...> wrote:
> @tacaswell I modified the wiki reflecting the changes and trying to
> answer the questions.
> Please let me know if I answered your questions/concerns. We can
> iterate as muchs as needed on this, I have no problem modifying the
> names or functionnality.
>
> Sorry for the long email
> Here a list of things that I changed
>
> ToolBase
> description = '': Small description of the tool
>
> persistent = False: If True, the instance of the Tool is registered
> with Navigation for reuse.
> This is needed because some tools are keept alive in the background,
> for example SubplotTool.
>
> position = None: Where is it positionned in the toolbar?. -1 = at the
> end, None = Not in the toolbar.
> The default tools are all ordered by their position in the Navigation
> _default_tools array. This argument is mainly used by User created
> tools that are added after the Toolbar creation.
> My idea was that for the user created tools, the user could set the
> position without having to subclass the Navigation class.
> So this information has to be included in the Tool.
>
>
> activate(self, event): This is the main method of the Tool, it is
> called when the Tool is triggered by:
>   * Toolbar button click
>   * keypress associated with the Tool Keymap
>   * Call to navigation.click_tool(name)
>
>
> ToolPersistentBase
> unregister(self, *args): ... Because ToolBase is intened for single
> use, there is no need of registration for the instances, persistent
> tools, need to be registered so __init__ is called only onece during
> the first trigger
>
>
> NavigationBase
> locks.... I tend to agree with you.
> The idea that I had in mind, and maybe was more complex than expected.
> Was to redirect the events to the tool without need to call the
> mpl_connect within the tool. So I provided the methods to handle those
> events directly.
> This is also from the idea that if we implement the
> MultiFigureManager, when there is a change on the 'active_figure'
> Navigation knows about the change and changes the event handlers, in
> this case the Tools don't need to do anything.
> It was just to simplify the Tool creation eliminating the need for
> basic event connection in case of figure changes.
>
> Even if we remove the locks we need two locks:
> canvaslock (for the input)
> keypress lock, to give the tool the option to absorb the keypress
> completely. (Tool for anotations comes to mind)
>
> I didn't remove the comment for the locks, because I am not sure what
> is the best option.
>
>
> ToolbarBase
> I tried to clarify the use of the methods. Most of the methods that
> you mentionned, are for internal use only but are mandatory for
> backend implementation.
> Also I updated the wiki with the "_" that was missing from the private methods.
>
> On Mon, Jan 27, 2014 at 9:12 PM, Thomas A Caswell <tca...@uc...> wrote:
>> I left some comments on the wiki (in []).  Not sure what the best way
>> to leave comments is.
>>
>> On Mon, Jan 27, 2014 at 5:04 PM, Federico Ariza
>> <ari...@gm...> wrote:
>>> Hello everybody
>>>
>>> I just added  "click_tool" to simulate a click programatically.
>>> https://github.com/matplotlib/matplotlib/pull/2759
>>>
>>> Is there anything missing or that you want to change?
>>> I'm saturated so I don't see anything anymore.
>>>
>>> I would like to have some input specially in the `ToolbarBase` class.
>>> I am ready to start the implementation on the other backends, and this
>>> is the "new class" that have to be implemented for all the backends.
>>> `Navigation` is mostly copy paste from existing toolbar
>>>
>>> Thanks
>>> Federico
>>>
>>> On Mon, Jan 27, 2014 at 11:07 AM, Phil Elson <pel...@gm...> wrote:
>>>> Hi Federico,
>>>>
>>>> I just wanted to say that I've been a little busy lately, but your MEP is
>>>> really shaping up - I really like the concepts that are being proposed and
>>>> think it will make a huge difference to people who want to implement custom
>>>> UIs.
>>>>
>>>> Keep up the great work, and continue trying to get feedback from all of us
>>>> on this!
>>>>
>>>> Thanks,
>>>>
>>>> Phil
>>>>
>>>>
>>>> On 24 January 2014 18:43, Federico Ariza <ari...@gm...> wrote:
>>>>>
>>>>> Hello everybody
>>>>>
>>>>> I just added some documentation for the MEP22 new classes and methods.
>>>>> Please take a look https://github.com/matplotlib/matplotlib/pull/2759
>>>>>
>>>>> I ran into some problems, when trying to decide if some methods where
>>>>> public or not.
>>>>>
>>>>> If the method was used only for backend implementation pourposes I put
>>>>> it as private (name starts with underscore) but still documented them
>>>>> in the Notes section of the class.
>>>>> I don't know if this is the correct way to do it, but I couldn't decide.
>>>>> If you prefer any other way to do it, please let me know.
>>>>>
>>>>> Thank you
>>>>> Federico
>>>>>
>>>>>
>>>>> --
>>>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>>>
>>>>> -- Antonio Alducin --
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>> Get a Quote or Start a Free Trial Today.
>>>>>
>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>> _______________________________________________
>>>>> Matplotlib-devel mailing list
>>>>> Mat...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>>>
>>> -- Antonio Alducin --
>>>
>>> ------------------------------------------------------------------------------
>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>> Critical Workloads, Development Environments & Everything In Between.
>>> Get a Quote or Start a Free Trial Today.
>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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
>
>
>
> --
> Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?
>
> -- Antonio Alducin --



-- 
Y yo que culpa tengo de que ellas se crean todo lo que yo les digo?

-- Antonio Alducin --