Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  Index 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: Internal type conversion in Epics
From: mrk@aps.anl.gov (Marty Kraimer)
To: tech-talk@phoebus
Date: Tue, 18 Jul 1995 13:11:35 -0500
> From ajf@ast.cam.ac.uk Tue Jul 18 10:30 CDT 1995
> Date: Tue, 18 Jul 1995 16:26:14 +0100 (BST)
> From: Andy Foster <ajf@ast.cam.ac.uk>
> X-Sender: ajf@orc
> To: Epics Questions <tech-talk@aps.anl.gov>
> 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


Navigate by Date:
Prev: [no subject] Andy Foster
Next: Free GDCT and Alpha/Digital Unix 415
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Internal type conversion in Epics Andy Foster
Next: Internal type conversion in Epics Andy Foster
Index: 1994  <19951996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·