Re: Not-a-number (nan) issues

[Andrew Johnson <anj@aps.anl.gov>]

Lawrence T. Hoff wrote:
> 	Just to be crystal-clear, it sounds (to me) like the 
> consensus position is that CA should propagate, communicate, 
> and otherwise handle NaN (and INF) like any other floating 
> point value. 

In so far as it can do so, yet.  CA also does conversions to other types 
(currently implemented in the server, but Jeff has talked about moving it 
to the client in the future), and we need to decide what should happen in 
those cases.

> 	The places where such values should be rejected as 
> inappropriate are at the client-side ("above" CA), or in 
> device support. In addition, the aoRecord (but no other 
> output records) will be modified so that it can optionally 
> recognize NaN and suppress executing device support "write_ao()" 
> function when NaN is encountered (essentially as a convenience
> for existing device support modules which do not check for NaN 
> themselves). Is that right?

The other output record types are not able to store a NaN in their VAL 
field, so their behaviour related to NaN values is moot.  We may need to 
revisit the current calcPerform behaviour used by the calc and calcout 
records too.

In common with all output record types, the ao record has IVOA and IVOV 
fields that control what happens when the record is in Invalid severity. 
There are several ways of putting the record into Invalid severity, the 
alarm limits being one, UDF another, and reading a value through DOL with 
MS from another record that is in Invalid severity.  I am suggesting that 
the ao's VAL field holding a NaN should cause UDF to be set, thus 
triggering this mechanism, which allows the system designer to control 
what happens in this circumstance.

> 	The ramification of this is that if a NaN (or other 
> inappropriate value) is sent to a PV, it will make it at least as 
> far as the record before being flagged as inappropriate. I think 
> this means that the previous "good" value is obscured. Even though
> the NaN is "trapped", it still may be necessary to re-send the
> previous value in order for the system to operate properly.

There are records for which NaN and +/-Inf values may be appropriate; I am 
currently revising the sel record slightly, which in all versions to date 
has used a magic number of 1e30 in its input fields A-L to mean "Ignore 
this field".  This is not particuarly desirable as 1e30 could concievably 
be a valid input for some system, so I'm modifying the code to use NaN in 
place of the magic number.  This now means that a system could be designed 
that specifically needs to be able to put a NaN into one of those fields, 
in order to tell the record to ignore this field in its High/Low/Median 
calculation.  A subroutine record could use a similar technique if the 
user desires.  Thus I don't like the idea of preventing the network 
transport from passing NaN values around.

> Is that right? In the case of SNS, that would mean using some
> older save/restore file that did have an appropriate value for
> the PV in question.

To the point about the SNS application, there's no guarantee that the IOC 
knows what the appropriate value is in this setup (the last value the 
record held may not be correct in many cases), so there's no way the IOC 
could solve this problem anyway.

It is concievable that we might want to add another IVOA action which does 
a "restore previous value".  However this would have to be implemented in 
all appropriate record types, and might require the addition of a new 
field to the record types.


[Beware, wild metaphors approaching...]

Historically IOCs have pretty much ignored the possibility that float and 
double fields could contain NaN or Inf values, because vxWorks didn't seem 
to provide the necessary infrastructure to detect and deal with them. 
That particular issue is becoming less of a problem, so what I am trying 
to do is wrench the Ostrich's head from where it's buried in sand, and 
include some method by which systems can be protected from such rogue 
values.  CA is by no means the only way that a NaN could be injected into 
an IOC, and I don't think that putting a guard on that transport mechanism 
is a good place to try and fix the problem.  If anyone has any other 
suggestions on how to resolve this I'd be happy to hear them.

- Andrew
--
Dear God, I didn't think orange went with purple until I saw
the sunset you made last night.  That was really cool. - Caro