On 2011-05-20 15:16, Laurent Gautier wrote:
On 2011-05-19 23:18, Thomas Kluyver wrote:
On 19 May 2011 22:00, Laurent Gautier <lgaut...@gmail.com
<mailto:lgaut...@gmail.com>> wrote:
Does
>>> import ri
>>> ri.R_VERSION_BUILD
correspond to the R version you are running rpy2 against ?
Yes: 2.12.1, svn rev 53855
Do you have older versions of rpy2 installed ? If yes, does
removing them solve the problem ?
I did have rpy2 2.1.9 installed from the repositories. Removing it
doesn't seem to change anything.
Extra info: before I do ri.initr(), ri.NA_Real is 0.0. Once I've done
initr(), ri.NA_Real appears as a small float. Additionally, once it's
not 0.0, it changes between successive evaluations. There appears to
be a repeating pattern: [a, a, b, b, nan], where a and b are
different small floats and nan is the special 'not a number' float
value. a changes between successive runs of the interactive shell,
whereas b is consistent, at least so far. But I guess there's not
much to be gleaned from that.
More on this. Something very odd must be going on.
ri.NA_Real is the instance of a singleton (ri.NARealType), and the same
instance is returned throughout calls to the constructor:
>>> import rpy2.rinterface as ri
>>> id(ri.NA_Real)
44587712
>>> id(ri.NARealType())
44587712
>>> ri.NARealType() is ri.NA_Real
True
The class NARealType has a custom method __repr__, that returns 'NA_real_'.
When working (currently the case here), it behaves as follows.
>>> ri.NA_Real
NA_real_
>>> type(ri.NA_Real)
<type 'rpy2.rinterface.NARealType'>
NARealType is also a subtype of a Python float.
>>> isinstance(ri.NA_Real, float)
True
However when changing the numerical value NA_Real is initialized with
(with anything non-zero) I start getting an unexplained segfault, and
the segfault disappears when using a debug build of Python 2.7 (making
it harder to trace what is happening with a C debugger).
This leaves me with 3 most probable general causes for the problem:
- rpy2 initialization is making the Python process unstable somewhere,
and initializing NAReal in particular makes the process collapse.
- compiler issue
- Python issue
Refactoring a bit in order to highlight a possible issue with the
compiler or Python does not bring more information: everything working
apparently perfectly with a debug build of Python, segfault and other
oddities (see right below) with a regular build.
>>> import rpy2.rinterface as ri
>>> type(ri.NA_Real)
<type 'rpy2.rinterface.NARealType'>
>>> ri.NA_Real
nan
# ?! the custom __repr__ for NARealType should return Na_real_
>>> ri.NA_Real.__repr__()
'NA_real_'
The confusion of methods makes me suspect a problem with Python (may be
at the level of the "free_list" trick for floats ?).
Out of curiosity, do people experiencing problems have 32-bit or 64-bit OS ?
L.
Mmmmh... the problem seems to be rooted in what I would believe to be
an oddity with R.
After a quick look, it appears that while the symbol NA_REAL is
defined in headers (as an alias of R_NaReal) it is only initialized
when the R engine is initialized.
void attribute_hidden InitArithmetic()
{
R_NaInt = INT_MIN;
R_NaN = 0.0/R_Zero_Hack;
R_NaReal = R_ValueOfNA();
R_PosInf = 1.0/R_Zero_Hack;
R_NegInf = -1.0/R_Zero_Hack;
}
This is a problem since rpy2's rinterface is obviously initialized
before the embedded R is (rpy2.initr() must be called to initialize R).
I am not certain of why this is done dynamically in R at
initialization time; it seems that this could be a static declaration.
static double R_ValueOfNA(void)
{
/* The gcc shipping with RedHat 9 gets this wrong without
* the volatile declaration. Thanks to Marc Schwartz. */
volatile ieee_double x;
x.word[hw] = 0x7ff00000;
x.word[lw] = 1954;
return x.value;
}
Something is already puzzling: why was this sometimes working ?
Moving the specification of the numerical value stored in rpy2's
NA_Real to something resolved at compile-time, now I have issue with
Python mixing up methods from the class "NAReal_Type" and the class
"float". There is something tricky going on, that might also be in
Python itself (as it seems that I am venturing in lesser explored
corners of Python - I have not found an other project defining a
subtype for PyFloat_Type at the C level).
This is quite annoying, and certainly a release blocker until resolved.
L.
Thomas
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
rpy-list mailing list
rpy-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rpy-list
