Hi Damon,
Thanks for your thoughts on how this should fit in with MPLs API. My $0.02:
What would feel more natural is if I could do the following:
> f = Facet(...)
> ax.facet(f, 'scatter')
>
Three things about this style bother me:
1. It seems too verbose ("facet" gets typed a lot -- 4 times if you call
the variable facet instead of f).
2. I don't love having to invoke methods like 'scatter' by naming them as a
string. It feels kludgy for some reason.
3. I think the axes plotting methods belong to a different category than a
facet. The former are "artist factories" that add artists like
lines/patches/etc to axes. A facet, on the other hand, is a higher-level
"axes factory" that creates multiple subplot axes objects. Making facet an
axes method seems out of place, since I think it's more natural to have a
separate axes for each subplot. What do you think?
Admittedly, functions like plot() are a total disaster, they take a
> plethora of different argument orders and types and try to conform to many
> calling signatures at once. Specifically, the way the data is passed to
> the plotting method varies wildly.
>
Good point. My implementation relies on a pretty general (but not universal
or formally documented) property of most plot functions: the first
arguments for each method are usually data arrays. This means that, in most
situations, Facet can extract the appropriate subset of the original data,
pass them as the first arguments to an axes method, and this will "do the
right thing". This works most of the time, but might be considered a hack.
The iterator interface is meant to address the cases where this doesn't
work (for example, calling Facet.imshow or Facet.streamplot doesn't work).
I think your Faceted plotting API supports exactly what I'm hoping to see
> matplotlib will move towards:
>
> class Facet(matplotlib.Plottable)
> def __init__(self, ...)
> ...
>
> f = Facet(...)
> ax.scatter(f)
>
This interface addresses my first two concerns above, but not the third --
I don't think that all facets should live in a single axes. I'm not sure
what you envision the Plottable interface looks like, but I imagine it
provides methods to extract data, so that you can plot things besides
arrays. In this case, I think a facet could *use* Plottables when building
subplots, but I'm not sure a facet *is* a plottable.
Tangential to the notion of Plottable objects: if there were a standard
protocol for passing data and style arguments to all plotting methods, it
would be easier to build robust, higher level axes factories. Facets are
one such factory, but there are others. For example (and not the prettiest,
I admit), see the map at
http://www.tableausoftware.com/public/gallery/new-jersey-test-score-analysis-visualization.
It's basically a faceted group of pie charts, that are positioned and sized
according to more data. The generalized description is something like:
atomic_plot + faceted_by(variable) + positioned_by(x, y) + sized_by(z)
Where atomic_plot is an axes plot method (e.g., ax.pie, but why not ax.bar
or any other single-variable plot?). You could imagine building a layered
API like this, and it would be easier if the interface for all atomic_plot
objects were compatible. Matplotlib was first built to win converts over
from matplotlib -- with a layered API, you can start converting the
ggplot/d3/bokeh/vega community :)
Cheers,
Chris
------------------------------------------------------------------------------
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
