From tcaswell at gmail.com Mon Feb 4 15:01:16 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 4 Feb 2019 15:01:16 -0500 Subject: [Matplotlib-devel] Release and branching plans for {2.2.4, 3.0.3, 3.1.0} Message-ID: Folks, First an apology, this should have gone out last week. Paul Ivanov has agreed to co-manage this release cycle with me. The rough plan is to do the bug fix releases at the end of this week (aiming for Feb 11 to have 2.2.4 and 3.0.3 released and available on pypi). I don't think we need to do RCs for these. At the same time as we tag 3.0.3 we will delete the 3.0.x and the 3.0.2-doc branch, create the 3.0.2-doc branch, and fork a 3.1.x branch off of master. This will be feature-freeze for 3.1 and we will then use the back-port bot to move any remaining PR- for 3.1 to the 3.1.x branch. I propose we aim for an RC1 sometime between Feb 18 and Feb 25 and a final release March 4. Similarly when we tag 2.2.4 we will delete the 2.2.3-doc branch and create 2.2.4-doc (again, conserving the number of active branches we have). If you have the power to add labels / milestones please mark things that you think must go in for 3.1 as release critical and re-milestone things you don't think will be done is the next few weeks as 3.2 (or needs-sorting). So in summary: Feb 11: release 2.2.4, 3.0.3 Feb 18: 3.1.0rc1 Mar 4: 3.1.0 Branches to be removed from matplotlib/matplotlib - v3.0.x - v3.0.2-doc - v2.2.3-doc Branches to be added: - v3.1.x - v3.0.3-doc (we need this at least temporarily to put the DOI on after we tag) - v3.1.0-doc - v2.2.4-doc Milestones to be closed: - v2.2.4 - v3.1.0 - v3.0.3 - v3.0.2-doc Milestones to be added: - v2.2.5 - v3.1.1 - v3.1-doc Milestones to have their backport-targets changed: - v2.2-doc Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Feb 4 15:06:51 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 4 Feb 2019 15:06:51 -0500 Subject: [Matplotlib-devel] Summer stundents In-Reply-To: References: Message-ID: Following up on this (and ccing the user list), Is anyone available and interested in helping to mentor summer students? Tom On Mon, Jan 21, 2019 at 4:22 PM Thomas Caswell wrote: > Folks, > > On this weeks call we discussed if we want to take summer students this > year (either through GSOC or running the JDH summer fellowship again). Is > anyone able and interested in mentoring this summer? > > Notes from the call: > https://paper.dropbox.com/doc/Matplotlib-meeting-agenda--AWH9pSDlOSvrxXBVPR8mLuxUAg-aAmENlkgepgsMeDZtlsYu#:h2=GSOC-&-JDH > > Tom > > -- > Thomas Caswell > tcaswell at gmail.com > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dummy585 at gmail.com Mon Feb 4 16:49:00 2019 From: dummy585 at gmail.com (joe manix) Date: Mon, 4 Feb 2019 22:49:00 +0100 Subject: [Matplotlib-devel] feature request : new rc parameters in matplotlibrc In-Reply-To: References: Message-ID: Hi there, I'm new to matplotlib, come from the ROOT world (https://root.cern.ch) and miss the following rc parameters : - legend.fontfamily - legend.fontstyle - legend.fontweight only legend.fontsize is implemented - axes.xlabelpad (or axes.xlabel.pad) - axes.ylabelpad (or axes.ylabel.pad) only a generic axes.labelpad exists Could you please add these new rc parameters to matplotlibrc? Cheers, Z -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi at berkeley.edu Tue Feb 5 17:28:34 2019 From: pi at berkeley.edu (Paul Ivanov) Date: Tue, 5 Feb 2019 14:28:34 -0800 Subject: [Matplotlib-devel] SciPy 2019 Conference - 10 days left for submissions, registration now open Message-ID: SciPy 2019, the 18th annual Scientific Computing with Python conference, will be held July 8-14, 2019 in Austin, Texas. The annual SciPy Conference brings together over 800 participants from industry, academia, and government to showcase their latest projects, learn from skilled users and developers, and collaborate on code development. The call for abstracts for SciPy 2019 for talks, posters and tutorials is now open. The original deadline for submissions has been extended and the new deadline is February 15, 2019. Conference Website: https://www.scipy2019.scipy.org/ Submission Website: https://easychair.org/conferences/?conf=scipy2019 *Talks and Posters (July 10-12, 2019)* In addition to the general track, this year will have specialized tracks focused on: - Data Driven Discoveries (including Machine Learning and Data Science) - Open Source Communities (Sustainability) *Mini Symposia* - Science Communication through Visualization - Neuroscience and Cognitive Science - Image Processing - Earth, Ocean, Geo and Atmospheric Science There will also be a SciPy Tools Plenary Session each day with 2 to 5 minute updates on tools and libraries. *Tutorials (July 8-9, 2019)* Tutorials should be focused on covering a well-defined topic in a hands-on manner. We are looking for useful techniques or packages, helping new or advanced Python programmers develop better or faster scientific applications. We encourage submissions to be designed to allow at least 50% of the time for hands-on exercises even if this means the subject matter needs to be limited. Tutorials will be 4 hours in duration. In your tutorial application, you can indicate what prerequisite skills and knowledge will be needed for your tutorial, and the approximate expected level of knowledge of your students (i.e., beginner, intermediate, advanced). Instructors of accepted tutorials will receive a stipend. -- _ / \ A* \^ - ,./ _.`\\ / \ / ,--.S \/ \ / `"~,_ \ \ __o ? _ \<,_ /:\ --(_)/-(_)----.../ | \ --------------.......J Paul Ivanov http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dstansby at gmail.com Tue Feb 5 17:52:15 2019 From: dstansby at gmail.com (David Stansby) Date: Tue, 5 Feb 2019 22:52:15 +0000 Subject: [Matplotlib-devel] Release and branching plans for {2.2.4, 3.0.3, 3.1.0} In-Reply-To: References: Message-ID: Sounds good to me! Thanks as always Tom for organisiing all this. David On Mon, 4 Feb 2019 at 20:01, Thomas Caswell wrote: > Folks, > > First an apology, this should have gone out last week. > > Paul Ivanov has agreed to co-manage this release cycle with me. > > The rough plan is to do the bug fix releases at the end of this week > (aiming for Feb 11 to have 2.2.4 and 3.0.3 released and available on > pypi). I don't think we need to do RCs for these. > > At the same time as we tag 3.0.3 we will delete the 3.0.x and the > 3.0.2-doc branch, create the 3.0.2-doc branch, and fork a 3.1.x branch off > of master. This will be feature-freeze for 3.1 and we will then use the > back-port bot to move any remaining PR- for 3.1 to the 3.1.x branch. I > propose we aim for an RC1 sometime between Feb 18 and Feb 25 and a final > release March 4. > > Similarly when we tag 2.2.4 we will delete the 2.2.3-doc branch and create > 2.2.4-doc (again, conserving the number of active branches we have). > > If you have the power to add labels / milestones please mark things that > you think must go in for 3.1 as release critical and re-milestone things > you don't think will be done is the next few weeks as 3.2 (or > needs-sorting). > > So in summary: > > Feb 11: release 2.2.4, 3.0.3 > Feb 18: 3.1.0rc1 > Mar 4: 3.1.0 > > Branches to be removed from matplotlib/matplotlib > - v3.0.x > - v3.0.2-doc > - v2.2.3-doc > > Branches to be added: > - v3.1.x > - v3.0.3-doc (we need this at least temporarily to put the DOI on after > we tag) > - v3.1.0-doc > - v2.2.4-doc > > Milestones to be closed: > - v2.2.4 > - v3.1.0 > - v3.0.3 > - v3.0.2-doc > > Milestones to be added: > - v2.2.5 > - v3.1.1 > - v3.1-doc > > Milestones to have their backport-targets changed: > - v2.2-doc > > > Tom > > -- > Thomas Caswell > tcaswell at gmail.com > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmhobson at gmail.com Tue Feb 5 18:04:30 2019 From: pmhobson at gmail.com (Paul Hobson) Date: Tue, 5 Feb 2019 15:04:30 -0800 Subject: [Matplotlib-devel] Release and branching plans for {2.2.4, 3.0.3, 3.1.0} In-Reply-To: References: Message-ID: Agreed. There's a light at the end of this work tunnel. I get back on the review train soon. -Paul On Tue, Feb 5, 2019 at 2:52 PM David Stansby wrote: > Sounds good to me! Thanks as always Tom for organisiing all this. > > David > > On Mon, 4 Feb 2019 at 20:01, Thomas Caswell wrote: > >> Folks, >> >> First an apology, this should have gone out last week. >> >> Paul Ivanov has agreed to co-manage this release cycle with me. >> >> The rough plan is to do the bug fix releases at the end of this week >> (aiming for Feb 11 to have 2.2.4 and 3.0.3 released and available on >> pypi). I don't think we need to do RCs for these. >> >> At the same time as we tag 3.0.3 we will delete the 3.0.x and the >> 3.0.2-doc branch, create the 3.0.2-doc branch, and fork a 3.1.x branch off >> of master. This will be feature-freeze for 3.1 and we will then use the >> back-port bot to move any remaining PR- for 3.1 to the 3.1.x branch. I >> propose we aim for an RC1 sometime between Feb 18 and Feb 25 and a final >> release March 4. >> >> Similarly when we tag 2.2.4 we will delete the 2.2.3-doc branch and >> create 2.2.4-doc (again, conserving the number of active branches we have). >> >> If you have the power to add labels / milestones please mark things that >> you think must go in for 3.1 as release critical and re-milestone things >> you don't think will be done is the next few weeks as 3.2 (or >> needs-sorting). >> >> So in summary: >> >> Feb 11: release 2.2.4, 3.0.3 >> Feb 18: 3.1.0rc1 >> Mar 4: 3.1.0 >> >> Branches to be removed from matplotlib/matplotlib >> - v3.0.x >> - v3.0.2-doc >> - v2.2.3-doc >> >> Branches to be added: >> - v3.1.x >> - v3.0.3-doc (we need this at least temporarily to put the DOI on after >> we tag) >> - v3.1.0-doc >> - v2.2.4-doc >> >> Milestones to be closed: >> - v2.2.4 >> - v3.1.0 >> - v3.0.3 >> - v3.0.2-doc >> >> Milestones to be added: >> - v2.2.5 >> - v3.1.1 >> - v3.1-doc >> >> Milestones to have their backport-targets changed: >> - v2.2-doc >> >> >> Tom >> >> -- >> Thomas Caswell >> tcaswell at gmail.com >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From CSchelp at gmx.net Mon Feb 11 08:54:39 2019 From: CSchelp at gmx.net (Carsten Schelp) Date: Mon, 11 Feb 2019 14:54:39 +0100 Subject: [Matplotlib-devel] plot confidence ellipse Message-ID: An HTML attachment was scrubbed... URL: From daniele at grinta.net Wed Feb 13 19:46:32 2019 From: daniele at grinta.net (Daniele Nicolodi) Date: Wed, 13 Feb 2019 17:46:32 -0700 Subject: [Matplotlib-devel] Event handling callbacks call order Message-ID: <629c191f-fbb9-f73c-2b54-748804d6691d@grinta.net> Hello, I have an application where I let the user place Patches on the canvas via mouse events. To do so I have a "button_press_event" callback registered to the canvas. I now would like to allow to drag the drawn patches to change their position. To do so I register other callbacks on the canvas like in the examples at https://matplotlib.org/users/event_handling.html. The problem is that the callbacks are called in the order they are registered and I haven't found a way to inhibit execution of callbacks down the stack from previously called callback. This results in the fact that patches are drawn on top of the old ones when the user tries to drag those around. I can see (quite convoluted) ways to avoid this in my code, but I would think that correctly handling this is a common occurrence and that there could be a solution built into matplotlib. However, I haven't found it. I am missing something? Thank you! Cheers, Dan From antony.lee at institutoptique.fr Thu Feb 14 05:26:44 2019 From: antony.lee at institutoptique.fr (Antony Lee) Date: Thu, 14 Feb 2019 11:26:44 +0100 Subject: [Matplotlib-devel] Event handling callbacks call order In-Reply-To: <629c191f-fbb9-f73c-2b54-748804d6691d@grinta.net> References: <629c191f-fbb9-f73c-2b54-748804d6691d@grinta.net> Message-ID: Hi, A simple way to do this would be for the first handler to attach e.g. a "handled" ("accepted", in Qt terminology) attribute to the event and for later handlers to first check whether that attribute exists. Note that this can be done independently of anything provided by Matplotlib itself (Matplotlib could automatically stop propagating events with that attribute set, but I'm not sure it's really worth it). Cheers, Antony On Thu, Feb 14, 2019 at 1:56 AM Daniele Nicolodi wrote: > Hello, > > I have an application where I let the user place Patches on the canvas > via mouse events. To do so I have a "button_press_event" callback > registered to the canvas. I now would like to allow to drag the drawn > patches to change their position. To do so I register other callbacks on > the canvas like in the examples at > https://matplotlib.org/users/event_handling.html. The problem is that > the callbacks are called in the order they are registered and I haven't > found a way to inhibit execution of callbacks down the stack from > previously called callback. This results in the fact that patches are > drawn on top of the old ones when the user tries to drag those around. > > I can see (quite convoluted) ways to avoid this in my code, but I would > think that correctly handling this is a common occurrence and that there > could be a solution built into matplotlib. However, I haven't found it. > > I am missing something? > > Thank you! > > Cheers, > Dan > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rayosborn at me.com Thu Feb 14 09:49:14 2019 From: rayosborn at me.com (Raymond Osborn) Date: Thu, 14 Feb 2019 08:49:14 -0600 Subject: [Matplotlib-devel] Event handling callbacks call order In-Reply-To: <629c191f-fbb9-f73c-2b54-748804d6691d@grinta.net> References: <629c191f-fbb9-f73c-2b54-748804d6691d@grinta.net> Message-ID: <0BCC4E97-FDB7-43BB-9048-D2F14FD3A534@me.com> I used the same Matplotlib examples to implement something similar in widgets.py (https://github.com/rayosborn/nexpy/blob/edit-options/src/nexpy/gui/widgets.py ). There is an NXpatch class, with a variety of subclassed shapes. Once they are created and connected to the plot, they are independently draggable and resizable as promised. >>> plotview.deactivate() >>> r=NXrectangle(1650,2000,200,1000,color='g?) >>> r.connect() >>> plotview.activate() I do have to deactivate zoom and pan modes when adding the shapes, but they can be reactivated afterwards and the shapes will still be movable provided the cursor is within them. I don?t know if that is the problem you are encountering. In the code, ?plotview? is the active plotting window - you can find the activate and deactivate functions in https://github.com/rayosborn/nexpy/blob/edit-options/src/nexpy/gui/plotview.py . Ray > On Feb 13, 2019, at 6:46 PM, Daniele Nicolodi wrote: > > Hello, > > I have an application where I let the user place Patches on the canvas > via mouse events. To do so I have a "button_press_event" callback > registered to the canvas. I now would like to allow to drag the drawn > patches to change their position. To do so I register other callbacks on > the canvas like in the examples at > https://matplotlib.org/users/event_handling.html. The problem is that > the callbacks are called in the order they are registered and I haven't > found a way to inhibit execution of callbacks down the stack from > previously called callback. This results in the fact that patches are > drawn on top of the old ones when the user tries to drag those around. > > I can see (quite convoluted) ways to avoid this in my code, but I would > think that correctly handling this is a common occurrence and that there > could be a solution built into matplotlib. However, I haven't found it. > > I am missing something? > > Thank you! > > Cheers, > Dan > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Feb 18 17:09:05 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 18 Feb 2019 17:09:05 -0500 Subject: [Matplotlib-devel] 2019 John Hunter Excellence in Plotting Contest Organizers Message-ID: Folks, We need a volunteer or two to help run the JHEPC competition this year (Nelle Varoquaux and Michael Droettboom ran it last year) The role involves : - making sure the announcement goes out - collecting a panel of judges (starting from last years) - organizing the collection of the submissions - sending the judging packet out to the judges and collecting the results - collating the results from the judges The timeline is: - get announcement out (late March / Early April) - collect submissions and distribute to judges (late May / early June) - final tally of results (July 10-12 to be announced at SciPy) The time commitment is 10-20 hours total between now and July. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From CSchelp at gmx.net Thu Feb 21 15:40:16 2019 From: CSchelp at gmx.net (Carsten Schelp) Date: Thu, 21 Feb 2019 21:40:16 +0100 Subject: [Matplotlib-devel] plot confidence ellipse Message-ID: Hello, Quite some time ago I had to plot confidence ellipses for two-dimensional datasets. There was no out-of-the-box solution in the libraries I used, then. Also, all the solutions that I found when searching online seemed cumbersome or did not even work well. So I brewed my own. You can see the result of my effort in this blogpost here (python, using numpy and matplotlib): https://carstenschelp.github.io/2018/09/14/Plot_Confidence_Ellipse_001.html - along with an explanation how and why it works. If you guys think that this functionality might be useful within matplotlib, I would happily prepare this approach - pythonic-checks, tests and all - and send a patch or pull request. I consider the confidence ellipse a kind of "cousin" to the "scatter(...)" function. Maybe it is appropriate to place it next to "scatter" - but that is still to be discussed, I think. Do you think that a function to plot the confidence ellipse of a two-dimensional dataset should be part of matplotlib? I am curious to hear your opinion. If the answer is "yes" I will make time to get the existing code "matplotlib-ready". (Sorry, I am posting this for the second time. First time, I sent an html message which messed up the readability in the list) Kind regards, Carsten From jklymak at uvic.ca Thu Feb 21 15:49:05 2019 From: jklymak at uvic.ca (Jody Klymak) Date: Thu, 21 Feb 2019 12:49:05 -0800 Subject: [Matplotlib-devel] plot confidence ellipse In-Reply-To: References: Message-ID: Hi Carsten, Thanks a lot for the cool example, and interest in contributing to matplotlib. The only matplotlib-part of this is drawing an ellipse, which we already have code for. From what I can tell, the rest is data processing and application of statistics. While we have historically had some data processing and statistics in the package, we are actively trying to remove as much of that as possible and leave it for numpy, scipy, pandas etc. Given that, I don?t think matplotlib is the correct home for this functionality. But perhaps I?ve misunderstood your proposal. Its certainly possible that other libraries would find this very appropriate. Thanks, Jody > On 21 Feb 2019, at 12:40, Carsten Schelp wrote: > > Hello, > > Quite some time ago I had to plot confidence ellipses for two-dimensional datasets. > There was no out-of-the-box solution in the libraries I used, then. > Also, all the solutions that I found when searching online seemed cumbersome or did not even work well. > > So I brewed my own. You can see the result of my effort in this blogpost here (python, using numpy and matplotlib): > https://carstenschelp.github.io/2018/09/14/Plot_Confidence_Ellipse_001.html > - along with an explanation how and why it works. > > If you guys think that this functionality might be useful within matplotlib, I would happily prepare this approach - pythonic-checks, tests and all - and send a patch or pull request. > I consider the confidence ellipse a kind of "cousin" to the "scatter(...)" function. Maybe it is appropriate to place it next to "scatter" - but that is still to be discussed, I think. > Do you think that a function to plot the confidence ellipse of a two-dimensional dataset should be part of matplotlib? > I am curious to hear your opinion. If the answer is "yes" I will make time to get the existing code "matplotlib-ready". > > (Sorry, I am posting this for the second time. First time, I sent an html message which messed up the readability in the list) > Kind regards, Carsten > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel -- Jody Klymak http://web.uvic.ca/~jklymak/ From antony.lee at institutoptique.fr Thu Feb 21 15:54:23 2019 From: antony.lee at institutoptique.fr (Antony Lee) Date: Thu, 21 Feb 2019 21:54:23 +0100 Subject: [Matplotlib-devel] plot confidence ellipse In-Reply-To: References: Message-ID: Dear Carsten, Thank you for sharing your example. I personally think it looks like a reasonably common task, but Matplotlib is trying to move away from doing the statistical computations in favor of concentrating on the just providing the plotting parts (at least that's my personal take). Hence, the example may be a better addition to the Matplotlib gallery (under examples/ in the source tree); feel free to open a PR for that. Cheers, Antony On Thu, Feb 21, 2019 at 9:40 PM Carsten Schelp wrote: > Hello, > > Quite some time ago I had to plot confidence ellipses for two-dimensional > datasets. > There was no out-of-the-box solution in the libraries I used, then. > Also, all the solutions that I found when searching online seemed > cumbersome or did not even work well. > > So I brewed my own. You can see the result of my effort in this blogpost > here (python, using numpy and matplotlib): > https://carstenschelp.github.io/2018/09/14/Plot_Confidence_Ellipse_001.html > - along with an explanation how and why it works. > > If you guys think that this functionality might be useful within > matplotlib, I would happily prepare this approach - pythonic-checks, tests > and all - and send a patch or pull request. > I consider the confidence ellipse a kind of "cousin" to the "scatter(...)" > function. Maybe it is appropriate to place it next to "scatter" - but that > is still to be discussed, I think. > Do you think that a function to plot the confidence ellipse of a > two-dimensional dataset should be part of matplotlib? > I am curious to hear your opinion. If the answer is "yes" I will make time > to get the existing code "matplotlib-ready". > > (Sorry, I am posting this for the second time. First time, I sent an html > message which messed up the readability in the list) > Kind regards, Carsten > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.barker at noaa.gov Thu Feb 21 20:12:52 2019 From: chris.barker at noaa.gov (Chris Barker) Date: Thu, 21 Feb 2019 17:12:52 -0800 Subject: [Matplotlib-devel] plot confidence ellipse In-Reply-To: References:

