On Wed, Sep 12, 2007 at 01:11:54PM -0500, John Hunter wrote: > On 9/12/07, Michael Droettboom <[EMAIL PROTECTED]> wrote: > > > So, I feel like I'm going in a bit of a circle here, and I might need a > > reality check. I thought I'd better check in and see where you guys > > (who've thought about this a lot longer than I have) see this going. A > > statement of objectives of this part of the task would be helpful. > > (e.g. what's the biggest problem with how transforms work now, and what > > model would be a better fit). John, I know you've mentioned some to me > > before, e.g. the LazyValue concept is quirky and relies on C and the PDF > > stateful transforms model is close, but not quite what we need, etc. I > > feel I have a better sense of the overall code structure now, but you > > guys may have a better "gut" sense of what will fit best. > > Here is a brief summary of what I see some of the problems to be with > the existing approach to transformations, and what I would like to see > improved in a refactoring. The three major objectives are clarity, > extensibility and efficiency. > > Clarity: > > The existing transformation framework, written in C++ and > making extensive use of deferred evaluation of binary operation > trees and values by reference, is difficult for most developers to > understand (and hence enhance). Additionally, since all the heavy > lifting is done in C++, python developers who are not versed in C++ > have an additional barrier to making contributions.
Indeed! > Extensibilty: > > We would like to make it fairly easy for users to add additional > non-linear transformations. The current framework requires adding a > new function at the C++ layer, and hacking into axes.py to support > additional functions. We would like the existing nonlinear > transformations (log and polar) to be part of a general > infrastructure where users could supply their own nonlinear > functions which map (possibly nonseparable) (xhat, yhat) -> > separable (x, y). There are two parts to this: one pretty easy and > one pretty hard. > > The easy part is supporting a transformation which has a separation > callable that takes, eg an Nx2 array and returns and Nx2 array. For > log, this will simply be log(XY), for polar, it will be > r*cos(X[:,0]), r*sin(X[:,1]). Presumably we will want to take > advantage of masked arrays to support invalid transformations, eg > log of nonpositive data. > > The harder part is to support axis, tick and label layout > generically. Currently we do this by special casing log and polar, > either with special tick locators and formatters (log) or special > derived Axes (polar). Another hard part is grids. More generally, a straight line in x,y becomes curved in x',y'. Ideally, a sequence of points plotted on a straight line should lie directly on the transformed line. This would make the caps on the polar_bar demo follow the arcs of the grid. The extreme case is map projections, where for some projections, a straight line will not even be connected. Another issue is zooming and panning. For amusement, try it with polar_demo. > Efficiency: > > There are three parts to the efficiency question: the efficiency of > the transformation itself, the efficiency with which transformation > data structures are updated in the presence of viewlim changes > (panning and zooming, window resizing) and the efficiency in getting > transformed data to the backends. My guess is that the new design > may be slower or not dramatically faster for the first two (which > are not the bottleneck in most cases anyhow) but you might get > sigificant savings on the 3rd. Changing the internal representation of things like collections so that the transform can be done using numpy vectors will help a lot. - Paul ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel