Experimental Physics and
Industrial Control System

Dirk Zimoch <[email protected]> · Fri, 11 Jun 2004 18:10:47 +0200

But what does this exactly mean? I think, the most intuitive sense is
to format the value like "%.<PREC>f". At least this is the default
behaviour of medm when using a text monitor. But why not like
"%.<PREC>g" or "%.<PREC>e"? And why does neither caget nor camonitor
honor PREC? And what about negative PREC values?

I'm not sure that the most intuitive sense is "%.<PREC>f". I interpret
the documentation to mean that PREC should result in "%.<PREC>g".

That's my problem: It is not documented what PREC really means. Of
course, one can look into the code as Marty suggested, but not many
people can really find out what's going on in EPICS just by looking in
the code :-) Even after finding and understanding cvtFloatToString, etc.
it is hard to say under what circumstances those functions are used.
To ignore PREC > 8 and use "%12.5e" instead is not what I expected
(found in cvtFloatToString). Even though it seems reasonable, because
the precision of a float is very limited.
I found that in cvtFloatToString, etc., the precision argument is
unsigned short. This does not match the definitions of the PREC fields
in the dbd files.

I suggest the following:
PREC >= 0 means to format the value like printf("%.*f",PREC,VAL);
PREC < 0  means to format the value like printf("%.*e",-PREC,VAL);

I worry that there are a lot of tools out there that might not take well
to negative PREC values.
All tools including caget and camonitor should honor PREC.
Any comments?

I'd argue that PREC should specify the number of significant digits and
that the style (f/e) should be chosen according to the printf rules:
 If the precision is missing, 6 digits are given; if the

precision is zero, it is treated as 1. Style e is used if the

exponent from its conversion is less than -4 or greater than or

equal to the precision. Trailing zeros are removed from the

fractional part of the result; a decimal point appears only
if it

is followed by at least one digit.
With PREC=2, pi would print as 3.1, pi/100 as 0.031, pi/10000 as
0.00031, pi/100000 as 3.1e-5, pi*10 as 31 and pi*100 as 3.1e2.

printf "%g" works this way, but EPICS obviously not:
record (ai, "ai") {
    field (PREC, "2")
    field (VAL, "3.1415")
}
record (stringin, "string") {
    field (INP, "DZ-AI")
    field (PINI, "YES")
}
The value of string is "3.14"
When I use 'field (PREC, "-2")', the value of string is
"3.14150000000000018e+00"

All in all, it was just an idea, how one could define in the record how
the value should be shown and not in caget or the adl file. It is more
in line with the EPICS philosophy (as I understand it) to configure as
much as possible on the record level. A change in cvtFloatToString, etc.
could possibly do it for most applications.
Dirk
--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System