Message-ID: On Thu, Feb 21, 2019 at 12:59 PM Jody Klymak wrote: > Hi Carsten, > > From what I can tell, the rest is data processing and application of > statistics. While we have historically had some data processing and > statistics in the package, we are actively trying to remove as much of that > as possible and leave it for numpy, scipy, pandas etc. Given that, I don?t > think matplotlib is the correct home for this functionality. Maybe statsmodels is though: http://www.statsmodels.org/stable/index.html If it's not already there. Also -- there is a bit of maybe-tricky MPL code in there with applying transforms -- so it *may* make sense to add a utility to MPL to draw such ellipses. -CHB -- 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 Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Feb 22 22:35:14 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 22 Feb 2019 22:35:14 -0500 Subject: [Matplotlib-devel] created v3.1.x branch Message-ID: Folks, Created the 3.1.x and set up the bot to backport to PRs in the v3.1.0 milestone. We have ~170 open issues / pull requests labeled for 3.1.0. If you have time please help finish up the review and triage any release critical bugs / move to 3.2. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Feb 22 22:38:44 2019 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 22 Feb 2019 22:38:44 -0500 Subject: [Matplotlib-devel] master branch protection Message-ID: Folks, I turned up the protection on the master branch a bit to require 1 review and no change requests before the UI will let you merge. Lets see how it goes, please provide feedback on how this is. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From CSchelp at gmx.net Sat Feb 23 02:45:52 2019 From: CSchelp at gmx.net (Carsten Schelp) Date: Sat, 23 Feb 2019 08:45:52 +0100 Subject: [Matplotlib-devel] plot confidence ellipse In-Reply-To: References:

