On 2015-01-19 11:11-0000 Arjen Markus wrote: > Hi everyone,
> While working on the dual interface to the Plplot core functions for Fortran (that is: both single and double precision at the same time), I stumbled upon the interface for plbtime and plctime (possibly also plconfigtime, but I have not looked at that yet). I think our current use of PLFLT for the "ctime" arguments to these functions is incorrect. If PLFLT is defined as single-precision, then the functions will not give correct results, since single-precision reals have too little resolution. > I suggest we explcitly use the "double" type for these functions. Perhaps a minor detail that only comes into play if someone does decide to use single-precision for the core library, but still, it would lead to surprising results. > Do you agree or am I misinterpreting something? I disagree and think we should just stand pat. Here is why. There is no mention at all of PLFLT in the qsastime library source code and the floating point types there should stay as double (because 32-bit floats just do not have the required time resolution for the general case as you have already pointed out). So in src/pltime.c the appropriate PLFLT arguments for plbtime, plctime, and plconfigtime are implicitly cast to doubles whe calling the equivalent qsastime routines. So I think the status quo is just fine. It would be way too confusing for PLplot C (and other language users) to have the time part of the API use fixed double types and the rest of the API use configurable PLFLT types. In other words, it should continue to be possible to use the PLplot time API for the 32-bit floating-point case so your new Fortran binding for plbtime, plctime, and plconfigtime should not treat the arguments of those routines any differently than other parts of the PLplot C API. Of course, I agree with your point that users of the 32-bit floating-point PLplot library will experience rather limited time resolution in their calls to plbtime, etc. However, if that turns out to be a problem for them, their likely (and correct) move would be to try the 64-bit floating-point version of the PLplot library. Of course, another alternative you haven't mentioned is we could try disabling the build of the qsastime library, the PLplot time API, and most or all of example 29 for all languages for the 32-bit case, but that is a pretty intrusive solution so I prefer that we just stand pat and accept that users of the 32-bit floating-point variant of the PLplot library are going to experience limited time resolution. 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 __________________________ ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
