matplotlib-devel — matplotlib developers

[matplotlib-devel] gca() returns Axes

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

I have run into a problem related to tight_layout when building the 
docs, and the root of it seems to be that plt.gca() returns an Axes, not 
an AxesSubplot.  This seems odd, since it appears that it should be 
equivalent to plt.subplot(1,1,1) when there is no pre-existing axes.

Does anyone see any problem with ensuring that what plt.gca() returns in 
this case is an AxesSubplot instance?

Eric

Re: [matplotlib-devel] Two 1.2 milestones

[Michael D. <md...@st...>]

Ok.  That's a reasonable rationale. Let's keep it as it is for now.

Thanks for all of the bug triaging you've been doing this weekend!  
Looks like you've been drinking the right kind of coffee!

Mike

On 08/19/2012 05:43 PM, Phil Elson wrote:
> I made the "1.2.x known bugs" milestone. I wanted a way of drawing 
> attention to them, without bundling them in the 1.2.x milestone. The 
> main motivation for this was because there is nobody currently working 
> on them, yet they are confirmed bugs which, unless we address them, 
> will be known bugs in the release.
>
> I don't envisage the milestone to be a longterm thing, but I do think 
> its helpful to separate them from things we definitely want to resolve 
> before taking a 1.2.x cut. I would be happy even if we delete the 
> milestone first thing after the freeze tomorrow.
>
> Regards,
>
> Phil
>
>
>
> On 19 August 2012 18:54, Michael Droettboom <md...@st... 
> <mailto:md...@st...>> wrote:
>
>     On 08/19/2012 01:38 PM, Damon McDougall wrote:
>     > On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote:
>     >> There seems to be a new milestone "1.2.x known bugs".  Is there
>     a good
>     >> reason to have two milestones for 1.2?  As we enter into the freeze
>     >> phase for 1.2, it would be easier to just track a single milestone.
>     > According to mpl release calendar, the feature freeze is for
>     2.0, not
>     > 1.2.
>     >
>     > Is this correct, or am I missing something?
>     >
>     Thanks for pointing this out.  There was some disagreement/discussion
>     about what to call the next release.  In the end, it was decided
>     to call
>     it 1.2.There was a 2.0 milestone for a while, and all of those were
>     moved to 1.2.   I'll update the calendar.
>
>     Mike
>
>     ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond.
>     Discussions
>     will include endpoint security, mobile security and the latest in
>     malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Matplotlib-devel mailing list
>     Mat...@li...
>     <mailto:Mat...@li...>
>     https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>

Re: [matplotlib-devel] Two 1.2 milestones

[Phil E. <pel...@gm...>]

I made the "1.2.x known bugs" milestone. I wanted a way of drawing
attention to them, without bundling them in the 1.2.x milestone. The main
motivation for this was because there is nobody currently working on them,
yet they are confirmed bugs which, unless we address them, will be known
bugs in the release.

I don't envisage the milestone to be a longterm thing, but I do think its
helpful to separate them from things we definitely want to resolve before
taking a 1.2.x cut. I would be happy even if we delete the milestone first
thing after the freeze tomorrow.

Regards,

Phil



On 19 August 2012 18:54, Michael Droettboom <md...@st...> wrote:

> On 08/19/2012 01:38 PM, Damon McDougall wrote:
> > On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote:
> >> There seems to be a new milestone "1.2.x known bugs".  Is there a good
> >> reason to have two milestones for 1.2?  As we enter into the freeze
> >> phase for 1.2, it would be easier to just track a single milestone.
> > According to mpl release calendar, the feature freeze is for 2.0, not
> > 1.2.
> >
> > Is this correct, or am I missing something?
> >
> Thanks for pointing this out.  There was some disagreement/discussion
> about what to call the next release.  In the end, it was decided to call
> it 1.2.There was a 2.0 milestone for a while, and all of those were
> moved to 1.2.   I'll update the calendar.
>
> Mike
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] Two 1.2 milestones

[Michael D. <md...@st...>]

