On Wednesday, January 6, 2010 at 22:43:44 (-0800) David MacMahon writes: > 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).
My only suggestion is to not worry about the performance issues in function evaluation.. after all you've got a system call somewhere down the line to actually draw something. In my experience that's usually where the worst (and most intractable) bottleneck occurs. -- Maurice LeBrun ------------------------------------------------------------------------------ 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