New contouring algorithm

(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

···

On 2014/01/30 10:22 PM, Ian Thomas wrote:

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 <efiring@…229…> 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

Matplotlib-devel@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

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

···

On 31 January 2014 19:51, Eric Firing <efiring@...229...> 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 22:43, Benjamin Root <ben.root@...553...> wrote: