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
> 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
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 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