Hi all,
I wrote a bit of code for plotting streamgraphs with MPL (e.g., http://goo.gl/7sjcR).
It is available on my GitHub page here:
What is the best way for me to integrate it into MPL?
Uri
…
Uri Laserson
Graduate Student, Biomedical Engineering
Harvard-MIT Division of Health Sciences and Technology
M +1 917 742 8019
laserson@…608…
Hi Uri,
I wrote a bit of code for plotting streamgraphs with MPL (e.g.,
http://goo.gl/7sjcR).
Fantastic, many thanks! For anyone who is willing to shepherd this
through inclusion in MPL, I *strongly* recommend they read the paper
in the link above, titled:
“Stacked Graphs – Geometry & Aesthetics” by Lee Byron & Martin Wattenberg.
PDF link: http://www.leebyron.com/else/streamgraph/download.php?file=stackedgraphs_byron_wattenberg.pdf
In fact, I'm sure anyone who's intrested enough in data viz to be on
this list would tremendously enjoy the paper, it's a really good
piece.
It is available on my GitHub page here:
http://goo.gl/qGGPS
What is the best way for me to integrate it into MPL?
Unfortunately I'm too swamped to fully help you move this through, but
a few pointers now so to get you going, and hopefully another core dev
can pitch in...
- For mpl inclusion, your code needs to be explicitly BSD licensed,
and should mention that the original code it's based on (if you read
any of the implementation) was also BSD licensed (which it is, as per
this file: https://github.com/leebyron/streamgraph_generator/blob/master/COPYRIGHT).
- I read your implementation and it looks very nice and concise,
excellent job. After reading the paper, I was just wondering if this
problem might not benefit from a bit of object orientation...
I'm just thinking out loud here, and I actually tend to always favor
holding of on the OO until a more decoupled, functional approach shows
its limitations. So perhaps your take is just fine for now. But what
I'm thinking about is that the Streamgraph construction has a number
of moving parts:
* the optimization formulation to select g_0.
* the colormap choices, which can be fairly sophisticated.
* the sorting of the time series and their assignment on the stream stack.
It might be more convenient to bundle all these into an object that
exposes the already implemented options and can be extended to other
algorithms. This is a case where I'm thinking of going OO not because
of inheritance, but simply as a way of grouping related functions and
data in a way that's easier to pass around in more complex codes.
In fact, a good solution might be to keep a number of standalone
functions and offer a wrapper object that exposes an OO interface.
For simple cases people could just call the function with some data,
but for more complex development using (and possibly extending) the
object would be cleaner.
In any case, I hope this feedback is useful, and I look forward to
streamgraphs in MPL! Sorry that I won't be able to work on the
review/merge itself in the future; as interested as I was by the paper
(many thanks for bringing it to our attention), I'm already neglecting
other things far too much 
Regards,
f
On Wed, Feb 9, 2011 at 12:13 PM, Uri Laserson <laserson@...608...> wrote: