Andrew Johnson wrote:
Summary: I am working on changes and enhancements to the calcPerform
code in R3.14, and am considering making a change that will alter the
behaviour of expressions that use the 'NOT' operator in future versions
of EPICS. Please respond if this change will adversely affect your
site, i.e. if you actually make heavy use of the 'NOT' operator (as
against the related '-', '~' or '!' operators).
The libCom calc subsystem is used by the calc and calcout records,
Channel Access security module, MEDM and probably some other client
tools to evalutate expressions. It provides separate operators for
doing logical and bitwise operations, for example '&' is a bitwise AND
while '&&' is a logical AND. The operator 'AND' is also supported as a
synonym for the bitwise operator, and has parallel operators 'OR' and
'XOR'.
When it comes to the unary NOT operations however, the operator 'NOT'
does not match the bitwise '~' not operator, but instead performs a
NEGATE operation like the unary minus operator. This obscure behavior
is documented in the Record Reference manual.
The current 'NOT' operator dates back to a time when the expression
parser only supported the use of '-' as a binary subtraction operator,
and for some reason the keyword 'NOT' was picked for the unary minus
operator. However the ability to use '-' for unary minus was added by
Janet in R3.12.0beta7 about 11 years ago, so I'm now proposing to change
'NOT' to be a synonym for the bitwise operator '~'.
Please reply if you object to this change because your site uses 'NOT'
in a significant number of CALC expressions of a 3.14 database or Access
Security configuration file.
To reward anyone who was interested enough to read to the bottom of this
message, here's what I'm up to: I've been significantly improving the
error checking and reporting from the expression parser, and have added
an assignment operator ':=' and expression terminator ';'. A single
CALC record can now return multiple results, although it is still
subject to the 40 character limit for the expression string.
Cool. By the way, I recently found an operator-precedence problem in my
implementation of unary minus. I asked Janet to commit this code for me,
long ago, because I don't have access to base. The bug I found is not in
any way her fault. (I don't think Janet even *likes* bugs.)
The problem is pretty obscure (it took me 11 years to find it!) and maybe
nobody cares, but "-(-2)^2" should yield -4. Currently, it yields 4, because
postfix.c puts the precedence of unary minus '-' ahead of the precedence of '^'.
I fixed this in the string calc stuff, and I've been trying to decide whether
it's worth mentioning because the problem seems so innocuous, and the fix might
have unforseen consequences. The fix is a little messy because you have to
open holes in the precedence table. With the table in EPICS 3.14.7's copy of
postfix.c, unary minus should have an in-stack priority between 5 and 6, and an
incoming priority between 6 and 7. Too bad the priorities are integers.
Note that the priorities I'm talking about are the ones specified in #define
statements, which override values in the expression_element structure.
#define UNARY_MINUS_I_S_P 7
#define UNARY_MINUS_I_C_P 8
I suppose this could also apply to the other unary operators which are
not actually functions, but none seem at all likely ever to bump up against
the '^' operator.
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.
- References:
- calcPerform expressions: 'NOT' operator Andrew Johnson
- Navigate by Date:
- Prev:
What is Matjito? Jeff Hill
- Next:
EDM now supports MAC OS-X Ernest L. Williams Jr.
- 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: calcPerform expressions: 'NOT' operator Jeff Hill
- Next:
RE: calcPerform expressions: 'NOT' operator Redman, Russell
- 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
|