Experimental Physics and
Industrial Control System
| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 <2004> 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 <2004> 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: PREC |
| From: | Dirk Zimoch <[email protected]> |
| To: | Brian McAllister <[email protected]> |
| Cc: | TECHTALK <[email protected]> |
| Date: | Mon, 14 Jun 2004 09:19:21 +0200 |
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
- References:
- Re: PREC Brian McAllister
- Navigate by Date:
- Prev: Re: RDB connection from IOC [was:] Noboru Yamamoto
- Next: Hytec drivers & PSI CVS Korhonen Timo
- Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 <2004> 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
- Navigate by Thread:
- Prev: Re: PREC Brian McAllister
- Next: RE: PREC Allison, Stephanie
- Index: 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 <2004> 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·