On 2010-01-02 12:17-0800 David MacMahon wrote: > Hi, Alan, > > Thanks for confirming that for me. > > On Jan 2, 2010, at 8:13 , Alan W. Irwin wrote: > >> I would suggest you use the default (double precision) build >> (with appropriate casts of that part of your data that is single-precision >> to double precision) since the default build is the one that has the most >> consistent testing. > > This might be veering off into a topic more suitable for the plplot-devel > list, but if a relatively small subset of functions had two different > versions (one for single precision, one for double precision), then it seems > like both types could be supported simultaneously. Many functions would not > need two versions (compile-time casting would suffice), so only functions > that take pointers would need two versions and even many of those need not > offer two variants (i.e. float-only or double-only would likely suffice). If > the functions were differentiated with a "_f" or "_d" suffix, the header file > could alias a non-suffixed version to the desired variant based on a #define > so existing code for either libplplotf or libplplotd would be minimally > impacted. > > I guess this would affect the driver interface as well, so perhaps it would > be a non-trivial change, but it would provide the benefit of being able to > plot both types of data "natively" (i.e. without converting large arrays of > floats to large arrays of doubles). I'm not promising anything, but if > you're open to the concept I might be willing to take a stab at implementing > it.
Hi David: There are some substantial one-time costs to new API since we must propagate the change to the fairly large number of different languages we support and also document the new API. Furthermore, the obvious long-term cost of an ever-expanding API is it gradually makes PLplot harder and harder to learn. On the other hand, our track record is we are quite willing to add to our API if it is felt the general usefulness to users of the API addition outweighs the obvious one-time and long-term costs. For example, I am currently working on a plgradient addition to our API, and we recently added some time functionality with more in prospect. The overall usefullness of mixed precision is the question mark in my mind. My own educated guess is the fraction of our users with mixed double/single precision data to plot is low, but I could be wrong. I suggest you go ahead and make a mixed precision library wrapper for your own needs for a start; see how that goes; and then get back to us on the plplot-devel mailing list to discuss whether the overall general usefulness of this idea justifies making the required addition to the PLplot API. Discussions of code in hand tend to be much more fruitful than discussions of possibilities. :-) 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ ------------------------------------------------------------------------------ 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-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
