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
Thanks for bringing this back onto the mailing list. I am excited for the prospect of new algorithms for contouring. My company has actually been using the contourf() function for the past few years to generate the polygons from gridded data to then make shapefiles from those polygons. Having an rcParam and a kwarg for controlling which algorithm gets used for contouring would be good for us when we transition to any new algorithms. I also advocate strongly for better separation between the plotting and the contouring. I made an attempt awhile back for my work to not have to call contourf() so that my shapefile library code wouldn't interfere with anybody's plotting that they happen to be doing, but I just couldn't get a clean separation. I ended up having to wrap my contouring code as a sub-process. Do keep me in the loop about this, as I have a fairly substantial data source for testing. Cheers! Ben Root On Fri, Jan 31, 2014 at 2:51 PM, Eric Firing <ef...@ha...> wrote: > 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 > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >
On 31 January 2014 22:43, Benjamin Root <ben...@ou...> wrote: > Thanks for bringing this back onto the mailing list. > > I am excited for the prospect of new algorithms for contouring. My company > has actually been using the contourf() function for the past few years to > generate the polygons from gridded data to then make shapefiles from those > polygons. Having an rcParam and a kwarg for controlling which algorithm > gets used for contouring would be good for us when we transition to any new > algorithms. > It is good to hear that it will be useful. > I also advocate strongly for better separation between the plotting and > the contouring. I made an attempt awhile back for my work to not have to > call contourf() so that my shapefile library code wouldn't interfere with > anybody's plotting that they happen to be doing, but I just couldn't get a > clean separation. I ended up having to wrap my contouring code as a > sub-process. > This is not in the scope of the work I am doing - see my previous answer to Eric. > Do keep me in the loop about this, as I have a fairly substantial data > source for testing. > Excellent, testing by others will be much appreciated. I won't submit a PR on this until after the impending release so there is plenty of time for testing before the release after that. Ian
On 31 January 2014 19:51, Eric Firing <ef...@ha...> wrote: > 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. > Simpler, yes, but not substantially so. I would prefer to keep both blocky and corner-cutting algorithms together so that there is only one extension to maintain when we eventually remove the old code. 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. > That is certainly desirable, but not part of the work I am doing. I am rewriting the C/C++ code that calculates the contours, but the interface between that and the python contour code remains the same, apart from some trivial changes of course. Ian