Interesting trick.
Did you intend to write:
B=0
Or did you really want:
B==0
On Dec 8, 2011, at 8:23 AM, Dirk Zimoch wrote:
> Dirk Zimoch wrote:
>> Hi all,
>> When I tried to upgrade from 3.14.8 to 3.14.12, I found that some CALC expressions are not working any more, e.g. "B=0?A"
>> In 3.14.8 and all previous versions that meant: If B is 0 then set VAL to A otherwise don't change VAL.
>> Now, I get the error message:
>> Unbalanced conditional ?: operators in CALC expression 'B=0?A'
>> Can't set "recordname.CALC" to "B=0?A"
>> Was there any good reason for this incompatible change in the CALC behavior?
>> Dirk
>
> By the way, the previous behavior is documented here:
> http://www.aps.anl.gov/epics/wiki/index.php/RRM_3-14_Calculation#Conditional_Expression
>
>> (A+B)<(C+D)?E
>> * Result is E if (A+B) < (C+D)
>> * Result is unchanged if (A+B) >= (C+D)
>
> The change is not mentioned in the release notes http://www.aps.anl.gov/epics/base/R3-14/12-docs/RELEASE_NOTES.html
>
> Thus I guess the new behavior was not intended and is a bug.
>
> When fixing this, it is probably worth to implement as well a feature available in gcc: If the second operand is missing, it is the same as the first one.
>
> "A+B?:C" means "A+B?A+B:C" but saves space and cpu cycles.
>
> Dirk
>
- Replies:
- Re: Unbalanced conditional ? Dirk Zimoch
- References:
- Unbalanced conditional ? Dirk Zimoch
- Re: Unbalanced conditional ? Dirk Zimoch
- Navigate by Date:
- Prev:
Re: Unbalanced conditional ? Dirk Zimoch
- Next:
Re: Unbalanced conditional ? Dirk Zimoch
- 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: Unbalanced conditional ? Dirk Zimoch
- Next:
Re: Unbalanced conditional ? Dirk Zimoch
- 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
|