From: Alan W. I. <ir...@be...> - 2002-05-27 14:25:29
|
Yes, an extra array is required, but no, such an extra allocation, copy, and eventually free is not that expensive compared with the cpu effort required to actually plot. As part of a recent debugging exercise on this I compared wrapped results and "unwrapped" results where the extra set of points at theta = 2 pi was allocated from the get go as part of the example rather than relying on wrap to internally add a point at theta = 0. The plotted results were identical, and I didn't notice any speed difference at all. One other point I should have mentioned yesterday that should simplify your swig life is we subdivide our public API into common API (internal name starts with "c_", see the #defines in plplot/plplot.h) and the rest, which I suppose you could also designate as the non-common public API. The common API idea historically started as that part of the public API that you could easily implement from fortran, but it morphed to that part of the public API that you want all your front ends (fortran, Tcl, python, java, etc.) to implement since "the rest" are public C functions that are used internally (often with difficult argument lists to interface) and which should therefore not be implemented by the front ends. From time to time we do move functions from "the rest" to the common API or vice versa. But when we do that we are always careful to put the appropriate #defines into plplot/plplot.h. Thus, your swig effort can rely on those defines to find the common API that needs a python interface, and skip the C functions that are part of the public API but which are really meant for internal use only. Alan email: ir...@be... phone: 250-727-2902 FAX: 250-721-7715 snail-mail: Dr. Alan W. Irwin Department of Physics and Astronomy, University of Victoria, P.O. Box 3055, Victoria, British Columbia, Canada, V8W 3P6 __________________________ Linux-powered astrophysics __________________________ On Sun, 26 May 2002, Gary Bishop wrote: > > It's a flag which is 0 (no wrap), 1 (wrap first coordinate), or 2 (wrap > > second coordinate). This coordinate wrap idea got started with the Tcl API > > and migrated to the python and java API's. The idea is most useful when > > dealing with polar coordinates (see polar examples for the contour plots > > (xw09.py) and the shade plots (xw16.py). When wrap is set, the first angle > > point is duplicated as the last point by the interface code so that contours > > and shades are smooth. > > > > Thanks Alan, > > Doesn't "wrapping" like this imply allocating storage for another array? This > could get expensive... > > Can anyone comment on the callbacks? Some of the comments in plmodule.c imply > some of the callbacks aren't really implemented. > > gb > > |