Re: Single Precision versus double precision NA

[David Bateman]

John W. Eaton wrote:
> On 30-May-2008, David Bateman wrote:
> 
> | I have a problem with the NA value for single precision. Ideally if I do
> | 
> | double vd = octave_NA;
> | float vf = static_cast<float>(vd);
> | 
> | I'd like vf to also be considered as have the value NA. However as the
> | distinguishing feature of the double NA is in the lower word, this is
> | lost when cast to a single precision value. If the double precision NaN
> | value that was considered as being NA was
> | 
> | 0x7FF8 00F4 4000 0000
> | 
> | instead, when this was cast to a float it would become
> | 
> | 0x7F8007A2
> | 
> | and both might be considered as being NA. Making this change would
> | however not be backward compatible particularly with NA values stored in
> |  files.
> | 
> | Without wrapping to float and double, I don't think we can overload the
> | assignment operators to check for NA values, so that leaves catching the
> | NA values in the FloatMatrix, etc constructors and in fact several
> | others places.
> | 
> | Alternatively, I can just not care about the issue and then casting a
> | double NA to a float NA or visa versa just won't work..
> | 
> | Any other ideas of how to handle this?
> 
> I don't know what is best, but the particular value used for NA was
> chosen for compatibility with R (it is exactly the same value used in
> R), so I think we should try to preserve that if possible.  OTOH, we
> recently had a discussion about how NA is not always preserved in
> calculations because library functions can do things like
> 
>   if (isnan (x))
>     return NaN;
> 
> which will convert NA to NaN.  So maybe implementing NA in this way is
> not really the best way to do it in any case.

The easiest way for me to get something reasonable would be to replace
the NA value with one that has a value in the mantissa that has a bit or
bits set that will be carried over into the float value and zero in the
other bits so that conversion from float to double works correctly as
well. Then again, can we guarantee a certain behavior when converting
NaN values from double to float and visa versa or will this vary with
different compilers.

D.