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
>
>
|
