Menu
▾
▴
matplotlib-devel — matplotlib developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(33) |
Dec
(20) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(44) |
Mar
(51) |
Apr
(43) |
May
(43) |
Jun
(36) |
Jul
(61) |
Aug
(44) |
Sep
(25) |
Oct
(82) |
Nov
(97) |
Dec
(47) |
| 2005 |
Jan
(77) |
Feb
(143) |
Mar
(42) |
Apr
(31) |
May
(93) |
Jun
(93) |
Jul
(35) |
Aug
(78) |
Sep
(56) |
Oct
(44) |
Nov
(72) |
Dec
(75) |
| 2006 |
Jan
(116) |
Feb
(99) |
Mar
(181) |
Apr
(171) |
May
(112) |
Jun
(86) |
Jul
(91) |
Aug
(111) |
Sep
(77) |
Oct
(72) |
Nov
(57) |
Dec
(51) |
| 2007 |
Jan
(64) |
Feb
(116) |
Mar
(70) |
Apr
(74) |
May
(53) |
Jun
(40) |
Jul
(519) |
Aug
(151) |
Sep
(132) |
Oct
(74) |
Nov
(282) |
Dec
(190) |
| 2008 |
Jan
(141) |
Feb
(67) |
Mar
(69) |
Apr
(96) |
May
(227) |
Jun
(404) |
Jul
(399) |
Aug
(96) |
Sep
(120) |
Oct
(205) |
Nov
(126) |
Dec
(261) |
| 2009 |
Jan
(136) |
Feb
(136) |
Mar
(119) |
Apr
(124) |
May
(155) |
Jun
(98) |
Jul
(136) |
Aug
(292) |
Sep
(174) |
Oct
(126) |
Nov
(126) |
Dec
(79) |
| 2010 |
Jan
(109) |
Feb
(83) |
Mar
(139) |
Apr
(91) |
May
(79) |
Jun
(164) |
Jul
(184) |
Aug
(146) |
Sep
(163) |
Oct
(128) |
Nov
(70) |
Dec
(73) |
| 2011 |
Jan
(235) |
Feb
(165) |
Mar
(147) |
Apr
(86) |
May
(74) |
Jun
(118) |
Jul
(65) |
Aug
(75) |
Sep
(162) |
Oct
(94) |
Nov
(48) |
Dec
(44) |
| 2012 |
Jan
(49) |
Feb
(40) |
Mar
(88) |
Apr
(35) |
May
(52) |
Jun
(69) |
Jul
(90) |
Aug
(123) |
Sep
(112) |
Oct
(120) |
Nov
(105) |
Dec
(116) |
| 2013 |
Jan
(76) |
Feb
(26) |
Mar
(78) |
Apr
(43) |
May
(61) |
Jun
(53) |
Jul
(147) |
Aug
(85) |
Sep
(83) |
Oct
(122) |
Nov
(18) |
Dec
(27) |
| 2014 |
Jan
(58) |
Feb
(25) |
Mar
(49) |
Apr
(17) |
May
(29) |
Jun
(39) |
Jul
(53) |
Aug
(52) |
Sep
(35) |
Oct
(47) |
Nov
(110) |
Dec
(27) |
| 2015 |
Jan
(50) |
Feb
(93) |
Mar
(96) |
Apr
(30) |
May
(55) |
Jun
(83) |
Jul
(44) |
Aug
(8) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(3) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
(5) |
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
(7) |
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas C. <tca...@gm...> - 2014-11-01 15:49:12
|
Does anyone protest to removing all of the branches from the main repo except: - master - v1.4.x - v1.4.2-doc Having old branches around can lead to confusion (see https://github.com/matplotlib/matplotlib/pull/3748#issuecomment-61372162). Tom |
|
From: Benjamin R. <ben...@ou...> - 2014-10-30 19:38:18
|
Didn't Numpy have a student, too? On Tue, Oct 28, 2014 at 9:46 PM, Thomas Caswell <tca...@gm...> wrote: > We should ask the scikit-image devs how they managed it last summer as I > think they had at least one student. > > On Wed Oct 22 2014 at 3:33:11 PM Chris Barker <chr...@no...> > wrote: > >> On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...> >> wrote: >> >>> We should be a mentoring organization for next summer. >>> >> >> well, maybe. A few years ago Google shifted to preferring fewer, larger, >> mentoring organizations. So python projects have tended to be handled under >> the PSF-sponsored organization. >> >> Or we could go half-way, and have a numfocus one.. >> >> >>> we need to have a list of viable projects for a >>> >> summer student. I suspect that these will have to have a balance >>> between importance (to justify doing it) and shiny-ness (to get >>> students to _want_ to do it). >>> >> >> It's a good idea to develop this list regardless of the sponsoring >> organization structure. >> >> -Chris >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R (206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> Chr...@no... >> ------------------------------------------------------------ >> ------------------ >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > > |
|
From: Eric F. <ef...@ha...> - 2014-10-29 19:23:23
|
On 2014/10/28, 10:30 PM, Pierre Haessig wrote: > Le 21/10/2014 10:09, Eric Firing a écrit : >> That's the big question: what is the IP status? > So Nathaniel and I asked, and the blog post author, Steve Eddins, took > the time to answer : > > Nathaniel and Pierre—Thanks for your interest in the new parula > colormap. /Parula is the end result of a creative design effort over > an extended period of time. I am pleased that you find it so > appealing. The colormap is, however, MathWorks intellectual > property, and it would not be appropriate or acceptable to copy or > re-use it in non-MathWorks plotting tools./ > > You might look at other sources of high-quality colormaps. I have > listed some in my technical paper on rainbow colormaps, published > earlier this month on mathworks.com. > > > http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/#comment-27702 > > So they claim the IP. Next question is: is this claim valid, and I'm not > a lawyer to answer it. I suspect that the answer could be country specific. Regardless, we should respect their claim. I agree with the basic idea: it was the result of a creative process, and they choose to keep that as proprietary IP. Therefore mpl will not include a clone of this color map. If a user decides to make and use a clone, that's their business, not ours. We shouldn't encourage it. > > The only things that bother me in this IP claim, is the status of all > the plots produced with this colormap. They are in a sense a > /derivative/ work, am I right ? So the question becomes : does Mathworks > owns IP right for all these plots ?! Perhaps they could claim copyright infringement; but from the mpl perspective, I don't think it matters. The question will only arise in practice if a user makes a plot with a clone of parula, and Mathworks chooses to turn it into a legal issue. I think it is unlikely this will happen; but if and when it does, I don't think mpl will be involved. We will not be supplying the colormap or in any way encouraging or condoning its use in mpl, unless and until Mathworks releases it. Eric > > Pierre > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Pierre H. <pie...@cr...> - 2014-10-29 08:30:57
|
Le 21/10/2014 10:09, Eric Firing a écrit :
> That's the big question: what is the IP status?
So Nathaniel and I asked, and the blog post author, Steve Eddins, took
the time to answer :
Nathaniel and Pierre—Thanks for your interest in the new parula
colormap. /Parula is the end result of a creative design effort over
an extended period of time. I am pleased that you find it so
appealing. The colormap is, however, MathWorks intellectual
property, and it would not be appropriate or acceptable to copy or
re-use it in non-MathWorks plotting tools./
You might look at other sources of high-quality colormaps. I have
listed some in my technical paper on rainbow colormaps, published
earlier this month on mathworks.com.
http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/#comment-27702
So they claim the IP. Next question is: is this claim valid, and I'm not
a lawyer to answer it. I suspect that the answer could be country specific.
The only things that bother me in this IP claim, is the status of all
the plots produced with this colormap. They are in a sense a
/derivative/ work, am I right ? So the question becomes : does Mathworks
owns IP right for all these plots ?!
Pierre
|
|
From: Thomas C. <tca...@gm...> - 2014-10-29 01:46:49
|
We should ask the scikit-image devs how they managed it last summer as I think they had at least one student. On Wed Oct 22 2014 at 3:33:11 PM Chris Barker <chr...@no...> wrote: > On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...> > wrote: > >> We should be a mentoring organization for next summer. >> > > well, maybe. A few years ago Google shifted to preferring fewer, larger, > mentoring organizations. So python projects have tended to be handled under > the PSF-sponsored organization. > > Or we could go half-way, and have a numfocus one.. > > >> we need to have a list of viable projects for a >> > summer student. I suspect that these will have to have a balance >> between importance (to justify doing it) and shiny-ness (to get >> students to _want_ to do it). >> > > It's a good idea to develop this list regardless of the sponsoring > organization structure. > > -Chris > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chr...@no... > ------------------------------------------------------------ > ------------------ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Fernando P. <fpe...@gm...> - 2014-10-28 18:10:24
|
Hi folks, a colleague from NCAR in Boulder just sent me this link about a conference they are organizing in the spring: https://sea.ucar.edu/conference/2015 I figured this might be of interest to many on these lists. The actual call isn't up yet, so if you're interested, watch that site for an upcoming call when they post it (I'm not directly involved, just passing the message along). Cheers f -- Fernando Perez (@fperez_org; http://fperez.org) fperez.net-at-gmail: mailing lists only (I ignore this when swamped!) fernando.perez-at-berkeley: contact me here for any direct mail |
|
From: Benjamin R. <ben...@ou...> - 2014-10-28 16:16:02
|
Yeah, put together a PR, and we can evaluate it better that way. I think
the current plot directive behavior might need this sort of tightening up
On Sun, Oct 26, 2014 at 1:22 AM, Matthew Brett <mat...@gm...>
wrote:
> Sorry - I accidentally sent this reply just to Nathaniel - returning
> to this as it bit me again:
>
> On 7/14/14, Nathaniel Smith <nj...@po...> wrote:
> > Wouldn't a better default be to just close all figures when they're
> > displayed? It can't be common that someone wants to show the same plot
> > repeatedly (and if they do that could have an option)...?
>
> Yes, I think that would be a better default.
>
> You mean that if :context: is true, then always do something like
> ``plt.close('all')`` before running the relevant code and looking for
> figures.
>
> It would change the current behavior, but I agree that would be better.
>
> Anyone disagree?
>
> If not, I will make a pull request to change the behavior...
>
> Cheers,
>
> Matthew
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
|
|
From: Jouni K. S. <jk...@ik...> - 2014-10-27 14:33:04
|
Thomas Caswell <tca...@gm...> writes: > The user mailing list is still a going concern, the SF archives are just > broken. They know (and the archive pages are _less_ broken than they used > to be), but have not fixed it yet. How about linking to the gmane.org archives? http://news.gmane.org/gmane.comp.python.matplotlib.general http://news.gmane.org/gmane.comp.python.matplotlib.devel -- Jouni K. Seppänen http://www.iki.fi/jks |
|
From: Andy B. <an...@in...> - 2014-10-27 13:45:26
|
Thanks Thomas, that's great to know. I'll try using a newer version from
Github, and nice that the correction will gradually propagate to our users.
I'll ask my other questions on the user list; thanks for explaining!
Andy
On 26/10/14 16:18, Thomas Caswell wrote:
> Andy,
>
> The issue of the axes frame corners _should_ be fixed in 1.4
>
> The user mailing list is still a going concern, the SF archives are just
> broken. They know (and the archive pages are _less_ broken than they
> used to be), but have not fixed it yet.
>
> Tom
>
> On Sun, Oct 26, 2014 at 11:50 AM, Andy Buckley <an...@in...
> <mailto:an...@in...>> wrote:
>
> Hi all,
>
> I have a question/request about improving a minor aspect of plot
> cosmetics, namely that axis spines seem to be rendered as 4 individual
> lines, meaning that the corners of the axes boundary do not match up
> with a neat corner but have a "stair" appearance. I've attached a
> screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
> from Ubuntu 14.04... so apologies if it's already fixed in the latest
> 1.4.x versions. This effect is also visible in PNG output, as just a
> couple of pixels in the corners that look "ragged". Would it be possible
> to tidy this up... or point me to where in the code this rendering is
> done, if it's something easy that I could maybe help with?
>
> At the same time, I note in this zoom that the axis is showing tick
> marks at the very end(s) of the axis, where they overlap with the other
> axis/plot boundary line: is there an automatic way to elide tick marks
> in that redundant position?
>
> Apologies if this isn't a good place for these queries/requests -- I had
> a look at the matplotlib-user and -announce list archives linked from
> the web page and they seem to have gone defunct in 2012, hence coming
> here. I am happy to do a bit of development to address little cosmetic
> tweaks like this, but am not yet familiar with MPL internals.
>
> Thanks!
> Andy
>
> PS. I also have a question about how to enable old-style figures in a
> font when using the TeX/PGF rendering backed, cf.
> \usepackage[osf]{mathpazo}, but I'll wait to see if this is an
> appropriate place for such questions before troubling you with that!
>
> --
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> <mailto:Mat...@li...>
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> --
> Thomas Caswell
> tca...@gm... <mailto:tca...@gm...>
--
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
|
|
From: Eric F. <ef...@ha...> - 2014-10-26 19:26:35
|
On 2014/10/26, 4:52 AM, Thomas Caswell wrote: > https://github.com/HamsterHuey/easyplot?utm_content=buffer48700&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer > > I have not looked at it carefully, but it is something we might want to > be aware of when thinking about API re-designs. Yes, this is well worth keeping in mind. It looks like there are some very good ideas here. Eric > > Tom > > -- > Thomas Caswell > tca...@gm... <mailto:tca...@gm...> > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Thomas C. <tca...@gm...> - 2014-10-26 16:18:12
|
Andy,
The issue of the axes frame corners _should_ be fixed in 1.4
The user mailing list is still a going concern, the SF archives are just
broken. They know (and the archive pages are _less_ broken than they used
to be), but have not fixed it yet.
Tom
On Sun, Oct 26, 2014 at 11:50 AM, Andy Buckley <an...@in...>
wrote:
> Hi all,
>
> I have a question/request about improving a minor aspect of plot
> cosmetics, namely that axis spines seem to be rendered as 4 individual
> lines, meaning that the corners of the axes boundary do not match up
> with a neat corner but have a "stair" appearance. I've attached a
> screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
> from Ubuntu 14.04... so apologies if it's already fixed in the latest
> 1.4.x versions. This effect is also visible in PNG output, as just a
> couple of pixels in the corners that look "ragged". Would it be possible
> to tidy this up... or point me to where in the code this rendering is
> done, if it's something easy that I could maybe help with?
>
> At the same time, I note in this zoom that the axis is showing tick
> marks at the very end(s) of the axis, where they overlap with the other
> axis/plot boundary line: is there an automatic way to elide tick marks
> in that redundant position?
>
> Apologies if this isn't a good place for these queries/requests -- I had
> a look at the matplotlib-user and -announce list archives linked from
> the web page and they seem to have gone defunct in 2012, hence coming
> here. I am happy to do a bit of development to address little cosmetic
> tweaks like this, but am not yet familiar with MPL internals.
>
> Thanks!
> Andy
>
> PS. I also have a question about how to enable old-style figures in a
> font when using the TeX/PGF rendering backed, cf.
> \usepackage[osf]{mathpazo}, but I'll wait to see if this is an
> appropriate place for such questions before troubling you with that!
>
> --
> Dr Andy Buckley, Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
--
Thomas Caswell
tca...@gm...
|
|
From: Andy B. <an...@in...> - 2014-10-26 15:50:36
|
Hi all,
I have a question/request about improving a minor aspect of plot
cosmetics, namely that axis spines seem to be rendered as 4 individual
lines, meaning that the corners of the axes boundary do not match up
with a neat corner but have a "stair" appearance. I've attached a
screenshot from a zoomed PDF showing this effect, made with MPL 1.3.1
from Ubuntu 14.04... so apologies if it's already fixed in the latest
1.4.x versions. This effect is also visible in PNG output, as just a
couple of pixels in the corners that look "ragged". Would it be possible
to tidy this up... or point me to where in the code this rendering is
done, if it's something easy that I could maybe help with?
At the same time, I note in this zoom that the axis is showing tick
marks at the very end(s) of the axis, where they overlap with the other
axis/plot boundary line: is there an automatic way to elide tick marks
in that redundant position?
Apologies if this isn't a good place for these queries/requests -- I had
a look at the matplotlib-user and -announce list archives linked from
the web page and they seem to have gone defunct in 2012, hence coming
here. I am happy to do a bit of development to address little cosmetic
tweaks like this, but am not yet familiar with MPL internals.
Thanks!
Andy
PS. I also have a question about how to enable old-style figures in a
font when using the TeX/PGF rendering backed, cf.
\usepackage[osf]{mathpazo}, but I'll wait to see if this is an
appropriate place for such questions before troubling you with that!
--
Dr Andy Buckley, Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow / PH Dept, CERN
|
|
From: Thomas C. <tca...@gm...> - 2014-10-26 14:52:22
|
https://github.com/HamsterHuey/easyplot?utm_content=buffer48700&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer I have not looked at it carefully, but it is something we might want to be aware of when thinking about API re-designs. Tom -- Thomas Caswell tca...@gm... |
|
From: Matthew B. <mat...@gm...> - 2014-10-26 05:22:56
|
Sorry - I accidentally sent this reply just to Nathaniel - returning
to this as it bit me again:
On 7/14/14, Nathaniel Smith <nj...@po...> wrote:
> Wouldn't a better default be to just close all figures when they're
> displayed? It can't be common that someone wants to show the same plot
> repeatedly (and if they do that could have an option)...?
Yes, I think that would be a better default.
You mean that if :context: is true, then always do something like
``plt.close('all')`` before running the relevant code and looking for
figures.
It would change the current behavior, but I agree that would be better.
Anyone disagree?
If not, I will make a pull request to change the behavior...
Cheers,
Matthew
|
|
From: Thomas C. <tca...@gm...> - 2014-10-26 03:47:13
|
Hot on the tails of v1.4.1, we have a v1.4.2 due to an error in the boxplot api in pyplot.py The only changes between 1.4.1 and 1.4.2 are: - corrected boxplot in pyplot.py - added extra paths to default search paths for freetype Tom -- Thomas Caswell tca...@gm... |
|
From: Thomas C. <tca...@gm...> - 2014-10-23 13:45:25
|
Yes, pyplot didn't get regenerated after one of the boxplot fixes. On Thu, Oct 23, 2014 at 9:17 AM, Sandro Tosi <mo...@de...> wrote: > I see a 1.4.2 already? > > On Sun, Oct 19, 2014 at 3:54 AM, Thomas Caswell <tca...@gm...> wrote: >> Hello, >> >> We are pleased to announce the release of matplotlib 1.4.1. >> >> This is a bug-fix release for the 1.4 series. >> >> - reverts the changes to interactive plotting so ion will work as >> before in all cases fixed boxplot regressions >> - fixes for finding freetype and libpng >> - sundry unicode fixes (looking up user folders, importing >> seaborn/pandas/networkx with macosx backend) >> - nbagg works with python 3 + new font awesome >> - fixed saving dialogue in QT5 >> >> Source tarballs are available on sourceforge, github, and pypi. In >> addition wheels for both mac and windows are available on both pypi >> and source forge and windows executable installers are available on >> source forge. >> >> http://matplotlib.org/downloads.html >> >> https://pypi.python.org/pypi/matplotlib/1.4.1 >> >> The matplotlib dev team >> >> ------------------------------------------------------------------------------ >> Comprehensive Server Monitoring with Site24x7. >> Monitor 10 servers for $9/Month. >> Get alerted through email, SMS, voice calls or mobile push notifications. >> Take corrective actions from your mobile device. >> http://p.sf.net/sfu/Zoho >> _______________________________________________ >> Matplotlib-users mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-users > > -- > Sandro Tosi (aka morph, morpheus, matrixhasu) > My website: http://matrixhasu.altervista.org/ > Me at Debian: http://wiki.debian.org/SandroTosi > > ------------------------------------------------------------------------------ > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel -- Thomas Caswell tca...@gm... |
|
From: Sandro T. <mo...@de...> - 2014-10-23 13:18:32
|
I see a 1.4.2 already? On Sun, Oct 19, 2014 at 3:54 AM, Thomas Caswell <tca...@gm...> wrote: > Hello, > > We are pleased to announce the release of matplotlib 1.4.1. > > This is a bug-fix release for the 1.4 series. > > - reverts the changes to interactive plotting so ion will work as > before in all cases fixed boxplot regressions > - fixes for finding freetype and libpng > - sundry unicode fixes (looking up user folders, importing > seaborn/pandas/networkx with macosx backend) > - nbagg works with python 3 + new font awesome > - fixed saving dialogue in QT5 > > Source tarballs are available on sourceforge, github, and pypi. In > addition wheels for both mac and windows are available on both pypi > and source forge and windows executable installers are available on > source forge. > > http://matplotlib.org/downloads.html > > https://pypi.python.org/pypi/matplotlib/1.4.1 > > The matplotlib dev team > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Matplotlib-users mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-users -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi |
|
From: Chris B. <chr...@no...> - 2014-10-22 19:32:26
|
On Sat, Oct 18, 2014 at 8:50 AM, Thomas Caswell <tca...@gm...> wrote: > We should be a mentoring organization for next summer. > well, maybe. A few years ago Google shifted to preferring fewer, larger, mentoring organizations. So python projects have tended to be handled under the PSF-sponsored organization. Or we could go half-way, and have a numfocus one.. > we need to have a list of viable projects for a > summer student. I suspect that these will have to have a balance > between importance (to justify doing it) and shiny-ness (to get > students to _want_ to do it). > It's a good idea to develop this list regardless of the sponsoring organization structure. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chr...@no... |
|
From: Nathaniel S. <nj...@po...> - 2014-10-21 19:56:54
|
On Tue, Oct 21, 2014 at 8:09 PM, Eric Firing <ef...@ha...> wrote: > On 2014/10/21, 6:27 AM, Nathaniel Smith wrote: >> On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig >> <pie...@cr...> wrote: >>> Hi, >>> >>> Matlab is now shipping with a new default colormap, named "parula" >>> [1,2]. It is meant to overcome the many issues of the current default >>> "jet". It seems that the RGB values of this new colormap are already >>> onnline [3]. >>> >>> So my question is: >>> * is it worth adding this parula in the Matplotlib colormap collection ? >>> (I think it is) >>> * is there any copyright issue with that ? (I have no idea how >>> copyrightable a list of numbers is !) >> >> The general rule is that copyright requires "creative expression". >> This is a pretty marginal case at best, since that the colormap >> appears to have been derived by solving an optimization problem, but >> worst case we could always re-solve that optimization problem >> ourselves. (I've played before with using CAM02-UCS to automatically >> generate perceptually uniform colormaps - it's not terribly difficult >> to do.) >> > There are additional considerations, such as working well for the most > common form of color-blindness, providing as much resolution as > possible, and being aesthetically pleasing to most people. Sure, but the first two of those are just extra constraints on the optimization. Apparently they'll be making another blog post soon describing the actual constraints they used. -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org |
|
From: Eric F. <ef...@ha...> - 2014-10-21 19:09:29
|
On 2014/10/21, 6:27 AM, Nathaniel Smith wrote: > On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig > <pie...@cr...> wrote: >> Hi, >> >> Matlab is now shipping with a new default colormap, named "parula" >> [1,2]. It is meant to overcome the many issues of the current default >> "jet". It seems that the RGB values of this new colormap are already >> onnline [3]. >> >> So my question is: >> * is it worth adding this parula in the Matplotlib colormap collection ? >> (I think it is) >> * is there any copyright issue with that ? (I have no idea how >> copyrightable a list of numbers is !) > > The general rule is that copyright requires "creative expression". > This is a pretty marginal case at best, since that the colormap > appears to have been derived by solving an optimization problem, but > worst case we could always re-solve that optimization problem > ourselves. (I've played before with using CAM02-UCS to automatically > generate perceptually uniform colormaps - it's not terribly difficult > to do.) > > -n > There are additional considerations, such as working well for the most common form of color-blindness, providing as much resolution as possible, and being aesthetically pleasing to most people. Eric |
|
From: Nathaniel S. <nj...@po...> - 2014-10-21 16:50:31
|
On Tue, Oct 21, 2014 at 8:50 AM, Pierre Haessig <pie...@cr...> wrote: > Hi, > > Matlab is now shipping with a new default colormap, named "parula" > [1,2]. It is meant to overcome the many issues of the current default > "jet". It seems that the RGB values of this new colormap are already > onnline [3]. > > So my question is: > * is it worth adding this parula in the Matplotlib colormap collection ? > (I think it is) > * is there any copyright issue with that ? (I have no idea how > copyrightable a list of numbers is !) The general rule is that copyright requires "creative expression". This is a pretty marginal case at best, since that the colormap appears to have been derived by solving an optimization problem, but worst case we could always re-solve that optimization problem ourselves. (I've played before with using CAM02-UCS to automatically generate perceptually uniform colormaps - it's not terribly difficult to do.) -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org |
|
From: Eric F. <ef...@ha...> - 2014-10-21 08:09:12
|
On 2014/10/20, 9:50 PM, Pierre Haessig wrote: > Hi, > > Matlab is now shipping with a new default colormap, named "parula" > [1,2]. It is meant to overcome the many issues of the current default > "jet". It seems that the RGB values of this new colormap are already > onnline [3]. > > So my question is: > * is it worth adding this parula in the Matplotlib colormap collection ? > (I think it is) Yes, *if* the answer to your next question allows it. > * is there any copyright issue with that ? (I have no idea how > copyrightable a list of numbers is !) That's the big question: what is the IP status? Eric > > (I'm not speeking of changing the *default* colormap since this is > already discussed here https://github.com/matplotlib/matplotlib/issues/875) > > best, > Pierre > > 1 > http://blogs.mathworks.com/steve/2014/10/13/a-new-colormap-for-matlab-part-1-introduction/ > 2 > http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/ > 3 > http://www.mathworks.com/matlabcentral/answers/158575-values-fo-colormap-parula > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Pierre H. <pie...@cr...> - 2014-10-21 07:50:53
|
Hi, Matlab is now shipping with a new default colormap, named "parula" [1,2]. It is meant to overcome the many issues of the current default "jet". It seems that the RGB values of this new colormap are already onnline [3]. So my question is: * is it worth adding this parula in the Matplotlib colormap collection ? (I think it is) * is there any copyright issue with that ? (I have no idea how copyrightable a list of numbers is !) (I'm not speeking of changing the *default* colormap since this is already discussed here https://github.com/matplotlib/matplotlib/issues/875) best, Pierre 1 http://blogs.mathworks.com/steve/2014/10/13/a-new-colormap-for-matlab-part-1-introduction/ 2 http://blogs.mathworks.com/steve/2014/10/20/a-new-colormap-for-matlab-part-2-troubles-with-rainbows/ 3 http://www.mathworks.com/matlabcentral/answers/158575-values-fo-colormap-parula |
|
From: Benjamin R. <ben...@ou...> - 2014-10-20 15:31:35
|
Sigh, I think that might have been set up by John. Ben Root On Fri, Oct 17, 2014 at 11:36 PM, Thomas Caswell <tca...@gm...> wrote: > Does anyone on the list know the pass word (or control the recovery > email address) for the matplotlib gmail account? I would like to set > up google analytics on our web site to see a) how much traffic we get > and b) where people are going. > > Tom > > -- > Thomas Caswell > tca...@gm... > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://p.sf.net/sfu/Zoho > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > |
|
From: Joel B. M. <jo...@ki...> - 2014-10-20 14:10:46
|
Hi, I'm working on https://github.com/matplotlib/matplotlib/pull/3393 and poking around at _alpha, _forced_alpha, _rgb, and _orig_color members of GraphicsContextBase. I see quite a number of issues: 1) "_rgb" is (almost) always a 4 tuple which may be better named "_rgba". 2) "_orig_color" takes on many different value types -- I think it can be deleted and the "_rgb" variable used in the one place it is needed. 3) "get_rgb" documents that it returns a 3 or 4 tuple. In fact, I think it returns a 4-tuple (see point 1). backend_ps.py is a particularly scary example of the 3 tuple interpretation being taken with-out further thought. 4) I suppose there is a good reason for the existence of "_forced_alpha" and "_alpha", but I don't understand it. Since "_rgb" is a 4-tuple in common (all?) usage, why can't "set_alpha" merely set "_rgb[3]"? I'm going to be pushing something more to my branch at https://github.com/matplotlib/matplotlib/pull/3393 -- deleting "_orig_color" and renaming "_rgb" to "_rgba". But even with these changes, the points above give me pause. (I'm also sitting on irc right now asking these same questions). Joel |
127 messages has been excluded from this view by a project administrator.
