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 2025 | 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 2025 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Floating point problems is CA? |
From: | Jeremy Iken <[email protected]> |
To: | Mark Rivers <[email protected]> |
Cc: | "[email protected]" <[email protected]> |
Date: | Fri, 31 Oct 2014 15:59:57 -0400 |
Does this happen only in the portable CA server? Have you tested with an IOC?
Mark
Sent from my iPhone
On Oct 30, 2014, at 9:50 AM, Jeremy Iken <[email protected]<mailto:[email protected]>> wrote:
Hi all,
My company has been using Epics Channel Access Server to great success.
Most everything has been working well for many months.
However, recently we realized weird behavior when setting certain float values.
I first initialize an Epics single-precision floating point PV:
dataGdd = new gddScalar (gddAppType_value,aitEnumFloat32)
I then am able to set it through an Epics client. Here I use some simple PyEpics:
///
from epics import caget, caput
caput('analog_out_wire',-9.9187)
print caget('analog_out_wire')
///
Now, you would expect this to print -9.9187.
However, it prints out -9.935!
Other values work fine.
For example, when setting -9.9184 or -9.9190, it gets the value exactly.
Why can it not set -9.9187 correctly?
(I found the exact same error using C# and CSS, so it is not the fault of the client)
My colleague made this graph to show the difference between what he "puts" and what he "gets".
http://i.imgur.com/Y0DAFU4.jpg
The spikes show an error at intervals of .1875.
-9.9187, -9.7312, -9.5437, etc.
Weird.
This consistent loss of precision is not reasonable for our needs.
In my epicscas.cpp write() function:
caStatus epicspv::write(const casCtx &, const gdd & value)
I noticed that Epics was receiving a value of -9.935 (The wrong value!)
It is not the readback, but the setting of the value is somehow incorrect.
There may be some translation problem in EpicsCA, which I am not prepared to debug.
If I caput() a double precision float (in C#), the error would disappear.
As a workaround, I changed my PVs to 64bit floats and fixed the problem for now, as long as I use doubles instead of floats.
We would like to use 32bit floats in the future and would be interested in finding out why they don't work correctly. This issue may be causing problems for others using CA as well.
Hopefully someone can shed some lights on my odd findings.
Thanks,
Jeremy
Jeremy Iken
Software Engineer
Pyramid Technical Consultants, Inc.
http://ptcusa.com/