Re: [Matplotlib-users] filled contours: progress, a minor bug (?), and a point of curiosity

[John H. <jdh...@ac...>]

>>>>> "Eric" == Eric Firing <ef...@ha...> writes:

    Eric> Perry, John, Progress!  

Cool!

    Eric> I found that the problem I was having with PolyCollection
    Eric> was this: the vertices argument must be a sequence (list or
    Eric> tuple) of tuples of tuples--if one gives it a list of
    Eric> *lists* of tuples, one gets

    Eric> [first part of trace omitted] File
    Eric> "/usr/lib/python2.3/site-packages/matplotlib/collections.py",
    Eric> line 205, in draw self._offsets, self._transOffset)
    Eric> TypeError: CXX: type error

    Eric> (The line number was smaller before I put in some debugging
    Eric> print statements.)

    Eric> I think this fussiness qualifies as a bug; the docstring for
    Eric> PolyCollection says vertices can be a sequence of sequences
    Eric> of tuples.  I don't know what the right way to fix it is,
    Eric> however, so I am working around it.

Fair enough -- I just fixed all the agg collection drawing routines to
work with the sequence API and not require tuples.  Glad to see you're
making progress -- poly contouring is something I'd like to see added.

    Eric> Having solved that problem, I am getting more optimistic
    Eric> about being able to come up with a usable filled contour
    Eric> capability fairly quickly.  Still no promises, though.

Great -- be mindful of the contourf matlab docstrings.  Strict
adherence is not required, but it is nice to be compatible where
possible.

    Eric> All this brings to mind a question that has puzzled me for a
    Eric> long time: why does matplotlib internally use sequences of
    Eric> (x,y) tuples instead of numerix arrays--either a 2-D array,
    Eric> or a pair (or tuple) of 1-D arrays? I would think that
    Eric> running all plotted numbers through the conversion from
    Eric> arrays to Python tuples, and then from there into the native
    Eric> data types for each backend, would incur a big performance
    Eric> penalty when plotting large numbers of points.  Not that I
    Eric> am suggesting a redesign--I am just curious.

Historical and other reasons.  The historical part is that this part
of the code was written before Todd had solved the numeric/numarray
API compatibility problem for matplotlib.  These are now solved, 've
been slowly adding some numerix code to backend agg, most recently in
0.72.  I don't think it would make a lot of difference for
collections.  In the first place, you'd have to create all these lists
of numarray lists, since the collection is by definition a list of
disconnected lines.  In the second place, there is a fair amount going
on in the inner loop that I think would offset the gains you get from
using numeric.  In draw_lines, where the x,y access is a major part of
the inner loop, I do use numerix.

The backend API is moving to a path drawing model, which may obviate
the need for specialized collection drawing methods. The collection
interface would remain unchanged, but we might get away w/o having
special methods to draw them.

JDH