R devel - Jan 2005 - Standalone Mathlib, C++ and ISNAN()

In the hope of some meaningful response and ignoring the risk of 
further abuse, let me try to clarify the issue here.

I have re-read the 'Writing R Extensions' manual.  It seems to me that 
it clearly says R API functions can be called from from C++ programs, 
and the API  includes the special values ISNAN() and R_FINITE() and the 
missing test ISNA().

R_FINITE is no problem.  It is defined as R_finite, which is declared 
in Rmath.h and included in libRmath.

ISNAN() however is broken.
In R 1.9 it was defined as R_IsNaNorNA unless IEEE_754 was defined 
which was not done in the standalone libRmath/Rmath.h.  R_IsNaNorNA was 
declared in Rmath and included in libRmath.  So it would work, although 
probably not when built against an installed R library because R.h 
would likely define IEEE_754.

In R2.0 ISNAN() is defined using isnan thus (isnan(x)!=0).  isnan() is 
in math.h and this works perfectly for C code.  However, in C++ the 
header cmath (included by iostream and others) undefs isnan().  So on 
platforms for which isnan() is a macro, the code breaks at compile time 
with 'isnan() undeclared'.

If building against a full R library, one might possible use R_IsNaN 
instead but this function is not included in libRmath v2.0 and the 
function R_IsNaNorNA which was used in libRmath v1.9 no longer exists

While I am on this topic, there seems to be nothing at all in the 
standalone libRmath to deal with ISNA() and although R_PosInf and 
R_NegInf are in the library, they don't seem to me to be declared.

Bill Northcott

On Wed, 5 Jan 2005, Bill Northcott wrote:
>
> If building against a full R library, one might possible use R_IsNaN
instead
> but this function is not included in libRmath v2.0 and the function 
> R_IsNaNorNA which was used in libRmath v1.9 no longer exists
>
Yes, but in your standalone C or C++ code you can just use isnan() from 
math.h directly.

The reason that R doesn't do that is twofold.  In the past we tried to 
support computers that didn't use IEEE 754 arithmetic, which meant that 
isnan might not exist.  Also, IIRC we found that isnan() doesn't use 1 for 
TRUE on all platforms -- sometimes it uses -1 or something else -- and 
code had assumed 1.  That's why the strange-looking isnan(x)!=0 is there.

You shouldn't have either of these problems in your C++ code, so it would 
be much easier to just use isnan(x) directly.  The only complication 
would be distinguishing NA from other NaNs, but you won't have to do that 
in standalone C++ code.

It would be worth noting somewhere that ISNAN breaks when some C++ headers 
are included on Mac OS X, and I will do that.


 	-thomas