On Feb 16, 2010, at 9:24 , Alan W. Irwin wrote: > From the description, it sounds like the current 2D array API has been > reimplemented as a wrapper for the Dave's new 2D array API. So > just testing > the normal examples with the current 2D array API should indirectly > exercise > the new API.
Yes. To be very clear, my intent is that this patch NOT change the API of any existing function. If anyone finds that it does, please let me know and I will fix it. The patch should only add new things (structures, functions, etc.) and move pltr2f() from the f77 and f95 bindings into libplplot proper. It turns out that there are really two "current" 2D array APIs. Some of the PLplot functions already support the concept of arbitrary storage of 2D data (e.g functions relating to plcont, plshade, plvect). My patch neither changes the API of these functions nor introduces new variants of them. These existing functions still accept a single function pointer for *accessing* (aka "evaluating") the arbitrarily stored 2D data rather than a pointer to a structure of function pointers for *operating* on said data (accessing the data is one of several supported "operations"). Other PLplot functions that work with 2D data arrays, such as plplot3d, plsurf, and plmesh, current;y (i.e. pre-patch) require that the 2D data be stored in a particular form. My patch does not change the API of these functions, but it does introduce new variants of them that accept a 2D data array as a PLPointer plus a pointer to a structure of function pointers for operating on the data. The patch also replaces the implementation of the existing functions to forward their arguments to the new corresponding variant with a suitable pointer to a set of operator functions. In theory, the existing functions could be written as preprocessor macros that invoke the new variants, but obviously that would not work for existing code that expects the existing functions to exist in the library as callable symbols. The newly created variants are really modified and renamed versions of the existing functions. Other than the 2D data operations, the implementations themselves should remain unchanged. > However, I strongly second Arjen's plea to at least convert > one example (example 16?) to using the new 2D array API directly so > that all > the issues of porting it to the various languages (including perl/ > PDL) can > be worked out. Since the plshade functions have not changed dramatically, I think examples 8 (plot3d), 20 (plimage), and/or 21 (plgriddata) might be better choices to "port" to the new API. Examining how the "post- patch" versions of the existing functions call into their new variants would show how these changes would look. I would be happy to do this for one of these examples (requests please!), but it might be instructive for others to try it as well; it should be very straightforward. My primary concern about the patch is the impact it will have (if any) on the performance of calls involving 2D data arrays. I added a loop to x20c.c such that it calls into plimage 100 times. I ran it with "pre-patch" and "post-patch" builds using the null driver and found no significant performance change, so I have some confidence that it does not make things horribly worse, but I still worry (a little) about potential negative impacts to performance. Thanks, Dave ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
