I am more inclined to agree with Arjen. A time interface, without the ability
to represent time to the accuracy we display it is to my mind a bug. Perhaps if
the idea of a raw double doesn't appeal, then a PLTIMEFLT define would be more
in keeping with the current style.
Phil
-----Original Message-----
From: "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
Sent: 20/01/2015 02:27
To: "Arjen Markus" <arjen.mar...@deltares.nl>
Cc: "plplot-devel@lists.sourceforge.net" <plplot-devel@lists.sourceforge.net>
Subject: Re: [Plplot-devel] Question about plbtime and plctime
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
------------------------------------------------------------------------------
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
