RE: FLOOR function in EPICS CALC error

[<rory.clarke@stfc.ac.uk>]

Thank you Mark and Tim,

 

I understand what is happening now, I should have checked the precision set on PREC to see this correctly. With the correct PREC, I see the irrational part now.

 

Thank you for your time,

 

Rory

 

From: Engbretson, Mark S. [mailto:engbretson@aps.anl.gov]
Sent: 11 November 2016 20:24
To: Clarke, Rory (STFC,DL,TECH)
Subject: Re: FLOOR function in EPICS CALC error

 

I.e. 0.01 is a endlessly ongoing bit string in base 2. The number can not be represented without lose on a binary computer.

On Nov 11, 2016, at 14:19, Engbretson, Mark S. <engbretson@aps.anl.gov> wrote:

Wouldn't an easier test of FLOOR be just to use the floor statement with a constant? If it was really broken, order of parens should make little different. since it does, it seems as if the actual value of the calculation is suffering from a precision issue.

On Nov 11, 2016, at 14:08, <rory.clarke@stfc.ac.uk> <rory.clarke@stfc.ac.uk> wrote:

Hi,

 

I am seeing what I think may be a rounding error in the FLOOR function and I was wondering if others had seen this. I replaced the variables in my code with actual values to reproduce the problem. I am using EPICS R3.14.12.5 with Scientific Linux 7. I also tried it with the same version of EPICS running on Linux Mint

 

In Calc records, just using an empty Calc record and putting the values in by hand:

 

record(calc,"DLY:FSTEP")

{

 field(CALC,"6.1-0.2/0.01")

}

 

 

6.1-0.2/0.01 gives 590 as it should

 

However:

FLOOR((6.1-0.2)/0.01)

 

Gives me 589

 

If I write it as follows:

FLOOR((6.1-0.2)*(1/0.01))

 

I again get 590 (as it should be)

 

I wondered if this was my install or if this has been seen before. It only seems to happen for random values.

 

Best regards,

 

Rory Clarke