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

Bruce Southey bsouthey@gmail....
Thu Mar 12 15:21:38 CDT 2009


David Cournapeau wrote:
> On Thu, Mar 12, 2009 at 10:19 PM, Bruce Southey <bsouthey@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@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
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>   
Okay,
I have created ticket 1051 for this change with hopefully patches that 
address this.  The patches remove these duplicate definitions and 
uppercase names  but these other usages should be depreciated (but I do 
not know how). After the changes, all tests pass only Linux system for 
Python 2.4, 2.5 and 2.6.

Regards
Bruce




More information about the Numpy-discussion mailing list