On 08/19/2012 01:38 PM, Damon McDougall wrote:
> On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote:
>> There seems to be a new milestone "1.2.x known bugs".  Is there a good
>> reason to have two milestones for 1.2?  As we enter into the freeze
>> phase for 1.2, it would be easier to just track a single milestone.
> According to mpl release calendar, the feature freeze is for 2.0, not
> 1.2.
>
> Is this correct, or am I missing something?
>
Thanks for pointing this out.  There was some disagreement/discussion 
about what to call the next release.  In the end, it was decided to call 
it 1.2.There was a 2.0 milestone for a while, and all of those were 
moved to 1.2.   I'll update the calendar.

Mike

[matplotlib-devel] 1.2 Feature freeze plans for tomorrow

[Michael D. <md...@st...>]

There has been a lot of great work triaging and fixing bugs lately. This 
release is going to see more new features and bugfixes than we've seen 
in matplotlib in a long time.  Thanks to everyone!

Here's my plan for tomorrow's feature freeze:

Let's try to get a handle on the PRs we have for 1.2.  Please mark any 
features that are very near completion or critical bugs you're aware of 
with the 1.2 milestone.  (A lot of this work has already been done, but 
if you have a pet bug, make sure it comes to our attention).

Then we'll try to get as many of these merged as possible on to master.  
I'm not terribly concerned about getting them all done tomorrow if 
there's still some final cleanup to do first.  The critical thing is to 
hold off on merging "new" stuff onto master during the freeze.

Once we've whittled it down to a small number of things, I'll create a 
1.2.x branch off of master, and new work can once again go on on 
master.  That may not happen tomorrow, but hopefully early this week.

Any issues with that approach, or additional thoughts?

Mike

Re: [matplotlib-devel] Two 1.2 milestones

[Damon M. <dam...@gm...>]

On Sun, Aug 19, 2012 at 12:58:53PM -0400, Michael Droettboom wrote:
> There seems to be a new milestone "1.2.x known bugs".  Is there a good 
> reason to have two milestones for 1.2?  As we enter into the freeze 
> phase for 1.2, it would be easier to just track a single milestone.

According to mpl release calendar, the feature freeze is for 2.0, not
1.2.

Is this correct, or am I missing something?

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] Two 1.2 milestones

[Michael D. <md...@st...>]

There seems to be a new milestone "1.2.x known bugs".  Is there a good 
reason to have two milestones for 1.2?  As we enter into the freeze 
phase for 1.2, it would be easier to just track a single milestone.

Mike

Re: [matplotlib-devel] python3 release

[Mark L. <bre...@ya...>]

On 20/07/2012 20:21, John Hunter wrote:
> I would like to discuss a timetable towards a python3 release (1.2 or 2.0).
>   I'll throw this out there, and am happy to make modifications according to
> feedback
>
> Aug 20th : feature freeze and branch.  bugfixes only going forward from
> this point
>
> Sept 15th: rc1
>
> Oct 7th: rc2
>
> Oct 15th release
>
> I know we have lots of open and interesting pull requests to get in, and so
> if we need to push these times back to get them in that is fine.  Just
> wanted to put something out there to see if this timeline seems plausible
> to people.
>
> JDH
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

For the record my offer to help with testing on Windows is still open. 
Don't all rush :)

-- 
Cheers.

Mark Lawrence.

[matplotlib-devel] MEP10: Modernizing the documentation

[Michael D. <md...@st...>]

Working with the documentation this past week has me a little frustrated 
with the state of it.  Enough to write a MEP.

https://github.com/matplotlib/matplotlib/wiki/Mep10

In particular, it would be nice to compile a list of concerns about the 
docstrings and documentation layout so that we can address as much as 
possible in a single pass.  Also, let me know if there are any relevant 
PRs and Issues.

In particular, I think PR #1032, as it is a large structural 
reorganization, my dovetail well with the proposed reorganization of the 
docs.

Mike

