(Taking this away from the mailing list as it is going off topic).
I'm putting it on the devel list; it will be good for others to know this is in the works, and be able to advise on strategy before it gets to the PR stage.
The new contour code can do both the old blocky form of contouring and
the new corner-cutting. As you suggest, I was going to leave the old
algorithm in mpl as well (perhaps undocumented), so there will be three
choices for contouring in the short term, eventually reduced to two when
we can safely remove the old algorithm. I was going to opt for a kwarg
to contour(f) to specify which of the three algorithms, as this will
allow easy automated testing and a comparison example that shows the
blocky and corner-cutting results side-by-side. I like the idea of an
rcParam though, which could be used as a default if the kwarg is not
specified in a particular contour(f) call. Does this sound like a good
Yes, I think this is ideal.
Would the new code be substantially simpler if the blocky capability were omitted from it? If so, then it seems like it would makes sense to leave the blocky form to the old code.
By the way, the reason it is yet again slow to progress is that I've had
to do a partial rewrite. If you remember I had taken the approach of
using a single large numpy array of points per pair of contourf levels
that was really fast for the contouring algorithm to produce but
potentially slow for rendering and would eventually hit some backend
limit of max number of points rendered at any one time. Well now I've
reverted to the same output as the old algorithm, i.e. a numpy array for
each polygon and its contained holes, which is obviously much safer. It
turned out that my naive changes to do this scaled really badly so I had
to rewrite some of the algorithm to calculate the hole containment as it
progresses. Because of this It is much less elegant than it was and I
need to put in a bit more time to make it easier to understand before
Less elegant--too bad!
One thing to keep in mind is the desire for a cleaner separation between the generation of the contours and their plotting. Sometimes one actually wants the polygons themselves; for example, topographic contours can be used to define boundaries for internal wave flux calculations. A student here at UH is doing exactly this.
On 2014/01/30 10:22 PM, Ian Thomas wrote: