Experimental Physics and
Industrial Control System

[email protected] (Marty Kraimer) · Tue, 18 Jul 1995 13:11:35 -0500

> From [email protected] Tue Jul 18 10:30 CDT 1995
> Date: Tue, 18 Jul 1995 16:26:14 +0100 (BST)
> From: Andy Foster <[email protected]>
> X-Sender: ajf@orc
> To: Epics Questions <[email protected]>
> Subject: Internal type conversion in Epics
> Mime-Version: 1.0
> Content-Type> : > TEXT/PLAIN> ; > charset=US-ASCII> 
> Content-Length: 1407

...

> I have tried to pass down a double into a record which only
> accepts strings. This record has been written especially for
> the Gemini project and is known as a CAD record. Since
> the CAD only accepts input strings, I had to do this by first
> converting the double into a string using something like:
> 
> sprintf( pcad->inpa, "%0.15f", val );
> 
> Inside the routine that the CAD record calls, I had to do:
> 
> val = strtod( pcad->inpa, &c );
> 
> This worked fine but seems to be a bit of an overhead for 
> passing in a double!
> 
> I had previously thought that EPICS would do this sort of conversion
> automatically. However, when I tried this I found that I lost a great 
> deal of accuracy in the value that I was passing in. 
> For example, I tried to pass 9.564328761234322 through
> the output link of a double into the CAD input field. The result after:
> 
> val = strtod( pcad->inpa, &c ); 
> 
> was 9.564330000000000. 
> 
> Is this what you would expect or am I missing something obvious
> and important?

The code that does the conversion uses the same routine that converts
DBF_DOUBLE fields when an input request is DBR_STRING.
The code calls the get_precision member of the record support module,
which normally returns the value of the PREC field of the record.
Unless that number is very large or small or PREC>8 this is the number of
decimal digits of precision requested. An epics routine cvtDoubleToString
(in libCom/cvtFast.c) does the actual conversion.

The concept of PREC goes back before epics so I cant give the
exact reasoning. I can only say that in most cases this is what is
wanted for edd/medm text displays. For some cases it even fails for edd/medm.
It does NOT lead to conversion being consistant with it's inverse,
i.e. double1->string->double2 does not imply that double1=double2.
By the way I dont think that it is possible to provide a completely generic
set of string<->float or string<->double conversion routines that will
satisfy ALL uses.

For the case of DBR_DOUBLE to a DBF_STRING field perhaps
the decision should have been to use %g (note that  width and precision
are purposely suppressed). It should be noted that at one time the g format
conversions were VERY slow. On a 68020 the cvtDoubleToString routine was >100
times as fast as sprintf(xxx,"%g",value). The %g took several milliseconds.
I have not timed this on recent versions of vxWorks.

This also leads to the statement that it is better for such conversions to
be done by clients rather that in an ioc. Of course, if the conversion is being
done because of database links, it has to be done in the ioc.

Marty Kraimer

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System