Experimental Physics and
Industrial Control System

Tim Mooney <[email protected]> · Wed, 30 May 2012 12:25:22 -0500 (CDT)

----- Original Message -----
> From: "J. Lewis Muir" <[email protected]>
> To: "Andrew Johnson" <[email protected]>
> Cc: [email protected]
> Sent: Wednesday, May 30, 2012 12:06:05 PM
> Subject: Re: calc VAL field not updating from bi VAL field
> On 5/30/12 11:11 AM, Andrew Johnson wrote:
> > Hi Lewis,
> >
> > On 2012-05-30 Allison, Stephanie wrote:
> >> Could this be a round-off error (long to double)? Does this CALC
> >> work:
> >>
> >> field(CALC, "A>0.5?1:0")
> >
> > If that works, also try the expression "!!A" which is more efficient
> > than
> > using ?: anyway. In general I never assume that a true value is 1,
> > it's
> > better to check for non-zero, so use "A!=0?1:0" or just "A?1:0".
> 
> Hi, Andrew.
> 
> Yes, "!!A" works too.
> 
> I'm not actually assuming a true value is 1. I'm simply
> comparing the value of A with 1 to see if the bi record value is
> 1. That should work. The bi record does not indicate true or
> false; it indicates two values: 0 or 1. I could just as easily
> be using an mbbi record and doing a comparison of A with the 2
> to see if the mbbi record value is 2.
> 
> My CALC expression shows the problem, but it is not what I would
> normally write by hand. The real situation is that I have a
> database where the bi value corresponding to the "inserted"
> state of a pneumatically controlled backlight is specified as a
> macro (in this case named "INSERTED"). So the CALC expression
> in the database actually looks like this:
> 
> field(CALC, "A=$(INSERTED)?1:0")
> 
> This enables the database to work with a pneumatically
> controlled backlight where the actual state (i.e. inserted or
> retracted) is reported as a high *or* low digital I/O signal.
> 
> Maybe I could do something tricky like setting the INSERTED
> macro to "!" or the empty string "" depending on how the actual
> state is reported to achieve your CALC expression, but that
> would be way less readable and therefore a poorer choice to me.
> 
> > However I admit I would be very surprised if the integer to double
> > conversion
> > is not exact for the value 1.
> 
> Right. And I'm sure I'm not the only one writing CALC
> expressions like this. There have got to be hundreds of
> expressions (probably thousands) out there that would break
> under these circumstances.
> 
> I also tried "nint(A)=1?1:0". This does not work.

It seems that the integer to double conversion really is not exact for 1.  If so, it wouldn't be exact for either 1.
Could you try "nint(a)=nint(1)?1:0"

> Thanks,
> 
> Lewis

-- 
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System