EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: calcPerform expressions: 'NOT' operator
From: Tim Mooney <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Tech Talk <[email protected]>
Date: Fri, 03 Mar 2006 16:32:21 -0600


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  <20062007  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  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·