You are going great guns with mpl1; I am trying to get spun up on
traits, and to understand where you are going with mpl1. In general I
like what I see--as expected. Regarding the following comments: I
recognize that you are engaged in a sketching activity, and I may be
thinking prematurely about detail.
A bit of both, some of the things you mention I've simply left out for
expediency, and some of them reflect murky thinking, so these comments
are useful. Also, you'll notice that the examples are quite verbose
right now -- I think there is plenty we can do to simplify as well as
wrap these calls up into convenience methods. I've been focused more
on trying to get things wired up properly and then later worry about
how it looks.
You raised the question of 3D. I don't know anything about fancy 3D
with hardware acceleration etc., but for the simplest 3D it seems like
everything can be done at the model stage of the transformation;
everything after that is 2D. Maybe this doesn't get us very far; I
don't know how hidden-line removal would be handled for multiple paths.
This is essentially the approach taken by axes3d and friends in
current matplotlib, and yes, you do get into 3d clipping problems this
way. I don't really have much of an appetite for 3D personally. It's
plenty of work to get 2D right. My comment was more in the vein of:
would it be useful to stick in 3D transformations and data structures
from the ground up if they aren't too expensive so that if someone who
*does* have more of an appetite for making it work comes around, they
will have a fighting chance.
It seems to me that in the interesting cases such as polar plots, map
projections, and simple 3D plotting, the Func class is really a
Projection class, so I suggest it be renamed to that, or to Proj if you
want something short. ("Func" always seemed a bit ugly.) It will
typically need additional attributes, and should supply additional
information. For example, for a given set of coordinate limits (say r
from 1 to 2 and theta from 0 to pi/2 in the polar case) it should be
able to provide a bounding box in the rectilinear coordinates. It will
need a method to generate a path that is "straight" in the original
coordinates, hence curved in the rectilinear coordinates. (This method
will probably be used both to calculate the bounding box and to generate
the axis objects, grids, bounding "polygon", and things like the bar
paths in a polar bar plot, for example.) I suspect it will also help to
have a method that returns a rotation matrix for each of a set of
points. This would be a help in generating an axis with tick marks in a
curvilinear system, and in orienting vectors drawn on a map projection.
This is very helpful -- as you saw, what I have in their are mostly
stubs and I have not given a lot of thought to how they need to fit in
with a general transformation scheme vis-a-vis tick labeling and
gridding. The other question is: where should they live? In the
draft, they are attached to the artist, but probably the artist should
get them from the axes they live in because the axes will also need to
use them for ticking and gridding. I'm pretty close to having the
axis, axes portion of the sketch done, though I have to take a few
days off from this to attend to other things. If you have some time,
in the interim, you should sketch out a traited API of the Projection
class (much better name). When I get that axis portion working,
perhaps you should jump and see if you can plug your projection class
into it. For me it will probably be Tues or Wed at the earliest.
This brings up another question, regarding the drawing model: what do
you view as (1) required and (2) not required but used if available? So
far, everything is in terms of moveto, lineto, and close_polygon. What
about curves? Do you anticipate sticking to line-segment paths, or do
you expect to use any curve-generation (bezier, arc, ellipse)
facilities? Is this something to be done as a phase-2 optimization,
after initially doing everything with line-segment paths?
No we'll support the bezier curves at the outset, this was an example
of an expediency. I just didn't add the extra codes in m first pass.
Ellipse and Arc will just be special cases of a Path with bezier
codes, but they won't be primitives.
Returning to a point of terminology: what you are calling Affine is
actually a very limited subset of affine transformations, correct?
Rotation and shear are not included.
Also, I was puzzled initially by the xlim and ylim attributes; these are
the bounds that get mapped to the 0-1 interval by the transform,
correct? If so, this is an additional specialization of your Affine
relative to the general meaning of the term.
This is the example of the mix of expediency and murkiness I was
referring to above. I planned to go back and add rotation and shear
interfaces (eg along the lines of the current translate and scale
properties). The murkiness part is that I made the xlim and ylim a
property based view into the affine, which was quite handy, but will
probably cause problems down the road. We might want to have a
derived special case of the affine for separable coordinate systems so
that we can support this usage of the xlim and ylim. The aritst.adata
would then be the seperable affine, where as the aview would be a full
affine, eg to support rotated axes. Does this seem workable?
Thanks,
JDH
···
On 7/22/07, Eric Firing <efiring@...229...> wrote: