[matplotlib-devel] whats_new and api_changes
Fellow developers, I know we are now encouraged when writing a PR not to alter doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to create files in the doc/users/whats_new and doc/api/api_changes directories instead. When building the master branch docs I was expecting the contents of these new files to be automagically incorporated in the appropriate doc sections, but this does not happen on my development system (ubuntu 14.04, python 2.7, sphinx 1.2.2). I figure either I am doing something wrong, or this is a bug, or there is manual process at release time to cut and paste the new files into the parent files. Which is it? Ian -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On Nov 26, 2014 10:04 PM, "Nathaniel Smith" wrote: > > On Wed, Nov 26, 2014 at 9:30 AM, Todd wrote: > > On Sat, Nov 22, 2014 at 12:22 AM, Nathaniel Smith wrote: > >> > >> - Default line colors: The rgbcmyk color cycle for line plots doesn't > >> appear to be based on any real theory about visualization -- it's just > >> the corners of the RGB color cube, which is a highly perceptually > >> non-uniform space. The resulting lines aren't terribly high contrast > >> against the default white background, and the different colors have > >> varying luminance that makes some lines "pop out" more than others. > >> > >> Seaborn's default is to use a nice isoluminant variant on matplotlib's > >> default: > >> > >> http://web.stanford.edu/~mwaskom/software/seaborn/tutorial/aesthetics.html > >> ggplot2 uses isoluminant colors with maximally-separated hues, which > >> also works well. E.g.: > >> > >> http://www.cookbook-r.com/Graphs/Colors_%28ggplot2%29/ggplot2_scale_hue_colors_l45.png > > > > About this, I am not expert so forgive me if this is nonsensical. However, > > it would seem to me that these requirements are basically the same as the > > requirements for the new default colormap that prompted this whole > > discussion. So, rather than create two inconsistent set of colors that > > accomplish similar goals, might it be better to instead use the default > > colormap for the line colors? You could pick "N" equally-spaced colors from > > the colormap and use those as the line colors. > > The main differences in requirements are: > - for the color cycle, you want isoluminant colors, to avoid the issue > where one line is glaring bright red and one is barely-visible-grey. > For general-purpose 2d colormaps, though, you almost always want the > luminance to vary to help distinguish colors from each other. If you used isoluminance colors for the lines, wouldn't that mean a plot printed in grayscale would have all lines be the same shade of gray? -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] whats_new and api_changes
There should be an automatic process, but no one has written it yet. I think IPython has code we can adapt in their doc build process. I had planned to deal with this when we cut the next minor/major release. Tom On Thu, Nov 27, 2014, 04:18 Ian Thomas wrote: > Fellow developers, > > I know we are now encouraged when writing a PR not to alter > doc/users/whats_new.rst and doc/api/api_changes.rst directly, but rather to > create files in the doc/users/whats_new and doc/api/api_changes directories > instead. When building the master branch docs I was expecting the contents > of these new files to be automagically incorporated in the appropriate doc > sections, but this does not happen on my development system (ubuntu 14.04, > python 2.7, sphinx 1.2.2). > > I figure either I am doing something wrong, or this is a bug, or there is > manual process at release time to cut and paste the new files into the > parent files. Which is it? > > Ian > > -- > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=157005751&; > iu=/4140/ostg.clktrk___ > Matplotlib-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] whats_new and api_changes
On 27 November 2014 at 16:16, Thomas Caswell wrote: > There should be an automatic process, but no one has written it yet. I > think IPython has code we can adapt in their doc build process. I had > planned to deal with this when we cut the next minor/major release. > > Tom > Thanks for letting me know Tom. Ian -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] whats_new and api_changes
For reference, the IPython script is in tools/update_whatsnew.py On Thu Nov 27 2014 at 11:58:40 AM Ian Thomas wrote: > On 27 November 2014 at 16:16, Thomas Caswell wrote: > >> There should be an automatic process, but no one has written it yet. I >> think IPython has code we can adapt in their doc build process. I had >> planned to deal with this when we cut the next minor/major release. >> >> Tom >> > > Thanks for letting me know Tom. > > Ian > -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk___ Matplotlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
Re: [matplotlib-devel] Better defaults all around?
On Thu, Nov 27, 2014 at 9:54 AM, Todd wrote:
>
> On Nov 26, 2014 10:04 PM, "Nathaniel Smith" wrote:
>>
>> The main differences in requirements are:
>> - for the color cycle, you want isoluminant colors, to avoid the issue
>> where one line is glaring bright red and one is barely-visible-grey.
>> For general-purpose 2d colormaps, though, you almost always want the
>> luminance to vary to help distinguish colors from each other.
>
> If you used isoluminance colors for the lines, wouldn't that mean a plot
> printed in grayscale would have all lines be the same shade of gray?
Yes. But IME it's very difficult to use greyscale alone to distinguish
between multiple plot lines no matter what: you can't go much beyond 2
lines before you either end up with hard-to-see lines (b/c they don't
have enough contrast with the white background) or the lines become
nigh-indistinguishable ("which one is the slightly-darker grey?"). And
if you have substantial luminance variation to make the greyscale
work, then the color images end up looking really weird (the scarlet
versus faint-yellow problem, where you end up emphasizing one set of
data over another -- emphasis should be done on purpose! in
matplotlib's current color cycle the yellow and cyan tend to
disappear).
If you're worried about greyscale then IMHO you should use different
line styles (solid/dashed/dotted/...) and/or use solid black for
everything and label the lines directly.
Which isn't to say that there's never any value in picking line colors
from a colormap, it's just more complicated than it seems :-).
-n
--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
___
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
