[R] ISNAN() broken? in ver 2.x on MacOS X
Prof Brian Ripley
ripley at stats.ox.ac.uk
Tue Jan 4 09:09:13 CET 2005
This is a good example of why it is necessary to include all the pertinent
details (and I know that demands knowing the answer, but using standalone
Rmath.h is *not* `an extension'). That you were using C++ was also
pertinent.
I don't think you should be using <R.h> if you are building against
standalone libRmath.
On Tue, 4 Jan 2005, Bill Northcott wrote:
> I see you are quite correct that IEEE_754 is defined in Rconfig.h on MacOS X.
> However, I was building against a standalone libRmath v1.9.1. So I was
> including Rmath.h only and IEEE_754 was not defined. The result was that I
> got R_IsNaNorNA in the preprocessed source.
>
> I finally found it. The culprit is
> #include <iostream>
> which is used in our real code
>
> If I preprocess the following code then the substitution is ISNAN() -->
> (isnan(x)!=0)
> #include <iostream>
> #include <R.h>
> #include <Rmath.h>
> ISNAN(x);
>
> Removing the #include <iostream> the substitution becomes
> ISNAN(x) --> (( ( sizeof ( x ) == sizeof(double) ) ? __isnand ( x ) : (
> sizeof ( x ) == sizeof( float) ) ? __isnanf ( x ) : __isnan ( x ) )!=0)
> which is correct.
>
> This behaviour is the same with both gcc 3.3 and pre-release gcc 4.0 on MacOS
> X 10.3.7.
>
> Is this a bug we should report to someone such the gcc maintainers?
You might want to swap the order of inclusion of headers. Using C headers
in a C++ program is always slightly dodgy.
> Bill Northcott
> On 04/01/2005, at 1:48 PM, Thomas Lumley wrote:
>>> In R 1.9.1 Arith.h and Rmath.h contained code like
>>>
>>> #ifdef IEEE_754
>>> # define ISNAN(x) (isnan(x)!=0)
>>> #else
>>> # define ISNAN(x) R_IsNaNorNA(x)
>>> #endif
>>> #define R_FINITE(x) R_finite(x)
>>> int R_IsNaNorNA(double);
>> Although you have clearly gone to some effort to diagnose this, I think
>> your diagnosis is incorrect.
>>
>> 1) In R 1.9.1 IEEE_754 was #defined on OS X, so we would already have had
>> #define ISNAN(x) (isnan(x)!=0)
>>
>> 2) The gcc C preprocessor documentation says
>> "When the preprocessor expands a macro name, the macro's expansion
>> replaces the macro invocation, then the expansion is examined for more
>> macros to expand. For example,
>>
>> #define TABLESIZE BUFSIZE
>> #define BUFSIZE 1024
>> TABLESIZE
>> ==> BUFSIZE
>> ==> 1024
>>
>> TABLESIZE is expanded first to produce BUFSIZE, then that macro is
>> expanded to produce the final result, 1024."
>>
>> and while I haven't been able to find anything definitive about the ANSI
>> standard, the gcc documentation usually flags extensions fairly well and in
>> any case you are presumably using gcc (though you don't say explicitly).
>>
>>
>> A work-around would be to use isnan() rather than ISNAN().
--
Brian D. Ripley, ripley at stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
More information about the R-help
mailing list