[Numpy-discussion] Portable macro to get NAN, INF, positive and negative zero

[David Cournapeau]

On Thu, Mar 12, 2009 at 10:19 PM, Bruce Southey <bsouthey at gmail.com> wrote:
> David Cournapeau wrote:
>> Hi,
>>
>>     For the record, I have just added the following functionalities to
>> numpy, which may simplify some C code:
>>     - NPY_NAN/NPY_INFINITY/NPY_PZERO/NPY_NZERO: macros to get nan, inf,
>> positive and negative zeros. Rationale: some code use NAN, _get_nan,
>> etc... NAN is a GNU C extension, INFINITY is not available on many C
>> compilers. The NPY_ macros are defined from the IEEE754 format, and as
>> such should be very fast (the values should be inlined).
>>     - we can now use inline safely in numpy C code: it is defined to
>> something recognized by the compiler or nothing if inline is not
>> supported. It is NOT defined publicly to avoid namespace pollution.
>>     - NPY_INLINE is a macro which can be used publicly, and has the same
>> usage as inline.
>>
>> cheers,
>>
>> David
>> _______________________________________________
>> Numpy-discussion mailing list
>> Numpy-discussion at scipy.org
>> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>>
> Hi,
> I am curious how this relates to Zach's comment in the thread on
> 'Infinity Definitions':

It does not directly - but I implemented those macro after Pauli,
Charles (Harris) and me worked on improving formatting; those macro
replace several ad-hoc solutions through the numpy code base.

Concerning formatting, there is much more consistency with python 2.6
(because python itself bypasses the C runtime and does the parsing
itself), and we followed them. With numpy 1.3, you should almost never
see anything else than nan/inf on any platform. There are still some
cases where it fails, and some cases we can't do anything about (print
'%s' % a, print a, print '%f' % a all go through different codepath,
and we can't control at least one of them, I don't remember which
one).

>
> If this is no longer a concern then we should be able to remove those
> duplicate definitions and use of uppercase.

Yes, we should also fix the pretty print options, so that arrays and
not just scalar arrays print nicely:

a = np.array([np.nan, 1, 2])
print a -> NaN, ...
print a[0] -> nan

But this is much easier, as the code is in python.

cheers,

David