Re: PREC

[Dirk Zimoch <dirk.zimoch@psi.ch>]

> > 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