On Wed, Jan 4, 2012 at 9:33 PM, Ryan May <rma...@gmail.com> wrote:
> On Jan 4, 2012, at 20:52, Benjamin Root <ben.r...@ou.edu> wrote:
>
> > Hello all,
> >
> > So, I am getting to the point where I need to implement a color cycling
> mechanism throughout pyplot. So, before I get too deep in implementing it,
> I have some thoughts that I need feedback on.
> >
> > 1) Not all plotting functions use color cycling right now. Currently,
> only plot() and any function that calls plot in its process (such as
> errorbar()). Glaring omissions are bar() and scatter(), and pie() could
> also benefit from having a uniform cycling mechanism. So, the issue going
> forward is, do we want to enable common cycling for all the pyplot/axes
> plotting functions which would require updating the test images and break
> backwards compatibility (in a sense), or do we want to have a per-function
> default rcparams that would contain one-element cycles that would
> effectively maintain current drawing results?
> >
> > 2) I also have the need to implement line-style cycling for b&w
> publications. Of course if I implement that, then why not hatch-cycling?
> marker-cycling? I have seen use-cases for all of these, and I am
> considering how to have a generalized framework for this. So my question
> is, what attributes would we like to see cycle-able? Here is a short list
> and some usecases I have come up with. Please extend this with ideas of
> your own.
> >
> > color - plot(), errorbar(), scatter(), bar(), hist(), pie(), stem()
> > linestyle - plot(), errorbar(), stem()
> > hatch - bar(), hist(), pie()
> > marker - plot(), errorbar(), scatter(), stem()
> >
> > linewidth? facecolor/edgecolor? joinstyle?
> >
> > 3) rcparam names. I was thinking about how to name these cycles in the
> matplotlibrc file. Possibly:
> >
> > cycle.colors
> > cycle.linestyles
> > cycle.hatches
> > cycle.markers
> >
> > And these would represent the global default, meanwhile,
> function-specific cycles could be given by:
> >
> > cycle.colors.pie
> > cycle.colors.bar
> > cycle.linestyles.plot
> > cycle.linestyles.errorbar
> >
> > I was thinking that in code, one would access the full name attribute
> for the function, and I would extend the __get__ function to intelligently
> fall back to the global default if the full-name attribute is not
> specified. However, would there be confusion in a situation such as a
> person who wanted to use barh() but only had specified cycle.colors.bar?
> >
> > 4) Ultimately, my goal is to be able to create some typical profiles
> that have useful cycle specs, and possibly make some available as
> convenience functions, such as a b&w mode. Such a mode would set the
> default colormap to a grayscale-friendly colorscale, and use line style,
> hatch and marker cycles instead of a full color cycle.
> >
> > Thoughts? Comments?
>
> My first thought is that maybe we need an object to collect and abstract
> all of these style attributes, and then cycle through a sequence of those.
> In the future we could move the matplotlib API to use such an object
> instead of the billion parameters that are individually passed now.
>
>
+10000
> Just 0.02 to distract me from the dissertation.
>
>
Oh yeah... I got one of those to complete as well...
Ben Root
Ryan
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Matplotlib-users mailing list
Matplotlib-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-users
