[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Single/Double precision NA values
From: |
David Bateman |
Subject: |
Re: Single/Double precision NA values |
Date: |
Tue, 29 Jul 2008 18:17:51 +0200 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080725) |
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 address@hidden
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