John Hunter wrote: > On the issue of units (not unit testing but unit support which is > motivating your writing of unit test) I think we may need a new > approach. The current approach is to put unitized data into the > artists, and update the converted data at the artist layer. I don't > know that this is the proper design. For this approach to work, every > scalar and array quantity must support units at the artist layer, and > all the calculations that are done at the plotting layer (eg error > bar) to setup these artists must be careful to preserve unitized data > throughout. So it is burdensome on the artist layer and on the > plotting function layer. > > The problem is compounded because most of the other developers are not > really aware of how to use the units interface, which I take > responsibility for because they have oft asked for a design document, > which I have yet to provide because I am unhappy with the design. So > new code tends to break functions that once had unit support. Which > is why we need unit tests .... > > I think everything might be easier if mpl had an intermediate class > layer PlotItem for plot types, eg XYPlot, BarChart, ErrorBar as we > already do for Legend. The plotting functions would instantiate these > objects with the input arguments and track unit data through the > reference to the axis. These plot objects would contain all the > artist primitives which would store their data in native floating > point, which would remove the burden on the artists from handling > units and put it all in the plot creation/update logic. The objects > would store references to all of the original inputs, and would update > the primitive artists on unit changes. The basic problem is that the > unitized data must live somewhere, and I am not sure that the low > level primitive artists are the best place for that -- it may be a > better idea to keep this data at the level of a PlotItem and let the > primitive artists handle already converted floating point data. This > is analogous to the current approach of passing transformed data to > the backends to make it easier to write new backends. I need to chew > on this some more.
John, I think that getting unit support out of the basic artists, and keeping it at a higher level, is an excellent idea. Right now, unit support is sprinkled all over, and one never knows exactly where it will be or what to expect. Most of it works, but some doesn't. (I just fixed a part that didn't.) One could go a little farther with this and require that more of the argument checking and regularization be done above the artist level as well; so that the artists could count on arrays of coordinates being ndarrays or masked arrays, for example. Whether the resulting code simplification would be worth the extra care required in using the artists, I don't know. I also like the PlotItem concept as a way to get Axes under control and slimmed down. It is the approach taken with Quiver, Contour, and Colorbar, so there is more precedent than just Legend. I'm not sure that a complete PlotItem-ization is required for localizing the unit support at a higher level than the basic artists; maybe it can be done piecemeal. A complete one-shot reworking would be a big job, requiring a lot of testing. Eric ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
