contour plots

Hi everybody, I just found your application, and I'm

    > stunned. You've done a great job. I'm the lead developer
    > of another application called SciGraphica
    > (http://scigraphica.sourceforge.net) and GtkExtra, a
    > package of widgets for (among other things) plotting 2d,
    > contour, 3d, and polar plots. SciGraphica is built on top
    > of gtkextra and it's not competing with matplot in the
    > sense that it aims at having a GUI based program ala
    > Microcal Origin, with spreadsheets for editing and
    > manipulating the data. I hope you agree that we can learn
    > from each others experiences with algorithms, etc. This is
    > precisely why I'm contacting you, guys!

Hi Adrian,

Thanks for the kind words. scigraphica looks like an incredible
project; combined with gtkextra it must keep you pretty busy.

    > I have to confess that my contour and 3d plots are pretty
    > "raw" in the sense that the algorithms I use are quite
    > primitive and slow. I basicaly generate a delaunay
    > triangulation and cut the triangles with planes, and draw
    > the resulting polygons. I was wondering if you guys could
    > give me some feedback about a good algorithm for plotting
    > 2d contour plots, or at least, tell me where to look in
    > your code to see if I can learn from it. Whare are the
    > actual engines to plot the pie charts and contours, for
    > instance?

The contouring engine is pure C code and is borrowed from the gist
library; see src/cntr.c. There are some python classes that sit on
top of this to create the graphics objects and labeling, and these are
in lib/matplotlib/contour.py. As far as we are able to determine, the
C code from gist does not have any licensing restrictions, and the
matplotlib contouring routines are all PSF/BSD compatible in their
licenses so you are welcome to borrow them for your own code. There
are many more publicly available routines you can consider since you
have a GPL license; matplotlib has a more permissive license and we
tryu to avoid GPL code for that reason. Most of the contouring
routines we considered, along with the licenses and possible patent
encumbrances, were discussed on the devel list last year in this
thread [Lhms-devel] Re: [Patch] New zone ZONE_EASY_RECLAIM take 3. (define ZONE_EASY_RECLAIM)[2/5] | Linux Hotplug Memory Support .

As far as the "actual engines" we use to make plots, matplotlib has
several engines it can use (PS, SVG, antigrain, GTK, Cairo, GD, ...)
All of the screenshots were produced with the antigrain renderer, a
C++ library for 2D antialiased rendering with full alpha channel
support (http://antigrain.com). We embed the antigrain rendered
images into a variety of GUI canvases (Tk, GTK, WX, FLTK, Qt) using a
bitmap transfer.

Hope this helps!

JDH

John,

Attached is the diff against CVS for lines.py, with a fix for the set_xdata/set_ydata bug that Torsten found. The changes are:

(0) (Sorry--looks like part of the diff is caused merely by trailing space characters that my editor strips off.)

1) I replaced _masked_x and _masked_y attributes with _x_orig and _y_orig, which hold the inputs to set_data with no changes; they are always used, regardless of whether the inputs are masked or not. This leads to some simplification, and solves the problem Torsten found. The penalty is that if neither x nor y is masked and both are already 1-D numerix float arrays, then both are needlessly stored twice, once in _x_orig/_y_orig, and again in _x and _y. (Actually, this may not be true; I am not sure whether the arrays are duplicated or whether there are merely separate references to the same data arrays. I could figure it out, but I don't want to spend time on that now unless it is deemed urgent.)

2) I made some other changes in set_data to make it simpler and more readable; in particular, using ma.ravel() at the start eliminates several later conditionals and calls to ravel.

3) There seems to have been half-way support for letting either x or y be of length 1, and having it automatically expanded to match the other variable; I completed this support and moved it to near the top of the function. If it is not useful, it can be removed easily with no ill effects. (All it would be good for is making horizontal or vertical lines.)

Eric

lines.diff (4.96 KB)