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: