Experimental Physics and
Industrial Control System

Perhaps we should also consider rejecting NAN requests in ca_put, but is
that going too far? Would there ever be a valid reason to allow a CA client
to write NAN into a specialized PV?

That's of course where it gets religious and
thus we can start a full bore email war.
You can argue that NaN is there for a reason.
sqrt(-1) returns NaN when I try it on Linux,
then NaN gets passed through further computations
and needs to be handled at the end.
So shouldn't a collection of CALC records
on one IOC, when running into sqrt(-1), result in NaN,
and if that's read via channel access on another IOC,
shouldn't it be passed as NaN, and then it's up
to the final output record to decide what to do with NaN.
ChannelAccess no record support must not nanny the user
by removing the NaN.

On the other hand, it's probably much safer to assume
that NaN doesn't get handled at the end, it's created
by accident and thus should be blocked as soon as
possible (which I think is what the CALC record resp.
calcPerform.c do).

Replies:

Re: Not-a-number (nan) issues Eric Norum

Re: Not-a-number (nan) issues Till Straumann

Re: Not-a-number (nan) issues Andrew Johnson

References:

RE: Not-a-number (nan) issues Jeff Hill

Navigate by Date:

Prev: Re: Not-a-number (nan) issues Marty Kraimer

Next: Re: Not-a-number (nan) issues Eric Norum

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: Not-a-number (nan) issues Jeff Hill

Next: Re: Not-a-number (nan) issues Eric Norum

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