Hi Uri, On Wed, Feb 9, 2011 at 12:13 PM, Uri Laserson <laser...@mit.edu> wrote: > > 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 ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
