Re: PREC

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

Brian McAllister wrote:
> > > > Dirk Zimoch wrote:
>
>   > All tools including caget and camonitor should honor PREC.
>
> Caget has command line arguments that can be used to specify both format
> and precision.  I find that having a default precision rather than using
> what's defined in the record is useful, as people frequently neglect to set
> the precision and 0 is rarely useful for floating-point numbers.  I would
> probably end up creating an alias specifying a format if it used PREC by
> default.  Perhaps if one could distinguish between an explicit PREC=0 and
> "no PREC defined" it would make sense to honor PREC by default, but that is
> not currently possible.

To be lazy is not an excuse. If the PREC field is 0 it IS defined. And 
that people "forget" to set it is mainly because it is not used by the 
command line tools, I think.

> The key word here (in the discussion) is "DISPLAY".  When a value is
> retrieved as a number in native format, PREC correctly has no effect.  The
> number is the number, and is not truncated or rounded.  How that number is
> displayed should always be controllable by the client, with PREC (like
> HOPR/LOPR) as a *suggestion* indicating what the database designer believes
> is appropriate, which is used by default if the user doesn't specify
> otherwise.
>
> MEDM (and I assume the other display tools) allows the user to display
> numbers is whatever format they please, including displaying the same value
> in more than one format.  This is a GOOD THING.

You're right: "if the user doesn't specify otherwise". I do not want to 
forbid the user to specify an other precision. But if the user doesn't 
specify one, the precision provided by the record should be used. And 
caget DOES display the value, thus it should honor display parameters.

> > > > Allison, Stephanie wrote:
>
>   > Here is a radical thought - it would be nice to have a new string field
>   > (ie, .FMT) that specifies how to display the value as a string.  Then I
>   > could set up the format of our vacuums (ie, VALs that should always be
>   > displayed using exponential notation) in the database instead of having
>   > to override the default display format in each client.  Also, some
>   > save/restore tools won't restore the proper values of things like
>   > vacuum limits unless you set a ridiculously large PREC.

Vacuum readouts are what I had in mind when looking for a way to specify 
exponential format. The advantge of implementing that with negative PREC 
values is that no additional field is needed and, as Andrew pointed out, 
a format string requires a change in CA, but negative PREC values don't.

Dirk

--
Dr. Dirk Zimoch
Swiss Light Source
Paul Scherrer Institut
Computing and Controls
phone +41 56 310 5182
fax   +41 56 310 4413