Message-ID: Thanks for the feedback, everybody! Appreciated. It is definitely a good idea to guard that line "What should really be in MPL, and what not". I remember my situation as a user, when I first had to plot those ellipses. I thought "MPL gives me boxplots and histograms - I'll have a look whether I can also get a confidence ellipse, here." Just like with scatter() or hist() I expected to put data in and get back a plot. Not analysis, but mere visualisation. And this basically is what confidence_ellipse() does. (Maybe I should then not return the matrix with the pearson coefficients, for clarity.) In the function, numpy.cov() is the only thing that looks a bit like data analysis, from my perspective. The rest of the code is addressing that non-trivial geometric problem to get the ellipse right. And I think that MPL is also supposed to help users with geometrical problems, given it is about standard plotting functionality like histograms, boxplots and confidence ellipses? hist() for instance uses numpy.histogram() to estimate the right number of bins. But only to get the plot right, not for analysis. And hist() is not to be considered data-aware, particularly. The statsmodels module on the other hand has a lot of data-awareness and no geometry/plot awareness. confidence_ellipse() would not really fit in there, I think. Please don't get me wrong: I am not arguing. I just want to show you where my idea came from: "Hey this would be handy to have in MPL". The MPS gallery is a great place to show the "howto", though. For the time being, I can submit an example there. If the devel-community changes her mind, she knows how to find me :-) Kind regards, Carsten