Re: [matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

OK, I have a sample code for people to run if they want to.  I've dumped
all of the interactive manager code and some sample usage (of the mix-in
way of doing it) in the following branch:

https://github.com/dhyams/matplotlib/tree/MEP9

in the directory

examples/user_interfaces/imanager.py

Just run that script, and it should give a little demo plot.  I do
apologize and disclaim all messiness in the code...it's not the prettiest
thing anyway, and I cobbled it together very quickly so that you could see
what it does.  Sort of a straw man to beat on, I guess.


On Fri, Aug 17, 2012 at 3:38 PM, Daniel Hyams <dh...@gm...> wrote:

>
>
> On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing <ef...@ha...> wrote:
>
>> On 2012/08/17 8:45 AM, Daniel Hyams wrote:
>> > I was planning to just create my own branch to start putting code in,
>> > but would it be better for an admin to create a branch off of master in
>> > the main matplotlib repo (say MEP9)?  Then whoever wants to help out
>> > with MEP9 can branch from that and issue pull requests against it?
>>
>> People can already do that by forking your repo (which you forked from
>> master), and issuing pull requests against your MEP9 branch within it.
>> The difference is that in the latter case, you are the only one who can
>> merge a pull request.  I think this will have some advantages, including
>> giving you more freedom to do things like rebase and force-push, which
>> we would not want to do in the main repo.
>>
>> Eric
>
>
>
> OK, thanks Eric.  I'll try my best not to let my git-ignorance "git" in
> the way too much ;)
>
>


-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing <ef...@ha...> wrote:

> On 2012/08/17 8:45 AM, Daniel Hyams wrote:
> > I was planning to just create my own branch to start putting code in,
> > but would it be better for an admin to create a branch off of master in
> > the main matplotlib repo (say MEP9)?  Then whoever wants to help out
> > with MEP9 can branch from that and issue pull requests against it?
>
> People can already do that by forking your repo (which you forked from
> master), and issuing pull requests against your MEP9 branch within it.
> The difference is that in the latter case, you are the only one who can
> merge a pull request.  I think this will have some advantages, including
> giving you more freedom to do things like rebase and force-push, which
> we would not want to do in the main repo.
>
> Eric



OK, thanks Eric.  I'll try my best not to let my git-ignorance "git" in the
way too much ;)

Re: [matplotlib-devel] MEP9: interactivity

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

On 2012/08/17 8:45 AM, Daniel Hyams wrote:
> I was planning to just create my own branch to start putting code in,
> but would it be better for an admin to create a branch off of master in
> the main matplotlib repo (say MEP9)?  Then whoever wants to help out
> with MEP9 can branch from that and issue pull requests against it?

People can already do that by forking your repo (which you forked from 
master), and issuing pull requests against your MEP9 branch within it. 
The difference is that in the latter case, you are the only one who can 
merge a pull request.  I think this will have some advantages, including 
giving you more freedom to do things like rebase and force-push, which 
we would not want to do in the main repo.

Eric


>
> On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams <dh...@gm...
> <mailto:dh...@gm...>> wrote:
>
>
>
>     On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <md...@st...
>     <mailto:md...@st...>> wrote:
>
>         Here's my initial thoughts:
>
>         There are a few examples in the event_handling that are going to
>         be much simplified by this new infrastructure.  They should be
>         updated to point people in the direction of this
>         new/better/easier way.
>
>         How do the *select* methods relate to the existing pick
>         functionality?  Does it replace or complement?  Are there any
>         inconsistencies in usage between the two?
>
>
>     I think that in most use cases that I can think of, a user would
>     want to either use the picking mechanism, which fires an event, or
>     go "whole hog" and use the interactive manager.  Not both....if I
>     remember correctly, I do call set_picker() in the interactive
>     manager, so that I can set a reasonable tolerance around the artist
>     for containment purposes...otherwise it's too hard to point exactly
>     at a line, for example.  So there is some potential for interference
>     there that would need to be looked after in the new code.
>
>     As an aside, all of the on_* methods really encourage the user to
>     use matplotlib in object oriented way, which I really like, but
>     probably most people won't.  As a bridge for the functional-style
>     users of mpl, we could just implement all of the on_* methods in the
>     artist.Artist class by default by having them fire an event.  Then
>     if someone overrides the method, fine, but if they don't, there is
>     an event fired.
>
>
>         Other than that, I'm not seeing any obvious issues with the MEP.
>         I'd love to see the code when it's ready.
>
>
>     I'll probably have an example code, still in its mix-in form, in a
>     branch for you to look at soon.  This way, the discussion can turn
>     more concrete.  The example code will also be a runnable sample so
>     that you can play with the interactivity.
>
>
>
>
> --
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>

