@Jerry: This is the heads-up you requested for this commit (<https://sourceforge.net/p/plplot/plplot/ci/314bae717aff3e1af3cd11cbf650f18c0a33a3ce/>) concerning C example 8 and use of plsurf3d rather than plfsurf3d there.
@Everybody Those of you who have been doing recent testing of PLplot should have noticed that the PostScript differences between Ada (thick and thin) examples and corresponding C examples are now perfect, e.g., ada Missing examples : Differing graphical output : Missing stdout : Differing stdout : adathick Missing examples : Differing graphical output : Missing stdout : Differing stdout : This satisfying result is thanks to Jerry's recent Ada changes. During that effort, Jerry effectively asked the question why should there be plfsurf3d calls in C example 8 but not in example 8 for any of the other languages? That is known as a "good question". :-) Please see the commit message at the above URL for my opinion concerning that question. However, there is a larger question here which is relevant because of David McMahon's patch that I applied in 2010. As a result of that change the C functions plfgriddata, plfmesh, plfmeshc, plfplot3d, plfplot3dc, plfplot3dcl, plfshades, plfshade1, plfimagefr, plfimage, plfsurf3d, and plfsurf3dl gained useful generalized capability for processing 2D arrays in any format that is accessible to C (regardless of whether that format is efficent or not). Note that each of our supported languages typically has a preferred efficient native method of representing 2D arrays, e.g., row-major order in C and row-column order in Fortran (see <https://en.wikipedia.org/wiki/Row-major_order> for further details). So the above functions can be quite useful in _the implementation_ of each of our language bindings to help translate from one implementation to another. That said, I am strongly of the opinion that we should only support the preferred efficient native method of representing 2D arrays for each of our languages other than C. That is, none of the above functions should be propagated to our non-C languages and should not be used in any of our non-C examples. When I surveyed our C examples, the only direct use of the above API was in example 8 (i.e., use of plfsurf3d there) which served as the motivation for the current commit which (unless the user specifies the C-only -if_plfsurf3d option) replaces all those calls by the equivalent plsurf3d calls to help give better guidance as to what part of the C API should be propagated to our non-C languages. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
