Re: Unbalanced conditional ?

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

Paul Nord wrote:
> Interesting trick.
>
> Did you intend to write:
> 	B=0
>
> Or did you really want:
> 	B==0

In EPICS CALC that's the same: Comparison. Assignment is :=



> 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