NA discrepancies with and without -OO in python

Issue #86 resolved
mzjune created an issue

It seems NAs returned by R functions via rpy2 are interpreted as a large floating number. Also, this behavior changes depending on whether to use -OO. Is there a fix for this? Thanks.

Here is the procedure to reproduce the issue.

Create test_rpy_NA.py with:

more test_rpy_NA.py import rpy2.robjects

Note this portion of the output stays the same.

ret = "" x = rpy2.robjects.r("NA") print "%s, %s, %s, %s" % (type(x), (x > 1e9), (x > 0), (x < 0))

Note this portion of the output changes behavior depending on whether -OO is

used.

vector = rpy2.robjects.r("c(1, NA, 3)") for x in vector: print "%s, %s, %s, %s" % (type(x), (x > 1e9), (x > 0), (x < 0))

-- use this script to run:

more run.sh python test_rpy_NA.py >out1.txt python -OO test_rpy_NA.py >out2.txt diff out1.txt out2.txt source run.sh 3c3 < <type 'rpy2.rinterface.NARealType'>, True, True, False


<type 'rpy2.rinterface.NARealType'>, False, False, False

-- some info about our systems:

cat /proc/cpuinfo processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 44 model name : Intel(R) Xeon(R) CPU E5645 @ 2.40GHz stepping : 2 cpu MHz : 2394.270 cache size : 12288 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm bogomips : 4788.54 clflush size : 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management:

python Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) [GCC 4.5.2] on linux2 Type "help", "copyright", "credits" or "license" for more information.

import rpy2 rpy2.version '2.1.9'

Comments (4)

  1. mzjune reporter

    Sorry I had to reedit the issue to make the code more readable to you.

    It seems NAs returned by R functions via rpy2 are interpreted as a large floating number. Also, this behavior changes depending on whether to use -OO. Is there a fix for this? Thanks.

    Here is the procedure to reproduce the issue. -- Create test_rpy_NA.py with:

    more test_rpy_NA.py

    import rpy2.robjects
    # Note this portion of the output stays the same.
    x = rpy2.robjects.r("NA")
    print "%s, %s, %s, %s" % (type(x), (x > 1e9), (x > 0), (x < 0))
    # Note this portion of the output changes behavior depending on whether -OO is
    # used.
    vector = rpy2.robjects.r("c(1, NA, 3)")
    for x in vector:
      print "%s, %s, %s, %s" % (type(x), (x > 1e9), (x > 0), (x < 0))
    

    -- use this script to run:

    more run.sh

    python test_rpy_NA.py >out1.txt
    python -OO test_rpy_NA.py >out2.txt
    diff out1.txt out2.txt
    

    source run.sh

    3c3
    < <type 'rpy2.rinterface.NARealType'>, True, True, False
    ---
    > <type 'rpy2.rinterface.NARealType'>, False, False, False
    

    -- some info about our systems:

    > cat /proc/cpuinfo
    processor       : 1
    vendor_id       : GenuineIntel
    cpu family      : 6
    model           : 44
    model name      : Intel(R) Xeon(R) CPU           E5645  @ 2.40GHz
    stepping        : 2
    cpu MHz         : 2394.270
    cache size      : 12288 KB
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 11
    wp              : yes
    flags           : fpu de tsc msr pae cx8 sep cmov pat clflush mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nopl nonstop_tsc pni pclmulqdq ssse3 cx16 sse4_1 sse4_2 popcnt aes hypervisor lahf_lm
    bogomips        : 4788.54
    clflush size    : 64
    cache_alignment : 64
    address sizes   : 40 bits physical, 48 bits virtual
    power management:
    
    > python 
    Python 2.7.1+ (r271:86832, Apr 11 2011, 18:13:53) 
    [GCC 4.5.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import rpy2
    >>> rpy2.__version__
    '2.1.9'
    
  2. Laurent Gautier

    Thanks for your bug report. Would this also be present with rpy2-2.2.5 (latest release) ?

    (As my time is limited, there are not may chances I am working on a bug in the 2.1.x series - I'd rather spend that time on rpy2 on getting 2.3.0 released and may be fix 2.2.x if the bug is serious enough)

  3. Log in to comment