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': http://mail.scipy.org/pipermail/numpy-discussion/2008-July/035740.html
> If I recall correctly, one reason for the plethora of infinity > definitions (which had been mentioned previously on the list) was that > the repr for some or all float/complex types was generated by code in > the host OS, and not in numpy. As such, these reprs were different for > different platforms. As there was a desire to ensure that reprs could > always be evaluated, the various ways that inf and nan could be spit > out by the host libs were all included. > > Has this been fixed now, so that repr(inf), (etc.) looks identical on > all platforms? If this is no longer a concern then we should be able to remove those duplicate definitions and use of uppercase. Bruce _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