Re: [matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

I was planning to just create my own branch to start putting code in, but
would it be better for an admin to create a branch off of master in the
main matplotlib repo (say MEP9)?  Then whoever wants to help out with MEP9
can branch from that and issue pull requests against it?

On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams <dh...@gm...> wrote:

>
>
> On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <md...@st...>wrote:
>
>>  Here's my initial thoughts:
>>
>> There are a few examples in the event_handling that are going to be much
>> simplified by this new infrastructure.  They should be updated to point
>> people in the direction of this new/better/easier way.
>>
>> How do the *select* methods relate to the existing pick functionality?
>> Does it replace or complement?  Are there any inconsistencies in usage
>> between the two?
>>
>
> I think that in most use cases that I can think of, a user would want to
> either use the picking mechanism, which fires an event, or go "whole hog"
> and use the interactive manager.  Not both....if I remember correctly, I do
> call set_picker() in the interactive manager, so that I can set a
> reasonable tolerance around the artist for containment purposes...otherwise
> it's too hard to point exactly at a line, for example.  So there is some
> potential for interference there that would need to be looked after in the
> new code.
>
> As an aside, all of the on_* methods really encourage the user to use
> matplotlib in object oriented way, which I really like, but probably most
> people won't.  As a bridge for the functional-style users of mpl, we could
> just implement all of the on_* methods in the artist.Artist class by
> default by having them fire an event.  Then if someone overrides the
> method, fine, but if they don't, there is an event fired.
>
>
>> Other than that, I'm not seeing any obvious issues with the MEP.  I'd
>> love to see the code when it's ready.
>>
>
> I'll probably have an example code, still in its mix-in form, in a branch
> for you to look at soon.  This way, the discussion can turn more concrete.
>  The example code will also be a runnable sample so that you can play with
> the interactivity.
>
>



-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <md...@st...> wrote:

>  Here's my initial thoughts:
>
> There are a few examples in the event_handling that are going to be much
> simplified by this new infrastructure.  They should be updated to point
> people in the direction of this new/better/easier way.
>
> How do the *select* methods relate to the existing pick functionality?
> Does it replace or complement?  Are there any inconsistencies in usage
> between the two?
>

I think that in most use cases that I can think of, a user would want to
either use the picking mechanism, which fires an event, or go "whole hog"
and use the interactive manager.  Not both....if I remember correctly, I do
call set_picker() in the interactive manager, so that I can set a
reasonable tolerance around the artist for containment purposes...otherwise
it's too hard to point exactly at a line, for example.  So there is some
potential for interference there that would need to be looked after in the
new code.

As an aside, all of the on_* methods really encourage the user to use
matplotlib in object oriented way, which I really like, but probably most
people won't.  As a bridge for the functional-style users of mpl, we could
just implement all of the on_* methods in the artist.Artist class by
default by having them fire an event.  Then if someone overrides the
method, fine, but if they don't, there is an event fired.


> Other than that, I'm not seeing any obvious issues with the MEP.  I'd love
> to see the code when it's ready.
>

I'll probably have an example code, still in its mix-in form, in a branch
for you to look at soon.  This way, the discussion can turn more concrete.
 The example code will also be a runnable sample so that you can play with
the interactivity.

Re: [matplotlib-devel] MEP9: interactivity

[Michael D. <md...@st...>]

Here's my initial thoughts:

There are a few examples in the event_handling that are going to be much 
simplified by this new infrastructure.  They should be updated to point 
people in the direction of this new/better/easier way.

How do the *select* methods relate to the existing pick functionality?  
Does it replace or complement?  Are there any inconsistencies in usage 
between the two?

Other than that, I'm not seeing any obvious issues with the MEP. I'd 
love to see the code when it's ready.

Mike

On 08/15/2012 02:10 PM, Daniel Hyams wrote:
> I'm not sure where to say that I just posted up a new MEP, but here it is:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP9
>
>
> and I suppose we discuss it here...
>
> -- 
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

On Fri, Aug 17, 2012 at 10:52 AM, Drain, Theodore R (343P) <
the...@jp...> wrote:

>  OK - I'll start the ball rolling...
>
>
>
> One feature that would be nice to have is positioning options that are not
> pixel based.  See the annotate function for some possibilities:
>

Note that the get_pixel_position_ll() and such functions (in the MEP9
proposal) are only for internal use by the interactive manager.  Items can
still be placed by the script wherever necessary, and if the position (in
one or multiple transformations) is necessary, one can record that in the
on_select_end callback for that artist.

In fact, one of the things that must be done in the set_position_and_size()
call (every artist will have to do this) is to set that artist's
appropriate parameters for its position and size, based on its current
transformation, that fits it within the bounding box that the user just
finished moving and dragging around.  Sorry, I know that's hard to see
without some straw-man code that I intend to post soon...I was a little
ashamed to post it in its current state ;)

