So I have committed a patch that returns None whenever an atomic
NA_integer_ is returned to Python. At least this is better than
returning True.
Atomic integer and real/float are less problematic, so I am inclined to
leave them as they are for now.
The variable NA_{LOGICAL, INTEGER, REAL} are hopelessly broken until how
this can be addressed nicely becomes clear.
This plus a handful of patches already committed should make it as a
version 2.0.2 scheduled for the weekend.
L.
Nathaniel Smith wrote:
> On Tue, Jan 27, 2009 at 1:02 PM, Jeff Gentry <jgen...@jimmy.harvard.edu>
> wrote:
>>> I am also getting:
>>> >>> robjects.r('NA')[0]
>>> True
>> So does this imply that R's NA objects always evaluate as Python's True
>> right now? What is (or should be) the equivalent to a NA value in Python?
>
> Heh, I was just researching this last night. It turns out that R's NA
> objects don't *always* evaluate as True, because R has many different
> "NA" values, one for each type. If you just say NA bare, then R
> apparently guesses and makes that the boolean sort of NA:
>
> In [305]: r("mode(NA)")[0]
> Out[305]: 'logical'
>
> So when rpy2 tries to convert it out, it knows that it's a boolean, so
> it must be one of True/False, and chooses True. But the other R NA
> values get converted differently:
>
> In [307]: r("as.numeric(NA)")[0]
> Out[307]: nan
>
> In [308]: r("as.character(NA)")[0]
> Out[308]: 'NA'
>
> In [309]: r("as.integer(NA)")[0]
> Out[309]: -2147483648
>
> etc. The real and integer values actually round-trip through
> conversion to python objects:
>
> In [318]: r.show(Out[307])
> [1] NA
> Out[318]: <RVector - Python:0x214d8f560 / R:0x2160a39f8>
>
> In [319]: r.show(-2147483648)
> [1] NA
>
> So that's convenient when setting up data to pass into rpy2. (But note
> that there are many different values of "NaN", and only one of them is
> understood as "NA" by R. Passing numpy.NaN there wouldn't have worked.
> See http://tolstoy.newcastle.edu.au/R/help/00a/1782.html)
>
> rpy2.rinterface has some variables that look like they're supposed to
> be python objects corresponding to NA's --
> NA_{REAL,LOGICAL,STRING,INTEGER} -- but in fact they don't ATM. It'd
> be convenient if they existed, and conversion respected them in both
> directions somehow...
>
> -- Nathaniel
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
