David Cournapeau wrote: > On Thu, Mar 12, 2009 at 10:19 PM, Bruce Southey <bsout...@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 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