Re: [matplotlib-devel] MEP9: interactivity

[Drain, T. R (343P) <the...@jp...>]

OK - I'll start the ball rolling...



One feature that would be nice to have is positioning options that are not pixel based.  See the annotate function for some possibilities:



http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate



I'm not sure if all of these options are practical for a general artist but they do come in handy.  Being able to position something as a percentage of the figure or an axes is a really nice feature when making nice looking plots.  This is especially true for text.  We implemented something for dragging annotations around and saving the results (in a custom xml file) that kept the initial method the user used (%, data, pixel) with the updated location.  We didn't implement a resizing capability but that would have been great to have for each axes object in the figure.



FYI the app we made used MPL and basemap to display the landing uncertainties and hazard probabilities for the Mars Curiosity rover on the Martian surface (very cool stuff). There was a lot of data and labels on the graphs and the navigation team needed to quickly make presentation grade images that people could easily read.  Being able to drag the annotations, legend, etc around was huge and since data was updated every day, being able to save the drag and drop locations and restore them from the xml file with new data the next day made things a lot faster.



Ted



________________________________
From: Daniel Hyams [dh...@gm...]
Sent: Wednesday, August 15, 2012 11:10 AM
To: mat...@li...
Subject: [matplotlib-devel] MEP9: interactivity

I'm not sure where to say that I just posted up a new MEP, but here it is:

https://github.com/matplotlib/matplotlib/wiki/MEP9


and I suppose we discuss it here...

--
Daniel Hyams
dh...@gm...<mailto:dh...@gm...>

Re: [matplotlib-devel] MEP9: interactivity

[Michael D. <md...@st...>]

Thanks for this.  The first "real" MEP!

My view is that we can discuss this here, and then you would be 
ultimately responsible for updating the MEP based on feedback -- but 
this is a new process, we can be as flexible as we want.

I've read it through once and think it's a very valuable idea in 
general.  I'll send my comments once I've had time to further digest it.

Cheers,
Mike

On 08/15/2012 02:10 PM, Daniel Hyams wrote:
> I'm not sure where to say that I just posted up a new MEP, but here it is:
>
> https://github.com/matplotlib/matplotlib/wiki/MEP9
>
>
> and I suppose we discuss it here...
>
> -- 
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Re: [matplotlib-devel] Q-Q Plot

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

Damon,

When the current state of the relevant python libraries, scipy is
required to create a QQ plot. Therefore, matplotib will never be able
to natively make QQ or probability plots. I've got a PR into the the
statsmodels project to do just what you need (and more!).
https://github.com/statsmodels/statsmodels/pull/412

It'll probably be a while before I get that PR up to par with the rest
of statsmodels, so in the meantime, I suggest you use the existing
functionality in statsmodels or roll your own.

Good luck,
-paul

