Single/Double precision NA values

[David Bateman]

John W. Eaton wrote:
> On 28-Jul-2008, David Bateman wrote:
>
> | * The conversion of the NA values will require either an addition copy
> | of the array to be written or a slow write function that checks every
> | value before writing to see if its a NA value.
>
> Checks could be done in blocks to limit the actual number of "write"
> system calls.
>   
That will add complexity (cruft) but is probably workable.

> I don't know the best thing to do, but here are some additional
> thoughts.
>
> First, I made NA compatible with R so that we could exchange binary
> data and preserve the meaning of NA between the systems.  But if no
> one really cares about that, then I don't think it matters if this
> feature stops working.
>   
I suppose I'm asking how R/octave compatibility is dealt with and how 
people pass data between the two. Its not obvious to me what means are 
currently used and perhaps the binary compatibility is not in fact needed.

> After applying your patch, what will happen when reading old binary
> files that contain NA?  Will I get the new NA values internally?  That
> would be helpful.  However, I don't think it is as important for the
> newer Octave to be able to write out NA in a way that older versions
> can read.
>   
My current patch translates the old NA values to the new internal 
representation when reading files, though I can't remember if fread does 
it as well. However the code writes the new NA values to the files.

> Aside from compatibility with R, the other main reason for adding NA
> to Octave was so that we could have a way to represent NA separate
> from NaN.  I still that is a good thing, but I'm not sure that the
> current implementation really does the job.  For example, we know that
> some library functions (in the C library, for example) on some systems
> do things like
>
>   if (isnan (x))
>     return NaN;
>
> which will convert an NA value to a NaN.  Operations like this cause
> trouble because NA is converted to a generic NaN value.
>
> I had also hoped that over time, people would modify existing
> functions in Octave to be NA-aware, but I don't think that has really
> happened.  I only see NA used in the following functions:
>
>   interp1  interp2  interp3  interpn  interp1q  imshow
>
> and isna is only used in
>
>   interpn  __go_draw_axes__  assert
>
> Given the limited usage and the surprising, system dependent, and, to
> the end user, apparently random problems due to library functions,
> should we even bother to keep the current definition of NA?  Or should
> we just remove it and overload NaN to handle missing values?
>   
I really don't know.. I'm not a big user of NA values..

Regards
David



> jwe
>
>   


-- 
David Bateman                                David.Bateman at motorola.com
Motorola Labs - Paris                        +33 1 69 35 48 04 (Ph) 
Parc Les Algorithmes, Commune de St Aubin    +33 6 72 01 06 33 (Mob) 
91193 Gif-Sur-Yvette FRANCE                  +33 1 69 35 77 01 (Fax) 

The information contained in this communication has been classified as: 

[x] General Business Information 
[ ] Motorola Internal Use Only 
[ ] Motorola Confidential Proprietary