Hello, I do computational science and I think I'm typical in that I've accumulated a huge pile of code to post-process simulations and draw plots. I think the number of lines of plotting code is now greater than the number of lines in the actual simulation code... The problem with plotting code is that so much of it has such a short lifetime---you have an idea, spend some time writing code to draw the relevant plot, then the plot isn't interesting and you delete the code. Therefore there's little incentive to spend any time making sure that plotting code is at all well-designed. Nevertheless, _some_ of it tends to live a long time and get ever more complicated---then the lack of design becomes ever more painful as time goes on. You simply don't know at the beginning which code will be thrown away and which will live a long time.
Over the years I've developed my favorite way to organize my plotting code but it's far from perfect and I'd love to gather ideas from the MPL community. So, my current "design principles" are basically these: 1) Don't over-design. A simple system that's used consistently is better than a half-implemented complicated system. Furthermore, most plotting code gets thrown away, so keeping overhead down is one of the primary considerations. 2) Keep computation separate from plotting wherever possible. Therefore I have functions like "def compute_optical_depth(...)" that compute the physical quantities to be plotted and "def plot_optical_depth(...)" that handle everything about the visual appearance of the plot. Then when I want to draw some other plot involving optical depth, the calculation is neatly packaged into a function. 3) Keep annotation, axis labels, legends, etc, separate from the code that actually draws the lines on the axes. This allows you to compose plots to a certain extent. I often find myself saying "I want plot B to look just like plot A but with this extra information, extra lines, extra annotation, or whatever" If the function that draws plot A just puts the data on the axes without axis labels, etc, then the function that draws plot B can easily use it directly. If the function that draws plot A _also_ draws a bunch of annotations and labels, then the function that draws plot B must either get rid of them or hope they still make sense in the new context. 4) Don't put clf() and cla() all over the place. When working interactively, it's very tempting to put clf()'s into every function that draws a plot in order to save a few keystrokes. However, plots don't know the context into which they're being drawn, therefore they have no authority to clear the screen. They may "own" the whole plotting window, or they may be incorporated into a larger context. The function that worries about axis labels, annotations, and titles is allowed to call cla(). The function that worries about subplots is allowed to call clf(). If you might use the code over a slow link (e.g. connecting to a supercomputing site via residential DSL) then no function should call draw() -- that's the user's job. The upshot of these is that I end up with four layers of functions: 1) compute_physical_quantity(...): just handles numbers 2) draw_physical_quantity(...): has calls to pylab.plot() handling colors, linestyles, etc, but not annotations 3) some_plot(...): has calls to draw_physical_quantity(), some_related_physical_quantity(), along with axis labels, annotations, legends, and pylab.cla() 4) some_figure(...): has multiple panels with calls to pylab.subplot(), pylab.clf(), some_plot_a(), some_plot_b(), etc. Sometimes layers 2 and 3 are combined because I'm lazy if layer 2 would really be just a single call to pylab.plot. Please remember that I'm not writing these down because I think they're so great that everyone needs to know about them. I'm hoping that people will respond with much better ideas that I can adopt for myself. Thanks, Greg ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
