Do remember that I have a PR to add linestyle cycling, which would greatly
mitigate problems for colorblindness and non-color publications.
I also prefer it for slideshows as projectors at conferences tend to have
crappy colors anyway (was at a radar conference when the projector's red
crapped out
Hello all,
We are pleased to announce the release of matplotlib v1.4.3!
Wheels, windows binaries and the source tarball are available through both
source-forge [1] and pypi (via pip). Additionally the source is available
tarball is available from github [2] and mac-wheels from
http://wheels.sci
See [here](http://nbviewer.ipython.org/gist/mwaskom/6a43a3b94eca4a9e2e8b)
for a quick and dirty implementation that should get a general idea. This
probably ins't the best way to do it -- anyone should feel free to build on
this.
On Mon, Feb 16, 2015 at 3:38 PM, Eric Firing wrote:
> On 2015/02/1
It's helped by pulling the green towards blue and the red towards yellow,
but they are probably the hardest to distinguish in the set.
Which emphasizes that, while it's good to start with a colorblind-friendly
set of colors, the person making the figure also has the responsibility to
choose how to
On 2015/02/16 1:29 PM, Michael Waskom wrote:
> Nathaniel's January 9 message in that thread (can't figure out how to
> link to it in the archives) had a suggestion that I thought was very
> promising, to do something similar to Parula but rotate around the hue
> circle the other direction so that
On 2015/02/16 1:19 PM, Michael Waskom wrote:
> Here are two palettes that are optimized for colorblindness:
> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/#a-colorblind-friendly-palette
>
Strange--they have both red and green, so I would never have expected
them to work. The yellow look
On Mon, Feb 16, 2015 at 2:01 PM, Eric Firing wrote:
>
> Here is what I think is the most recent extensive thread:
> http://comments.gmane.org/gmane.comp.python.matplotlib.devel/13122
...
> 1) A greyscale has been proposed; it satisfies several of the criteria
> very well, but misses by omitti
On Mon, Feb 16, 2015 at 3:19 PM, Michael Waskom
wrote:
> Here are two palettes that are optimized for colorblindness
actually I should say I have no idea if those are optimal, but the
simulations do suggest they work well.
On Mon, Feb 16, 2015 at 3:15 PM, Eric Firing wrote:
> Does anyone have a suggestion for a colorblind-friendly cycle? Maybe
> omit the green and tack a gray on the end? I haven't checked, so I
> don't know if this would work well.
>
Here are two palettes that are optimized for colorblindness:
h
On 2015/02/16 12:42 PM, Paul Hobson wrote:
> There are several cycles in seaborn. Is it safe to assume that you mean
> the 'deep' palette?
Yes, in the sense that when I wrote the message I was just looking at
seaborn's tutorial showing the default, which is 'deep'--but I didn't
know it then.
A
There are several cycles in seaborn. Is it safe to assume that you mean the
'deep' palette?
On Mon, Feb 16, 2015 at 14:40 Eric Firing wrote:
> On 2015/02/16 12:01 PM, Eric Firing wrote:
>
> >
> > Proposals for the new color cycle for line plots?
>
> Here is a proposal: we simply adopt seaborn's c
On 2015/02/16 12:01 PM, Eric Firing wrote:
>
> Proposals for the new color cycle for line plots?
Here is a proposal: we simply adopt seaborn's cycle.
Eric
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT S
For a long time there has been discussion of replacing the matplotlib
default color map and color cycle, but we still haven't done it. We need
a clear set of criteria, and a small set of good alternatives, leading
to a decision, a PR, and a release. Now is the time.
Here is what I think is the
Hi,
On Mon, Feb 16, 2015 at 1:26 PM, Paul Kuin wrote:
> Ah, since it is a proper name it should be capitalised, but it never was. I
> think that it should remain uncapitalised and that you want to propose an
> alternative, like a change in type for the proper name matplotlib. Could be
> typescri
On 16 February 2015 at 10:53, Nelle Varoquaux
wrote:
> 2. you are used to having sentences start with capital letter, but
> this is mostly cultural. German People capitalize almost all Words in
> a Sentence. It just looks weird too…
>
FWIW, I tried naming a few small projects with all-lowercase
Perhaps this is a bit a of tangent, but what is exactly is the distinction
between the project and the software?
Is it as simple as: software = code and project = code + mailing list +
documentation + managing issues on github?
On Mon, Feb 16, 2015 at 11:04 AM, Matthew Brett
wrote:
> Hi,
>
> On
Hi,
On Mon, Feb 16, 2015 at 10:53 AM, Nelle Varoquaux
wrote:
>
> IMO, never.
Rationale, please?
>>>
>>>
>>> Consistency: it is never capitalized in matplotlib's documentation.
>>
>>
>> True, and a valid point--but we could easily change that. Wouldn't it make
>> it bit mor
IMO, never.
>>>
>>>
>>> Rationale, please?
>>
>>
>> Consistency: it is never capitalized in matplotlib's documentation.
>
>
> True, and a valid point--but we could easily change that. Wouldn't it make
> it bit more readable if sentences always started with a capital letter?
> Starting wi
On 2015/02/16 8:38 AM, Nelle Varoquaux wrote:
> On 16 February 2015 at 19:36, Eric Firing wrote:
>> On 2015/02/16 8:23 AM, Nelle Varoquaux wrote:
>>> IMO, never.
>>
>> Rationale, please?
>
> Consistency: it is never capitalized in matplotlib's documentation.
True, and a valid point--but we could
On Feb 16, 2015 10:35 AM, "Eric Firing" wrote:
>
> On 2015/02/16 8:16 AM, Benjamin Root wrote:
> > I am in the final rounds of edits for my book and a question has come up
> > between me and the editors. When should the matplotlib be capitalized?
> >
> > 1) never
> > 2) mostly never (even in the b
On 16 February 2015 at 19:36, Eric Firing wrote:
> On 2015/02/16 8:23 AM, Nelle Varoquaux wrote:
>> IMO, never.
>
> Rationale, please?
Consistency: it is never capitalized in matplotlib's documentation.
>
> Eric
>
> --
>
On 2015/02/16 8:23 AM, Nelle Varoquaux wrote:
> IMO, never.
Rationale, please?
Eric
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashb
On 2015/02/16 8:16 AM, Benjamin Root wrote:
> I am in the final rounds of edits for my book and a question has come up
> between me and the editors. When should the matplotlib be capitalized?
>
> 1) never
> 2) mostly never (even in the beginning of a sentence), except when used
> in a title
> 3) us
IMO, never.
On 16 February 2015 at 19:16, Benjamin Root wrote:
> I am in the final rounds of edits for my book and a question has come up
> between me and the editors. When should the matplotlib be capitalized?
>
> 1) never
> 2) mostly never (even in the beginning of a sentence), except when used
I am in the final rounds of edits for my book and a question has come up
between me and the editors. When should the matplotlib be capitalized?
1) never
2) mostly never (even in the beginning of a sentence), except when used in
a title
3) usually never, except at the beginning of a sentence and in
At risk of sounding defensive, all of the core developers are working mpl
on a mostly volunteer basis and only have so much bandwidth. This leads to
both thing falling through the cracks (we have close to 100 open PRs, that
is _way_ too many) and major re-factors (which every one agrees should be
d
Dear Sebastian,
I agree with your impression. I made a pull request for some axis
functionality (logit scales) and the PR got lost. I am convinced that:
1. working on things like axes, ticker, scales, locators would be a lot
easier with a little refactoring of the code
2. with a more modular cod
I'm a newcomer to the MPL code, and getting an overview is not easy.
Especially the API part of the documentation [1] has a lot of room for
improvement. The functionality of the MPL sources seems to be
scattered quite loosely among the sources and their structure is
directly mirrored in the doc. So
28 matches
Mail list logo
