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
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
