I think I have accomplished the changes described in the thread quoted below. I still have some testing to do, but I'd appreciate any comments on my approach. Preliminary testing shows negligible (i.e. undetectable) effect on performance. Here is a summary of what I did (a patch is available if desired, but I'd prefer to hold off sending it out until my testing is completed)...
Support arbitrary storage of 2D user data Adds support for arbitrary storage of 2D user data. This is very similar to the technique employed by some existing functions (e.g. plfcont and plfshade) that use "evaluator" functions to access 2D user data that is stored in an arbtrary format. The new approach extends the concept of a user-supplied (or predefined) "evaluator" function to a group of user-supplied (or predefined) "operator" functions. The operator functions provide for various operations on the arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, and minmax. To facilitate the passing of an entire family of operator functions (via function pointers), a plf2ops_t structure is defined to contain a pointer to each type of operator function. Predefined operator functions are defined for several common 2D data storage techniques. Variables (of type plf2ops_t) containing function pointers for these operator functions are also defined. New variants of functions that accept 2D data are created. The new variants accept the 2D data as two parameters: a pointer to a plf2ops_t structure containing (pointers to) suitable operator functions and a PLPointer to the actual 2D data store. Existing functions that accept 2D data are modified to simply pass their parameters to the corresponding new variant of the function, along with a pointer to the suitable predefined plf2ops_t stucture of operator function pointers. The list of functions for which new variants are created is: c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc, c_plot3dcl, c_plsurf3d, and c_plsurf3dl, and c_plgriddata. The new variants are named the same as their corresponding existing function except that the "c_" prefix is changed to "plf" (e.g. the new variant of c_plmesh is called plfmesh). Adds plfvect declaration to plplot.h and changes the names (and only the names) of some plfvect arguments to make them slightly clearer. In order to maintain backwards API compatibility, this function and the other existing functions that use "evaluator" functions are NOT changed to use the new operator functions. Thanks for any feedback, Dave On Jan 6, 2010, at 22:43 , David MacMahon wrote: > On Jan 6, 2010, at 17:14 , Maurice LeBrun wrote: > >> Some centuries ago I did endow the contourer with the function >> evaluator >> technique to deal with the issue of C vs Fortran vs whatever array >> storage. >> Worked out nicely IMO. Would've liked to upgrade all array- >> handling functions >> in like fashion but so far I think it's only been done for the >> plshadexx >> family. > > Thanks, Maurice, I see that now in plfcont and plfshade. I think > that's just the kind of thing that would be great to have for every > function that deals with >1-D data. > > I'm willing to try my hand at adapting some other functions to use > this technique. As far as I can tell, the list of functions that > could benefit from this are... > > c_plgriddata (*) > c_plmesh (**) > c_plmeshc (**) > c_plot3d (**) > c_plot3dc (**) > c_plot3dcl > c_plimagefr (***) > c_plimage (***) > c_plsurf3d (****) > c_plsurf3dl > c_plvect (*****) > > (*) c_plgriddata might need both a "getter" and a "setter" version of > this technique. > (**) calls through to c_plot3dcl > (***) might need a "plf..." version of plMinMax2dGrid > (****) calls through to c_plsurf3dl > (*****) already has a plfvect in plvect.c, but not plplot.h! > > My plan would be to rename the existing functions from "c_pl..." to > "plf..." (or "c_plf..."?) and create new versions of the old > functions that call the "plf" variant "with a particular choice for > f2eval and f2eval_data" (as the c_plcont comments say). > > The only downside to doing this, AFAICT, is that the current behavior > of these functions will be somewhat slower since they will be getting > data via the evaluator function and not directly from the "z[nx][ny]" > array (at least for z arrays that don't need to be "pre-un- > transposed" into that format). > > If anyone thinks that (or anything else about this idea) is a show- > stopper, please let me know ASAP so I don't spend time implementing > something that won't be incorporated. > > Thanks, > Dave > > > ---------------------------------------------------------------------- > -------- > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast > and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
