On 2014/01/30 10:22 PM, Ian Thomas wrote: > (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 > plan? 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 > release. 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. Eric > > Ian ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