On Wed, Aug 15, 2012 at 4:02 PM, Damon McDougall
<dam...@gm...> wrote:
> Hi all,
>
> If anyone hasn't noticed already. I've been somewhat semi-perusing the
> Matlab interface and trying to port over any plotting functionality not
> current present in mpl.
>
> The other day I made a bit of a mess up regarding functionality I didn't
> think existed but actually did (discussion here:
> https://github.com/matplotlib/matplotlib/pull/1068)
>
> I'm sending a message here because I've found another one I don't think
> currently exists in mpl:
> http://www.mathworks.co.uk/help/toolbox/stats/qqplot.html
>
> I wanted to check with everyone here (who probably know better!) before
> I started anything.
>
> Thanks!
> Damon
>
> --
> Damon McDougall
> http://www.damon-is-a-geek.com
> B2.39
> Mathematics Institute
> University of Warwick
> Coventry
> West Midlands
> CV4 7AL
> United Kingdom
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

[matplotlib-devel] Q-Q Plot

[Damon M. <dam...@gm...>]

Hi all,

If anyone hasn't noticed already. I've been somewhat semi-perusing the
Matlab interface and trying to port over any plotting functionality not
current present in mpl.

The other day I made a bit of a mess up regarding functionality I didn't
think existed but actually did (discussion here:
https://github.com/matplotlib/matplotlib/pull/1068)

I'm sending a message here because I've found another one I don't think
currently exists in mpl:
http://www.mathworks.co.uk/help/toolbox/stats/qqplot.html

I wanted to check with everyone here (who probably know better!) before
I started anything.

Thanks!
Damon

-- 
Damon McDougall
http://www.damon-is-a-geek.com
B2.39
Mathematics Institute
University of Warwick
Coventry
West Midlands
CV4 7AL
United Kingdom

[matplotlib-devel] MEP9: interactivity

[Daniel H. <dh...@gm...>]

I'm not sure where to say that I just posted up a new MEP, but here it is:

https://github.com/matplotlib/matplotlib/wiki/MEP9


and I suppose we discuss it here...

-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] How to properly use git to implement a feature

[Daniel H. <dh...@gm...>]

Thanks Eric; this is what I was looking for, and it's a shame that there
seems to be no way to accomplish this without cherrypicking a commit or
range of commits.  It seems that since v1.1.1 and master can be traced back
to some common ancestry, that git should be able to rewind and replay the
changes so that cherrypicking or reimplementing wouldn't be necessary.
 I've archived this email, though, so that I can use it at the appropriate
time.

For the immediate need, I was going to add the keyword 'bbox_size' to
Annotations, so that the user can optionally specify the box size around an
annotation...also was going to add additional boxstyles for Annotations, so
that one could use a circle, ellipse, or any other type of patch to enclose
the annotation.  This would be useful for flowcharting and any other use
where  the user wants a "patch with text inside".

As it stands, though I can only get 95% of this done...I can't seem to get
the placement of the patch correct when the text is rotated, unless
ha='center' and va='center', or if rotation_mode='anchor'.   So since I
would cause a regression here, I guess it's off the table.

On Sun, Aug 12, 2012 at 11:23 PM, Eric Firing <ef...@ha...> wrote:

> On 2012/08/12 3:34 PM, Daniel Hyams wrote:
> >
> > I was wanting to add a feature to matplotlib...one that I would use in
> > my application.  I also want to contribute the feature back. I'm
> > personally using version 1.1.1 of matplotlib.  Disclaimer...I only know
> > enough about git to be dangerous.
> >
> > So is it best to branch from v1.1.1, implement the feature, and then try
> > to rebase to master?  Or is it best to branch from master, implement the
> > feature, and then (somehow) backport the patch to the v1.1.1 tagged
> version?
>
> Mike answered for the case where you are making a bugfix that really
> does go in v1.1.x.  I think that even there, what he is recommending is
> a bit different from what you have in mind: he is saying to branch from
> an up-to-date v1.1.x, not from v1.1.1.  Similarly, for the case you have
> in mind, the pull request should be for a change relative to a recent
> enough point on the master branch that it can be merged cleanly, and
> with no unexpected side-effects.
>
> It sounds like what you are trying to do is maintain your own branch off
> of the v1.1.1 tagged version, with only your own features added.
>
> I don't think there is any single best way to do this; it depends on how
> you work, and on what sorts of changes you are making.
>
> Developing your change in your feature branch off of v1.1.1 is perfectly
> reasonable, since that is where you are normally working, and that is
> where you need it to work.  To propagate it upstream, you do need to
> either cherry-pick it, or reimplement it, relative to recent master.
> Re-implementing it can be simpler in some cases--easier to see what is
> going on!
>
> I had been thinking "rebase", but this is not correct; you don't want to
> *remove* your commits from your branch off of v1.1.1, you want to
> *reproduce* them, or their net effect, in a *new* topic branch off of
> up-to-date master.
>
> It would go something like this.  Assume "upstream" is the remote
> pointing to the main mpl repo, and "origin" is your github repo.  Assume
> your changes are in a topic branch called "dh_topic_stable", off of
> v1.1.1.  Find the commit numbers in dh_topic_stable that you need to
> propagate, say "a0b123fed" and "df237abc".
>
> git fetch upstream
> git checkout -b dh_topic upstream/master
> git cherry-pick a0b123fed df237abc
> # build and test; maybe add documentation and test commits
> git push origin dh_topic
>
> Then make your pull request against mpl master.
>
> For seeing what is in a repo, and what happens at each step of the way,
> I find qgit helpful.  Invoke as "qgit --all".  You need to hit the
> refresh button after each command-line git call.
>
> Eric
>
>
> >
> > Whatever the best choice is, what would the procedure look like to
> > accomplish this?
> >
> > --
> > Daniel Hyams
> > dh...@gm... <mailto:dh...@gm...>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> >
> >
> >
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> >
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>



-- 
Daniel Hyams
dh...@gm...

Re: [matplotlib-devel] Stacked plotting in matplotlib

[Nic E. <ns...@co...>]

Oops, sorry. I realized it was actually Ben Root who suggested I start this
discussion. Don't want to put words in anyones mouth.

Nic

On Sun, Aug 12, 2012 at 11:51 PM, Nic Eggert <ns...@co...> wrote:

> Hi all,
>
> I'd like to bring up a question spurred by PRs #847(mine) and #819
> (recently accepted). These PRs both deal with stacked plots. #819 adds the
> stackplot function to axes.py as a new function, which plots different 2-d
> datasets stacked atop each other. #847 slightly modifies the functioning of
> `hist` in axes.py by adding a new kwarg which allows datasets to be
> stacked. Currently this is only possible using the `barstacked` histtype.
> #847 makes it also work with the `step` and `stepfilled` histtypes.
>
> One of the issues that has been raised in the comments of #847 is whether
> we want to take this opportunity to come up with a unified way to handle
> "stacked-ness". Michael Droettboom suggested I raise this issue on this
> list. So far, there are 3 different approaches:
>
> 1. The state before #819. AFAIK the only way to do any sort of stacking
> was to call `hist` with `histtype="barstacked"`. This treats stacked
> histograms as a different type of histogram than non-stacked histograms.
> One of my motivations for writing #847 was to get stacked step and
> stepfilled histograms, which would require adding several new histtypes
> (stepstacked and stepfilledstacked). It seems to me that histtype mostly
> controls the style of the histogram plotted, and shouldn't have anything to
> do with "stacked-ness", so I think this is kind of clunky.
>
> 2. The approach I take in #847. Add a new kwarg which controls whether or
> not multiple datasets are stacked. I think this is the cleanest
> implementation, although that's probably obvious because it's how I wrote
> my PR. To keep everything consistent in this approach, we should remove the
> stackplot function added in #819, and move that functionality to the `plot`
> function, adding a `stacked` kwarg there.
>
> 3. The approach of #819. With this approach, we would add a separate
> function to handle stacked versions of different plots. I'd re-write #847
> as a new function called `stackhist`. This approach, IMO, doesn't scale
> well if we want to add "stacked-ness" to more plot types in the future.
>
> Please take a look at this and send comments about these proposals or any
> others you might have. I hope the community can come to a consensus which
> unifies the handling of stacked-ness.
>
> Whatever we end up choosing, I think adding a stacked step histogram will
> make it much easier to promote the use of mpl in high energy physics, where
> we use this style of plot frequently.
>
> Thanks,
>
> Nic Eggert
> Graduate Fellow
> Cornell University
>

[matplotlib-devel] Stacked plotting in matplotlib

[Nic E. <ns...@co...>]

Hi all,

I'd like to bring up a question spurred by PRs #847(mine) and #819
(recently accepted). These PRs both deal with stacked plots. #819 adds the
stackplot function to axes.py as a new function, which plots different 2-d
datasets stacked atop each other. #847 slightly modifies the functioning of
`hist` in axes.py by adding a new kwarg which allows datasets to be
stacked. Currently this is only possible using the `barstacked` histtype.
#847 makes it also work with the `step` and `stepfilled` histtypes.

One of the issues that has been raised in the comments of #847 is whether
we want to take this opportunity to come up with a unified way to handle
"stacked-ness". Michael Droettboom suggested I raise this issue on this
list. So far, there are 3 different approaches:

1. The state before #819. AFAIK the only way to do any sort of stacking was
to call `hist` with `histtype="barstacked"`. This treats stacked histograms
as a different type of histogram than non-stacked histograms. One of my
motivations for writing #847 was to get stacked step and stepfilled
histograms, which would require adding several new histtypes (stepstacked
and stepfilledstacked). It seems to me that histtype mostly controls the
style of the histogram plotted, and shouldn't have anything to do with
"stacked-ness", so I think this is kind of clunky.

2. The approach I take in #847. Add a new kwarg which controls whether or
not multiple datasets are stacked. I think this is the cleanest
implementation, although that's probably obvious because it's how I wrote
my PR. To keep everything consistent in this approach, we should remove the
stackplot function added in #819, and move that functionality to the `plot`
function, adding a `stacked` kwarg there.

3. The approach of #819. With this approach, we would add a separate
function to handle stacked versions of different plots. I'd re-write #847
as a new function called `stackhist`. This approach, IMO, doesn't scale
well if we want to add "stacked-ness" to more plot types in the future.

Please take a look at this and send comments about these proposals or any
others you might have. I hope the community can come to a consensus which
unifies the handling of stacked-ness.

Whatever we end up choosing, I think adding a stacked step histogram will
make it much easier to promote the use of mpl in high energy physics, where
we use this style of plot frequently.

Thanks,

Nic Eggert
Graduate Fellow
Cornell University

Re: [matplotlib-devel] How to properly use git to implement a feature

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

On 2012/08/12 3:34 PM, Daniel Hyams wrote:
>
> I was wanting to add a feature to matplotlib...one that I would use in
> my application.  I also want to contribute the feature back. I'm
> personally using version 1.1.1 of matplotlib.  Disclaimer...I only know
> enough about git to be dangerous.
>
> So is it best to branch from v1.1.1, implement the feature, and then try
> to rebase to master?  Or is it best to branch from master, implement the
> feature, and then (somehow) backport the patch to the v1.1.1 tagged version?

Mike answered for the case where you are making a bugfix that really 
does go in v1.1.x.  I think that even there, what he is recommending is 
a bit different from what you have in mind: he is saying to branch from 
an up-to-date v1.1.x, not from v1.1.1.  Similarly, for the case you have 
in mind, the pull request should be for a change relative to a recent 
enough point on the master branch that it can be merged cleanly, and 
with no unexpected side-effects.

It sounds like what you are trying to do is maintain your own branch off 
of the v1.1.1 tagged version, with only your own features added.

I don't think there is any single best way to do this; it depends on how 
you work, and on what sorts of changes you are making.

Developing your change in your feature branch off of v1.1.1 is perfectly 
reasonable, since that is where you are normally working, and that is 
where you need it to work.  To propagate it upstream, you do need to 
either cherry-pick it, or reimplement it, relative to recent master. 
Re-implementing it can be simpler in some cases--easier to see what is 
going on!

I had been thinking "rebase", but this is not correct; you don't want to 
*remove* your commits from your branch off of v1.1.1, you want to 
*reproduce* them, or their net effect, in a *new* topic branch off of 
up-to-date master.

It would go something like this.  Assume "upstream" is the remote 
pointing to the main mpl repo, and "origin" is your github repo.  Assume 
your changes are in a topic branch called "dh_topic_stable", off of 
v1.1.1.  Find the commit numbers in dh_topic_stable that you need to 
propagate, say "a0b123fed" and "df237abc".

git fetch upstream
git checkout -b dh_topic upstream/master
git cherry-pick a0b123fed df237abc
# build and test; maybe add documentation and test commits
git push origin dh_topic

Then make your pull request against mpl master.

For seeing what is in a repo, and what happens at each step of the way, 
I find qgit helpful.  Invoke as "qgit --all".  You need to hit the 
refresh button after each command-line git call.

Eric


>
> Whatever the best choice is, what would the procedure look like to
> accomplish this?
>
> --
> Daniel Hyams
> dh...@gm... <mailto:dh...@gm...>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>