From estatisticseu at gmail.com Tue Nov 3 16:05:16 2015 From: estatisticseu at gmail.com (Elias Estatistics) Date: Tue, 3 Nov 2015 23:05:16 +0200 Subject: [Matplotlib-devel] Include plot example: a 3D Barplot with a line Message-ID: <5639218C.2080801@gmail.com> Dear developers, I wrote a code (using different examples), that is plotting together: a 3d barplot with a smooth line that follows the "points" of bars. I could not find something similar, therefore, i am sending you this example. You may edit some sections if you find something wrong. Sorry for my english - not my primary language. #The following plot presents a 3d barplot together with a smooth line that follows the "points" of bars. #needed modules import csv import pandas as pandas import numpy as np from mpl_toolkits.mplot3d import Axes3D import matplotlib.pyplot as plt from matplotlib import cm from scipy.interpolate import spline #here, we are importing a simple datafile, csv type. data are comma seperated #Also, we are importing only 1st, 2nd and 4th columns. We can call these data now by thie new name, 'io'. #io = pandas.read_csv('test.csv', sep=",",usecols=(1,2,3,4)) #not available #io = io[np.isfinite(io['alice'])] #not available #We define a new name for the column that is named 'alice' inside 'io' dataset. result=([9,6,14,7,16,4,14,19,16,7,13,10,15,16,19,27,7,6]) #we need to make these data 'array type' result = np.array(result) #we now define the dimensions of our figure/plot, as well its dpi fig=plt.figure(figsize=(14, 6), dpi=150) #This line defines our first plot, afterwards, the '112' will define our second plot. ax1=fig.add_subplot(111, projection='3d') #we define here labels xlabels =np.array([9,6,14,7,16,4,14,19,16,7,13,10,15,16,19,27,7,6]) xpos = np.arange(xlabels.shape[0]) ylabels = np.array(['series A']) ypos = np.arange(ylabels.shape[0]) xposM, yposM = np.meshgrid(xpos, ypos, copy=False) zpos=result zpos = zpos.ravel() #this defines the dimensions of the actual boxes, you can play with these values. dx=0.7 dy=0.7 dz=zpos #here, we define ticks, they are placed in the 'middle' of each bar ax1.w_xaxis.set_ticks(xpos + dx/2.) ax1.w_xaxis.set_ticklabels(xlabels) ax1.w_yaxis.set_ticks(ypos + dy/2.) ax1.w_yaxis.set_ticklabels(ylabels) #here we define the colors of the bars, rainbow style, you can play with these numbers values = np.linspace(0.2, 1., xposM.ravel().shape[0]) colors = cm.rainbow(values) #figure subtitle fig.suptitle('test title', fontsize=20) #here, we define in the x axis the size of its ticks, its numbers ax1.tick_params(axis='x', which='major', pad=15,labelsize=6) #Here, we define the limits of y axis, #NOTE that this defines WHERE bars will be placed IN relation to the rest figure, their offset point plt.ylim((-2,5)) #this says if the grid will be printed plt.grid(True) #this defines the placement of the 3d plot in its placeholders, in the surrounding white space plt.subplots_adjust(left=0.0, right=1.0, bottom=0.0, top=1.0) #this is the actual command to define the plot, all 6 parameters that we previously defined, are placed here. #colors is an extra parameter ax1.bar3d(xposM.ravel(), yposM.ravel(), dz*0, dx, dy, dz, color=colors) #here we define that we will place a second plot ax1=fig.add_subplot(112, projection='3d') #here we say to produce numbers from 0 according to how many data exist in our 'result' x=np.arange(0, len(result)) #here, i apply a math trick, in order to get the line a little higher, out of the bars x=x+0.4 y=result #here, i try to center the linein relation to the top of bars. y=y+5 #here, i try to produce more points in order to make the line to look nicer. x_smooth=np.linspace(x.min(),x.max(), 100) y_smooth=spline(x,y, x_smooth) #here, i try to produce a 'z' array of so many zeros as the length of 'x_smooth' z=np.linspace(0, 0, len(x_smooth)) #here, we define the parameters of the second plot. #note that 'ax1' symbol is duplicated, in order to plot the line in the same plot with the barplot. ax1.plot(x_smooth,z,y_smooth) #here, finally, we will check our results, visually! plt.show() ???????????????????????????????????????.. For any question, request, comment, or statistical analysis you can communicate directly with me by using: ???????????????????????????????????????? *estatisticseu at gmail.com* ???????????????????????????????????????? Statistical Articles: eXplained Statistics EstatisticsEU Facebook page to find some other statistical goodies! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1022 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 10371 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 4470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2441 bytes Desc: not available URL: From shankha.nag at epfl.ch Fri Nov 6 11:41:20 2015 From: shankha.nag at epfl.ch (Nag Shankha) Date: Fri, 6 Nov 2015 16:41:20 +0000 Subject: [Matplotlib-devel] Non-orthogonal axis plots Message-ID: <8E35F330319A5344B4FC00944E7787831A9A2BE6@REXMF.intranet.epfl.ch> Hello, I am required to do some contour or surface plots where the x and y axes are non-orthogonal. It might appear trivial because a non-orthogonal contour section is a part of the orthogonal coordinate system. But the problem is, for contour and surface plots with orthogonal coordinates we need a rectangular mesh. However if the mesh of datapoints are not rectangle we cannot use the contourf type functions. So a routine is required to be able to draw contours and surfaces for non-rectangular mesh (or non-orthogonal coordinate system). Moreover the problem with not having a roitine for ternary plots (posted several times) is a special case of the aforesaid issue. Thus I request the developers of matplotlib to develop a routine to address this problem. Let me know your opinion at your earliest convenience. Sincerely, Shankha Shankha Nag, Doctoral Assistant EPFL STI IGM LAMMM ME A1 398 Station 9 CH-1015 Lausanne -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Fri Nov 6 23:45:32 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Sat, 07 Nov 2015 04:45:32 +0000 Subject: [Matplotlib-devel] protected branches on GH Message-ID: Hey all, GH now lets you protect branches which prevents people from force-pushing or deleting those branches; https://github.com/matplotlib/matplotlib/settings/branches. I have protected our 'production' branches. There is also an option to require status checks to pass before merging to a given branch, but that would break our current cherry-pick workflow and mean that we could not use our judgement to over-rule travis.ci ;) Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From njs at pobox.com Sat Nov 7 00:07:17 2015 From: njs at pobox.com (Nathaniel Smith) Date: Fri, 6 Nov 2015 21:07:17 -0800 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: Message-ID: On Fri, Nov 6, 2015 at 8:45 PM, Thomas Caswell wrote: > Hey all, > > GH now lets you protect branches which prevents people from force-pushing or > deleting those branches; > https://github.com/matplotlib/matplotlib/settings/branches. > > I have protected our 'production' branches. > > There is also an option to require status checks to pass before merging to a > given branch, but that would break our current cherry-pick workflow and mean > that we could not use our judgement to over-rule travis.ci ;) It looks like you can set it so that the status checks are enforced on normal users, but administrators are allowed to ignore it: https://help.github.com/articles/enabling-required-status-checks/ What I really want to know is whether it prevents simply pushing directly to the branch. That would be really awesome because it would mean you could hand out commit bits like candy without worrying that unreviewed code could creep into the repo... but there's no indication of this anywhere. (OTOH if direct pushes *are* still allowed, then that also provides a method for circumventing the status checks when desired -- just do a manual merge and push from the command line.) -n -- Nathaniel J. Smith -- http://vorpus.org From rmay31 at gmail.com Mon Nov 9 10:21:24 2015 From: rmay31 at gmail.com (Ryan May) Date: Mon, 9 Nov 2015 08:21:24 -0700 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: Message-ID: We use it here at work. Protected branches are just that--you CANNOT push a commit (i.e. a hash) until it has passed the checks. One note, though, is that the commit must have passed the checks running on top of *current* master. That means if master changes (i.e. you merge another PR), you have to update the PR (you can use the web button to merge master into the branch, but ewww) and re-run the status checks before it can merge. For us, it's still been better to enforce that tests stay green, but we don't have the rate of PR's that matplotlib has. Ryan On Fri, Nov 6, 2015 at 10:07 PM, Nathaniel Smith wrote: > On Fri, Nov 6, 2015 at 8:45 PM, Thomas Caswell wrote: > > Hey all, > > > > GH now lets you protect branches which prevents people from > force-pushing or > > deleting those branches; > > https://github.com/matplotlib/matplotlib/settings/branches. > > > > I have protected our 'production' branches. > > > > There is also an option to require status checks to pass before merging > to a > > given branch, but that would break our current cherry-pick workflow and > mean > > that we could not use our judgement to over-rule travis.ci ;) > > It looks like you can set it so that the status checks are enforced on > normal users, but administrators are allowed to ignore it: > https://help.github.com/articles/enabling-required-status-checks/ > > What I really want to know is whether it prevents simply pushing > directly to the branch. That would be really awesome because it would > mean you could hand out commit bits like candy without worrying that > unreviewed code could creep into the repo... but there's no indication > of this anywhere. (OTOH if direct pushes *are* still allowed, then > that also provides a method for circumventing the status checks when > desired -- just do a manual merge and push from the command line.) > > -n > > -- > Nathaniel J. Smith -- http://vorpus.org > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Ryan May -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Nov 9 12:11:03 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 09 Nov 2015 17:11:03 +0000 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: Message-ID: As a side note, I think you can force Travis to re run on top of the current master by closing and reopening the issue. On Mon, Nov 9, 2015, 10:21 Ryan May wrote: > We use it here at work. Protected branches are just that--you CANNOT push > a commit (i.e. a hash) until it has passed the checks. One note, though, is > that the commit must have passed the checks running on top of *current* > master. That means if master changes (i.e. you merge another PR), you have > to update the PR (you can use the web button to merge master into the > branch, but ewww) and re-run the status checks before it can merge. > > For us, it's still been better to enforce that tests stay green, but we > don't have the rate of PR's that matplotlib has. > > Ryan > > On Fri, Nov 6, 2015 at 10:07 PM, Nathaniel Smith wrote: > >> On Fri, Nov 6, 2015 at 8:45 PM, Thomas Caswell >> wrote: >> > Hey all, >> > >> > GH now lets you protect branches which prevents people from >> force-pushing or >> > deleting those branches; >> > https://github.com/matplotlib/matplotlib/settings/branches. >> > >> > I have protected our 'production' branches. >> > >> > There is also an option to require status checks to pass before merging >> to a >> > given branch, but that would break our current cherry-pick workflow and >> mean >> > that we could not use our judgement to over-rule travis.ci ;) >> >> It looks like you can set it so that the status checks are enforced on >> normal users, but administrators are allowed to ignore it: >> https://help.github.com/articles/enabling-required-status-checks/ >> >> What I really want to know is whether it prevents simply pushing >> directly to the branch. That would be really awesome because it would >> mean you could hand out commit bits like candy without worrying that >> unreviewed code could creep into the repo... but there's no indication >> of this anywhere. (OTOH if direct pushes *are* still allowed, then >> that also provides a method for circumventing the status checks when >> desired -- just do a manual merge and push from the command line.) >> > >> -n >> >> -- >> Nathaniel J. Smith -- http://vorpus.org >> > _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel >> > > > > -- > Ryan May > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Mon Nov 9 12:20:44 2015 From: efiring at hawaii.edu (Eric Firing) Date: Mon, 9 Nov 2015 07:20:44 -1000 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: Message-ID: <5640D5EC.30109@hawaii.edu> On 2015/11/09 7:11 AM, Thomas Caswell wrote: > As a side note, I think you can force Travis to re run on top of the > current master by closing and reopening the issue. > Also, if you go into the Travis page showing the build, there is a "redo" circle with circular arrow that triggers a re-run. If that suffices, it is nicer than adding the clutter of close/reopen, which will trigger two emails to each follower. From ben.v.root at gmail.com Mon Nov 9 12:23:42 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 9 Nov 2015 12:23:42 -0500 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: <5640D5EC.30109@hawaii.edu> References: <5640D5EC.30109@hawaii.edu> Message-ID: A simple rebase doesn't suffice? On Mon, Nov 9, 2015 at 12:20 PM, Eric Firing wrote: > On 2015/11/09 7:11 AM, Thomas Caswell wrote: > >> As a side note, I think you can force Travis to re run on top of the >> current master by closing and reopening the issue. >> >> > Also, if you go into the Travis page showing the build, there is a "redo" > circle with circular arrow that triggers a re-run. If that suffices, it is > nicer than adding the clutter of close/reopen, which will trigger two > emails to each follower. > > _______________________________________________ > 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 efiring at hawaii.edu Mon Nov 9 12:27:40 2015 From: efiring at hawaii.edu (Eric Firing) Date: Mon, 9 Nov 2015 07:27:40 -1000 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: <5640D5EC.30109@hawaii.edu> Message-ID: <5640D78C.5080803@hawaii.edu> On 2015/11/09 7:23 AM, Benjamin Root wrote: > A simple rebase doesn't suffice? I expect it will, but it's a little bit more complicated than clicking a button on a web page. From tcaswell at gmail.com Mon Nov 9 12:27:57 2015 From: tcaswell at gmail.com (Thomas Caswell) Date: Mon, 09 Nov 2015 17:27:57 +0000 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: <5640D5EC.30109@hawaii.edu> References: <5640D5EC.30109@hawaii.edu> Message-ID: I think the rerun button (sadly) reruns with master of when the pr was created (because it is pinned to the sha of that shadow merge). I suspect that Travis and gh need to work out how to improve the web hooks on that. @ben yes, but is there really such a thing as a simple rebase? The close/open cycle can be done by anyone with a commit bit, the rebase can only be done by the contributor. I don't think we can add that sort of bottle neck to our work flow. Tom On Mon, Nov 9, 2015, 12:20 Eric Firing wrote: > On 2015/11/09 7:11 AM, Thomas Caswell wrote: > > As a side note, I think you can force Travis to re run on top of the > > current master by closing and reopening the issue. > > > > Also, if you go into the Travis page showing the build, there is a > "redo" circle with circular arrow that triggers a re-run. If that > suffices, it is nicer than adding the clutter of close/reopen, which > will trigger two emails to each follower. > _______________________________________________ > 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 njs at pobox.com Mon Nov 9 12:33:08 2015 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 9 Nov 2015 09:33:08 -0800 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: <5640D5EC.30109@hawaii.edu> References: <5640D5EC.30109@hawaii.edu> Message-ID: On Mon, Nov 9, 2015 at 9:20 AM, Eric Firing wrote: > On 2015/11/09 7:11 AM, Thomas Caswell wrote: >> >> As a side note, I think you can force Travis to re run on top of the >> current master by closing and reopening the issue. >> > > Also, if you go into the Travis page showing the build, there is a "redo" > circle with circular arrow that triggers a re-run. If that suffices, it is > nicer than adding the clutter of close/reopen, which will trigger two emails > to each follower. Kinda annoying when what you really want is a single button you press that means "re-run the tests if necessary, and if they pass, then merge". Homu might suffice for this: http://homu.io/ It's designed to provide similar functionality, but predates Github's new protected branch stuff, so projects using Homu generally just use social convention to enforce that no-one commits directly :-). But the homu UX does provide that 'single button' -- you post a comment saying "this looks good to me" in the special bot-language, and then the bot double-checks that the tests still pass when merging into current master, and if so then it pushes them. And, since it uses the Travis infrastructure to re-run the tests, I think it might well automagically work with the new protected branch feature, since Github should be able to see that the merged branch that homu is trying to push has had the tests run on it. (It also provides a useful serialization point -- the way Github's protected branches work right now, if you're trying to work with them manually and two people are trying to get a PR merged at the same time, then they both click the "rebuild" button, they both get a green light, they both click merge, one of them wins, and then the other has to go rebuild *again*. With homu, they'd each post an "I approve" message, and then Homu would take care of the race condition by picking one of them to test-and-merge first, and then the other.) -n -- Nathaniel J. Smith -- http://vorpus.org From njs at pobox.com Mon Nov 9 12:40:38 2015 From: njs at pobox.com (Nathaniel Smith) Date: Mon, 9 Nov 2015 09:40:38 -0800 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: <5640D5EC.30109@hawaii.edu> Message-ID: (BTW, experimenting with homu is super easy: you go to http://homu.io/n/ and type in the name of your repo to register. This by itself doesn't do much -- the only thing the bot does spontaneously is post a comment on old PRs when they become unmergeable due to conflicts, which is kinda nice but whatever [1]. But then if you want to use the actual functionality, you can now type "@homu: r+" in a PR comment, and the bot will wake up and run the tests and merge if they pass. At least if the person making the comment is on @homu's list of trusted reviewers.) -n [1] Example: https://github.com/numpy/numpy/pull/6053#issuecomment-143870423 On Mon, Nov 9, 2015 at 9:33 AM, Nathaniel Smith wrote: > On Mon, Nov 9, 2015 at 9:20 AM, Eric Firing wrote: >> On 2015/11/09 7:11 AM, Thomas Caswell wrote: >>> >>> As a side note, I think you can force Travis to re run on top of the >>> current master by closing and reopening the issue. >>> >> >> Also, if you go into the Travis page showing the build, there is a "redo" >> circle with circular arrow that triggers a re-run. If that suffices, it is >> nicer than adding the clutter of close/reopen, which will trigger two emails >> to each follower. > > Kinda annoying when what you really want is a single button you press > that means "re-run the tests if necessary, and if they pass, then > merge". > > Homu might suffice for this: > http://homu.io/ > It's designed to provide similar functionality, but predates Github's > new protected branch stuff, so projects using Homu generally just use > social convention to enforce that no-one commits directly :-). But the > homu UX does provide that 'single button' -- you post a comment saying > "this looks good to me" in the special bot-language, and then the bot > double-checks that the tests still pass when merging into current > master, and if so then it pushes them. > > And, since it uses the Travis infrastructure to re-run the tests, I > think it might well automagically work with the new protected branch > feature, since Github should be able to see that the merged branch > that homu is trying to push has had the tests run on it. > > (It also provides a useful serialization point -- the way Github's > protected branches work right now, if you're trying to work with them > manually and two people are trying to get a PR merged at the same > time, then they both click the "rebuild" button, they both get a green > light, they both click merge, one of them wins, and then the other has > to go rebuild *again*. With homu, they'd each post an "I approve" > message, and then Homu would take care of the race condition by > picking one of them to test-and-merge first, and then the other.) > > -n > > -- > Nathaniel J. Smith -- http://vorpus.org -- Nathaniel J. Smith -- http://vorpus.org From ben.v.root at gmail.com Mon Nov 9 12:45:36 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Mon, 9 Nov 2015 12:45:36 -0500 Subject: [Matplotlib-devel] protected branches on GH In-Reply-To: References: <5640D5EC.30109@hawaii.edu> Message-ID: While we are in the Travis-bashing mode (sort of), is there a way to get Travis to send a message to the creator of the PR that the tests failed? On Mon, Nov 9, 2015 at 12:40 PM, Nathaniel Smith wrote: > (BTW, experimenting with homu is super easy: you go to > http://homu.io/n/ and type in the name of your repo to register. This > by itself doesn't do much -- the only thing the bot does spontaneously > is post a comment on old PRs when they become unmergeable due to > conflicts, which is kinda nice but whatever [1]. But then if you want > to use the actual functionality, you can now type "@homu: r+" in a PR > comment, and the bot will wake up and run the tests and merge if they > pass. At least if the person making the comment is on @homu's list of > trusted reviewers.) > > -n > > [1] Example: > https://github.com/numpy/numpy/pull/6053#issuecomment-143870423 > > On Mon, Nov 9, 2015 at 9:33 AM, Nathaniel Smith wrote: > > On Mon, Nov 9, 2015 at 9:20 AM, Eric Firing wrote: > >> On 2015/11/09 7:11 AM, Thomas Caswell wrote: > >>> > >>> As a side note, I think you can force Travis to re run on top of the > >>> current master by closing and reopening the issue. > >>> > >> > >> Also, if you go into the Travis page showing the build, there is a > "redo" > >> circle with circular arrow that triggers a re-run. If that suffices, > it is > >> nicer than adding the clutter of close/reopen, which will trigger two > emails > >> to each follower. > > > > Kinda annoying when what you really want is a single button you press > > that means "re-run the tests if necessary, and if they pass, then > > merge". > > > > Homu might suffice for this: > > http://homu.io/ > > It's designed to provide similar functionality, but predates Github's > > new protected branch stuff, so projects using Homu generally just use > > social convention to enforce that no-one commits directly :-). But the > > homu UX does provide that 'single button' -- you post a comment saying > > "this looks good to me" in the special bot-language, and then the bot > > double-checks that the tests still pass when merging into current > > master, and if so then it pushes them. > > > > And, since it uses the Travis infrastructure to re-run the tests, I > > think it might well automagically work with the new protected branch > > feature, since Github should be able to see that the merged branch > > that homu is trying to push has had the tests run on it. > > > > (It also provides a useful serialization point -- the way Github's > > protected branches work right now, if you're trying to work with them > > manually and two people are trying to get a PR merged at the same > > time, then they both click the "rebuild" button, they both get a green > > light, they both click merge, one of them wins, and then the other has > > to go rebuild *again*. With homu, they'd each post an "I approve" > > message, and then Homu would take care of the race condition by > > picking one of them to test-and-merge first, and then the other.) > > > > -n > > > > -- > > Nathaniel J. Smith -- http://vorpus.org > > > > -- > Nathaniel J. Smith -- http://vorpus.org > _______________________________________________ > 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 schubert.viktoria at googlemail.com Thu Nov 12 08:11:45 2015 From: schubert.viktoria at googlemail.com (Viktoria Schubert) Date: Thu, 12 Nov 2015 14:11:45 +0100 Subject: [Matplotlib-devel] Use of contourf changed? Message-ID: Hello together, Since the 1.5 version of matplotlib together with python 3.5, I get strange results from using the contourf function. What I'm actually doing is plotting a lot of points in a 2D-space. The density equals the likelihood of the data, so what I want is to plot the 1Sigma, 2Sigma and 3Sigma areas of the data. For this purpose, I was using the following line of code: cs = plt.contourf(hist2D, extent=extent, levels=[L1,L2,L3,Lmin], linestyles=['-','-','-','-'], colors=['blue','blue','blue'], alpha=0.25) The problem now is, that with matplotlib 1.4, the resulting image shows the most dense area in white instead of darker blue, which was the previous behavior. I did not change my code, I can get the old result simply by moving back to 1.4. I link to the two pictures I created, so maybe one of you can explain me, what changed with the version so that the plot is getting messed up. V1.4: http://i.imgur.com/HH7jKBE.png V1.5: http://i.imgur.com/0LZ9Tso.png Thank you very much, Viktoria From ben.v.root at gmail.com Thu Nov 12 11:09:54 2015 From: ben.v.root at gmail.com (Benjamin Root) Date: Thu, 12 Nov 2015 11:09:54 -0500 Subject: [Matplotlib-devel] Use of contourf changed? In-Reply-To: References: Message-ID: Interesting, but it is hard to tell what is going on without any code or data. In particular, matplotlib's contourf polygons has always been "unstacked". In other words, the polygons representing a contour level does not overlap with any other polygon of another contour level, so I am not exactly sure how you are getting the behavior you are seeing in either image. Now, the default algorithm for contouring did change in v1.5. You can access the old algorithm by passing `corner_mask='legacy'` as a keyword argument to contourf() in v1.5. Could you try that and see if at least you get identical results for v1.5 and v1.4? Note, that keyword argument is not available in v1.4. This should help us narrow down the source of your issue, but I wouldn't treat it as a solution because the old algorithm is slated for removal at some point, and it still doesn't explain the difference you are seeing with the new contouring algorithm. Ben On Thu, Nov 12, 2015 at 8:11 AM, Viktoria Schubert via Matplotlib-devel < matplotlib-devel at python.org> wrote: > Hello together, > > Since the 1.5 version of matplotlib together with python 3.5, I get > strange results from using the contourf function. What I'm actually > doing is plotting a lot of points in a 2D-space. The density equals the > likelihood of the data, so what I want is to plot the 1Sigma, 2Sigma and > 3Sigma areas of the data. > For this purpose, I was using the following line of code: > cs = plt.contourf(hist2D, extent=extent, levels=[L1,L2,L3,Lmin], > linestyles=['-','-','-','-'], colors=['blue','blue','blue'], alpha=0.25) > > The problem now is, that with matplotlib 1.4, the resulting image shows > the most dense area in white instead of darker blue, which was the > previous behavior. I did not change my code, I can get the old result > simply by moving back to 1.4. > I link to the two pictures I created, so maybe one of you can explain > me, what changed with the version so that the plot is getting messed up. > V1.4: > http://i.imgur.com/HH7jKBE.png > V1.5: > http://i.imgur.com/0LZ9Tso.png > > Thank you very much, > Viktoria > _______________________________________________ > 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 schubert.viktoria at googlemail.com Thu Nov 12 12:34:33 2015 From: schubert.viktoria at googlemail.com (Viktoria Schubert) Date: Thu, 12 Nov 2015 18:34:33 +0100 Subject: [Matplotlib-devel] Use of contourf changed? In-Reply-To: References: Message-ID: Hello, Yeah, this helps indeed with "corner_mask='legacy' the result is identical, even though I get a warning: /usr/lib/python3.5/site-packages/matplotlib/cbook.py:136: MatplotlibDeprecationWarning: The corner_mask='legacy' attribute was deprecated in version 1.5. Use corner_mask=False or True instead. warnings.warn(message, mplDeprecation, stacklevel=1) I tried creating a minimal example which recreates the problem with simpler data. The result does not exactly represent 100% of the problem, but it is screwed anyway. Again, with the option corner_mask='legacy' option, it looks just fine. You can find my example here: https://paste.kde.org/poyn7upbi Thank you very much! Viktoria 2015-11-12 17:09 GMT+01:00 Benjamin Root : > Interesting, but it is hard to tell what is going on without any code or > data. In particular, matplotlib's contourf polygons has always been > "unstacked". In other words, the polygons representing a contour level does > not overlap with any other polygon of another contour level, so I am not > exactly sure how you are getting the behavior you are seeing in either > image. > > Now, the default algorithm for contouring did change in v1.5. You can access > the old algorithm by passing `corner_mask='legacy'` as a keyword argument to > contourf() in v1.5. Could you try that and see if at least you get identical > results for v1.5 and v1.4? Note, that keyword argument is not available in > v1.4. This should help us narrow down the source of your issue, but I > wouldn't treat it as a solution because the old algorithm is slated for > removal at some point, and it still doesn't explain the difference you are > seeing with the new contouring algorithm. > > Ben > > > On Thu, Nov 12, 2015 at 8:11 AM, Viktoria Schubert via Matplotlib-devel > wrote: >> >> Hello together, >> >> Since the 1.5 version of matplotlib together with python 3.5, I get >> strange results from using the contourf function. What I'm actually >> doing is plotting a lot of points in a 2D-space. The density equals the >> likelihood of the data, so what I want is to plot the 1Sigma, 2Sigma and >> 3Sigma areas of the data. >> For this purpose, I was using the following line of code: >> cs = plt.contourf(hist2D, extent=extent, levels=[L1,L2,L3,Lmin], >> linestyles=['-','-','-','-'], colors=['blue','blue','blue'], alpha=0.25) >> >> The problem now is, that with matplotlib 1.4, the resulting image shows >> the most dense area in white instead of darker blue, which was the >> previous behavior. I did not change my code, I can get the old result >> simply by moving back to 1.4. >> I link to the two pictures I created, so maybe one of you can explain >> me, what changed with the version so that the plot is getting messed up. >> V1.4: >> http://i.imgur.com/HH7jKBE.png >> V1.5: >> http://i.imgur.com/0LZ9Tso.png >> >> Thank you very much, >> Viktoria >> _______________________________________________ >> Matplotlib-devel mailing list >> Matplotlib-devel at python.org >> https://mail.python.org/mailman/listinfo/matplotlib-devel > > From ianthomas23 at gmail.com Fri Nov 13 06:23:52 2015 From: ianthomas23 at gmail.com (Ian Thomas) Date: Fri, 13 Nov 2015 11:23:52 +0000 Subject: [Matplotlib-devel] Use of contourf changed? In-Reply-To: References: Message-ID: This is indeed a bug. Both the legacy code and the new code produce incorrect output, but differently incorrect. I have opened an issue on github for this: https://github.com/matplotlib/matplotlib/issues/5477 Viktoria, Thanks for reporting this. It is a bug that has been around for a long time and needs to be dealt with. If you don't want to read through all of the github issue, which may get a bit technical, the key thing from your point of view is that even though the v1.4 code gave you what you wanted to see, it wasn't actually the correct output given what your code asked for. When we fix the underlying bug, if you keep using the same code you will get the correct output which will be no good to you! Instead of using levels = [L1, L2, L3, Lmin] plt.contourf(hist2D, levels=levels, colors=['b', 'b', 'b']) you should instead use something like levels = [L1, L2, L3, Lmin] for level in levels: plt.contourf(hist2D, levels=[level, np.inf], colors='b'] This will give you the results that you want now, as well as when we fix the bug. Ian On 12 November 2015 at 17:34, Viktoria Schubert via Matplotlib-devel < matplotlib-devel at python.org> wrote: > Hello, > > Yeah, this helps indeed with "corner_mask='legacy' the result is > identical, even though I get a warning: > /usr/lib/python3.5/site-packages/matplotlib/cbook.py:136: > MatplotlibDeprecationWarning: The corner_mask='legacy' attribute was > deprecated in version 1.5. Use corner_mask=False or True instead. > warnings.warn(message, mplDeprecation, stacklevel=1) > > I tried creating a minimal example which recreates the problem with > simpler data. The result does not exactly represent 100% of the > problem, but it is screwed anyway. Again, with the option > corner_mask='legacy' option, it looks just fine. > You can find my example here: > https://paste.kde.org/poyn7upbi > > Thank you very much! > Viktoria > > > > 2015-11-12 17:09 GMT+01:00 Benjamin Root : > > Interesting, but it is hard to tell what is going on without any code or > > data. In particular, matplotlib's contourf polygons has always been > > "unstacked". In other words, the polygons representing a contour level > does > > not overlap with any other polygon of another contour level, so I am not > > exactly sure how you are getting the behavior you are seeing in either > > image. > > > > Now, the default algorithm for contouring did change in v1.5. You can > access > > the old algorithm by passing `corner_mask='legacy'` as a keyword > argument to > > contourf() in v1.5. Could you try that and see if at least you get > identical > > results for v1.5 and v1.4? Note, that keyword argument is not available > in > > v1.4. This should help us narrow down the source of your issue, but I > > wouldn't treat it as a solution because the old algorithm is slated for > > removal at some point, and it still doesn't explain the difference you > are > > seeing with the new contouring algorithm. > > > > Ben > > > > > > On Thu, Nov 12, 2015 at 8:11 AM, Viktoria Schubert via Matplotlib-devel > > wrote: > >> > >> Hello together, > >> > >> Since the 1.5 version of matplotlib together with python 3.5, I get > >> strange results from using the contourf function. What I'm actually > >> doing is plotting a lot of points in a 2D-space. The density equals the > >> likelihood of the data, so what I want is to plot the 1Sigma, 2Sigma and > >> 3Sigma areas of the data. > >> For this purpose, I was using the following line of code: > >> cs = plt.contourf(hist2D, extent=extent, levels=[L1,L2,L3,Lmin], > >> linestyles=['-','-','-','-'], colors=['blue','blue','blue'], alpha=0.25) > >> > >> The problem now is, that with matplotlib 1.4, the resulting image shows > >> the most dense area in white instead of darker blue, which was the > >> previous behavior. I did not change my code, I can get the old result > >> simply by moving back to 1.4. > >> I link to the two pictures I created, so maybe one of you can explain > >> me, what changed with the version so that the plot is getting messed up. > >> V1.4: > >> http://i.imgur.com/HH7jKBE.png > >> V1.5: > >> http://i.imgur.com/0LZ9Tso.png > >> > >> Thank you very much, > >> Viktoria > >> _______________________________________________ > >> 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 efiring at hawaii.edu Fri Nov 13 12:38:55 2015 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 13 Nov 2015 07:38:55 -1000 Subject: [Matplotlib-devel] Use of contourf changed? In-Reply-To: References: Message-ID: <5646202F.5010605@hawaii.edu> On 2015/11/12 7:34 AM, Viktoria Schubert via Matplotlib-devel wrote: > Hello, > > Yeah, this helps indeed with "corner_mask='legacy' the result is > identical, even though I get a warning: > /usr/lib/python3.5/site-packages/matplotlib/cbook.py:136: > MatplotlibDeprecationWarning: The corner_mask='legacy' attribute was > deprecated in version 1.5. Use corner_mask=False or True instead. > warnings.warn(message, mplDeprecation, stacklevel=1) > > I tried creating a minimal example which recreates the problem with > simpler data. The result does not exactly represent 100% of the > problem, but it is screwed anyway. Again, with the option > corner_mask='legacy' option, it looks just fine. > You can find my example here: > https://paste.kde.org/poyn7upbi Viktoria, Independently of the contourf bug, I suggest you consider two other options for 2-D histogram display: pcolormesh, and hexbin. In both cases, you would use a BoundaryNorm with a ListedColormap. Something like this (untested): from matplotlib import colors cmap = colors.ListedColormap([(1, 1, 1, 1), (0, 0, 1, 0.25), (0, 0, 1, 0.5), (0, 0, 1, 0.75)]) norm = colors.BoundaryNorm([0, Lmin, L1, L2, L3, np.inf], ncolors=cmap.N) plt.pcolormesh(xedges, yedges, hist2D, norm=norm, cmap=cmap) An advantage of using pcolormesh or hexbin is that the value of a cell in a histogram represents the entire cell, not a point, so it makes sense to color in the whole cell. I think that using contour or contourf in cases like this gives an inaccurate visual impression unless the histogram is reasonably smoothly varying on a fine grid. Although in the example above I have stuck to your use of alpha to modify the shade of blue, I don't advocate this. Instead, unless you really need the transparency to achieve a visual effect involving other plot elements, I suggest modifying the color directly and leaving alpha as the default (unity). So I would use something like: cmap = colors.ListedColormap([(1, 1, 1), (0.75, 0.75, 1), (0.5, 0.5, 1), (0.25, 0.25, 1)]) Eric > > Thank you very much! > Viktoria > > > > 2015-11-12 17:09 GMT+01:00 Benjamin Root : >> Interesting, but it is hard to tell what is going on without any code or >> data. In particular, matplotlib's contourf polygons has always been >> "unstacked". In other words, the polygons representing a contour level does >> not overlap with any other polygon of another contour level, so I am not >> exactly sure how you are getting the behavior you are seeing in either >> image. >> >> Now, the default algorithm for contouring did change in v1.5. You can access >> the old algorithm by passing `corner_mask='legacy'` as a keyword argument to >> contourf() in v1.5. Could you try that and see if at least you get identical >> results for v1.5 and v1.4? Note, that keyword argument is not available in >> v1.4. This should help us narrow down the source of your issue, but I >> wouldn't treat it as a solution because the old algorithm is slated for >> removal at some point, and it still doesn't explain the difference you are >> seeing with the new contouring algorithm. >> >> Ben >> >> >> On Thu, Nov 12, 2015 at 8:11 AM, Viktoria Schubert via Matplotlib-devel >> wrote: >>> >>> Hello together, >>> >>> Since the 1.5 version of matplotlib together with python 3.5, I get >>> strange results from using the contourf function. What I'm actually >>> doing is plotting a lot of points in a 2D-space. The density equals the >>> likelihood of the data, so what I want is to plot the 1Sigma, 2Sigma and >>> 3Sigma areas of the data. >>> For this purpose, I was using the following line of code: >>> cs = plt.contourf(hist2D, extent=extent, levels=[L1,L2,L3,Lmin], >>> linestyles=['-','-','-','-'], colors=['blue','blue','blue'], alpha=0.25) >>> >>> The problem now is, that with matplotlib 1.4, the resulting image shows >>> the most dense area in white instead of darker blue, which was the >>> previous behavior. I did not change my code, I can get the old result >>> simply by moving back to 1.4. >>> I link to the two pictures I created, so maybe one of you can explain >>> me, what changed with the version so that the plot is getting messed up. >>> V1.4: >>> http://i.imgur.com/HH7jKBE.png >>> V1.5: >>> http://i.imgur.com/0LZ9Tso.png >>> >>> Thank you very much, >>> Viktoria >>> _______________________________________________ >>> 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 > From mdroettboom at continuum.io Mon Nov 16 17:37:30 2015 From: mdroettboom at continuum.io (Michael Droettboom) Date: Mon, 16 Nov 2015 17:37:30 -0500 Subject: [Matplotlib-devel] Meeting minutes 2015-11-16 Message-ID: Weekly matplotlib meeting 2015-11-16 In attendance: Michael Droettboom, Thomas Caswell, Eric Firing, Jens Nielsen We spent the call going over the effects of the proposed style changes for 2.0. (mdboom/style-change branch) - Size of grid lines may be too thin. Need to experiment there. - Tick lines should be shorter. They interfere badly with minus signs, particularly when on the right hand side y-axis. They can run into other subplots when close together. - Various things were broken by turning of edgecolor for all patches (including unfilled ones) - We should use Vega category 10 colors for the color cycle, rather than ColorBrewer Dark2. The former is slightly better for color-blindness, though nothing is really great in that regard. - The errorbar arrows don't look right when the errorbar line width is increased. We could use arrowheads that are centered around the base rather than the tip to get around this. - The number of ticks should be relative to the length of an axis, not fixed as it is now [#5488] - It would be really nice to easily specify a color that comes from the color cycle in the currently active style. We proposed a string syntax of `[n]` where `n` is the index in the color cycle. This could be used as `plot(x, y, '[1]o-')` for example. [#5489] - The new default mathtext that uses DejaVu is nice as it's consistent with all other text, but has some ways in which it is not as legible as Computer Modern. In particular, the integral sign is way too small. Placement and size of sub/superscript isn't great, but could probably be tweaked fairly easily. [#1097] - We need Numpy datetime dtype support. [#1097] - It was noted that the fact that we do image interpolation in RGB space [#5490] - We decided that we probably don't need to address [#1099] about scatter marker size scaling for 2.0. However, as we think about generalizing the color map norms we have now to apply to other dimensions, that would be a good solution to that problem. - The clippedline.py example is now handled internally and should be removed. [#5491] Cheers, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdroettboom at continuum.io Mon Nov 30 16:22:50 2015 From: mdroettboom at continuum.io (Michael Droettboom) Date: Mon, 30 Nov 2015 16:22:50 -0500 Subject: [Matplotlib-devel] matplotlib meeting minutes 2015-11-30 Message-ID: In attendance: Michael Droettboom, Thomas Caswell, Eric Firing, Jens Nielsen The 2.0 style work has opened up a can of worms. When the colors are changed to better defaults, the places where those defaults are not used become more obvious. In fixing those places, it became more obvious that there are shortcomings in how property cyclers are exposed and implemented. Issue #5584 illustrates some of the pain points, and #5577 is a As an action plan: - Expose more about the current property cycler on a given Axes object, so it can be introspected and used as the basis for another cycler. - Cyclers on an Axes should always have colors, even if that color is just black, so that plot types that only care about color can always use it to access a list of colors. - We should provide a mechanism to specify a color that is the nth color in the current property cycle (in the global rcParam). This will go a long way to keeping things that were easy before easy. Cheers, Mike -- Michael Droettboom Continuum Analytics -------------- next part -------------- An HTML attachment was scrubbed... URL: