Re: [boost] is_nan

From: John Maddock (john_at_[hidden])
Date: 2006-07-25 12:53:58

Howard Hinnant wrote:
>> Do we really want to use gratuitously different names from those in
>> C99:
>>
>> isfinite
>> isnorm
>> isinf
>> isnan
>
> If we use the C99 names, do we intend on #undef'ing the C99 macros if
> they exist (C99 says these are macros, not functions)?  If we don't
> then the macros will trash our functions.  There's an easy technique
> for converting the macro (if it exists) into a function (demonstrated
> by gcc's <cmath>).  If we do #undef the C99 macros, this is
> observable behavior which we should document (lest the client be
> testing #ifndef isnan after the boost header gets included).

The way I have it set up is to *not* undef anything, that means you have to 
call them using either:

(isnan)(x);

or:

(boost::math::isnan)(x);

Just like we have to do the same thing with min and max already: this usage 
is documented with examples as well BTW :-)

> I recommend restricting these templates to floating point types.
> Otherwise they are overly generic, and could easily be called
> accidently, especially isnormal, is_normal, isnorm (or whatever, C99
> and C++0X call it isnormal).

Oh, actually I *need* generic versions of these functions in order to make 
parts of the math toolkit I'm working on generic: at the very least these 
scale to pretty much anything that has numeric_limits defined, without that 
all you can do is assume the number is a zero or a normal: but that's OK too 
because most (all?) extended precision types like NTL::RR don't support 
infinities or NaN's anyway.

Of course passing a complex number or an octonium or something *would* be a 
mistake, but I'm assuming that any function that makes use of isnan etc 
wouldn't be compatible with these anyway.

John.