Re: [Numpy-discussion] [RFC] complex functions in npymath
Hi Pauli, Pauli Virtanen wrote: Hi (esp. David), If there are no objections, I'd like to move Numpy's complex-valued C99-like functions to npymath: http://github.com/pv/numpy-work/tree/npymath-complex This'll come useful if we want to start eg. writing Ufuncs in Cython. Actually, I am in the process of cleaning my numpy branches for review, and intend to push them into svn as fast as possible. Complex is pretty high on the list. The missing piece in complex support in npymath is mostly tests: I have tests for all the special cases (all special cases specified in C99 standard are tested), but no test for the actual 'normal' values. If you (or someone else) could add a couple of tests, that would be great. I'm working around possible compiler-incompatibilities of struct return values by having only pointer versions of the functions in libnpymath.a, and the non-pointer versions as inlined static functions. Is this a problem if we guarantee that our complex type is bit compatible with C99 complex (e.g. casting a complex to a double[2] should alway work) ? That's how the complex math is implemented ATM. Also, perhaps we should add a header file npy_math_c99compat.h that would detect if the compiler supports C99, and if not, substitute the C99 functions with our npy_math implementations. This'd be great for scipy.special. I am not sure I understand this: currently, if a given complex function is detected on the platform, npy_foo is just an alias to foo, so we use the platform implementation whenever possible. cheers, David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [RFC] complex functions in npymath
Fri, 30 Oct 2009 18:34:07 +0900, David Cournapeau wrote: [clip] Actually, I am in the process of cleaning my numpy branches for review, and intend to push them into svn as fast as possible. Complex is pretty high on the list. Great! The missing piece in complex support in npymath is mostly tests: I have tests for all the special cases (all special cases specified in C99 standard are tested), but no test for the actual 'normal' values. If you (or someone else) could add a couple of tests, that would be great. I can probably take a shot at this. I'm working around possible compiler-incompatibilities of struct return values by having only pointer versions of the functions in libnpymath.a, and the non-pointer versions as inlined static functions. Is this a problem if we guarantee that our complex type is bit compatible with C99 complex (e.g. casting a complex to a double[2] should alway work) ? That's how the complex math is implemented ATM. Correct me if I'm wrong, but I think the problem is that for typedef struct foo foo_t; foo_t bar(); different compilers may put the return value of bar() to a different place (registers vs. memory). If we put those functions in a library, and switch compilers, I think the behavior is undefined as there seems to be no standard. I don't think functions in C can return arrays, so double[2] representation probably does not help us here. Also, perhaps we should add a header file npy_math_c99compat.h that would detect if the compiler supports C99, and if not, substitute the C99 functions with our npy_math implementations. This'd be great for scipy.special. I am not sure I understand this: currently, if a given complex function is detected on the platform, npy_foo is just an alias to foo, so we use the platform implementation whenever possible. I'd like to write code like this: coshf(a) + sinhf(b) and not like this: npy_coshf(a) + npy_sinhf(b) This seems easy to achieve with a convenience header that substitutes the C99 functions with npy_ functions when C99 is not available. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [RFC] complex functions in npymath
Pauli Virtanen wrote: I can probably take a shot at this. Cool. Correct me if I'm wrong, but I think the problem is that for typedef struct foo foo_t; foo_t bar(); You're right, I was thinking about alignment issues myself - that's why I mentioned npy_complex and double[2] being equivalent, as defining complex with a struct does not guarantee this. different compilers may put the return value of bar() to a different place (registers vs. memory). If we put those functions in a library, and switch compilers, I think the behavior is undefined as there seems to be no standard. Is this a problem in practice ? If two compilers differ in this, wouldn't they have incompatible ABI ? David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [RFC] complex functions in npymath
Pauli Virtanen wrote: I'd like to write code like this: coshf(a) + sinhf(b) and not like this: npy_coshf(a) + npy_sinhf(b) Using npy_ prefix was a consciously designed feature :) I would prefer avoid doing this, as it may cause trouble: sometimes, even if the foo function is available, we may want to use npy_foo because it is better, faster, more standard compliant. For example, I remember that the few complex functions on Visual Studio are broken, so even though they are detected, I have a MSVC ifdef to use our own in that case. David ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [RFC] complex functions in npymath
David Cournapeau skrev: The missing piece in complex support in npymath is mostly tests: I have tests for all the special cases (all special cases specified in C99 standard are tested), but no test for the actual 'normal' values. If you (or someone else) could add a couple of tests, that would be great. In ticket #1271 I reported on some edgecase errors for pow with negative exponents which would be great to include in the test suite as well. /Jörgen ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] [RFC] complex functions in npymath
pe, 2009-10-30 kello 18:57 +0900, David Cournapeau kirjoitti: [clip: struct return values] Is this a problem in practice ? If two compilers differ in this, wouldn't they have incompatible ABI ? Yep, it would be an incompatible ABI. I don't really know how common this in practice -- but there was a comment warning about this in the old ufunc sources, so I wanted to be wary... I don't think there's a significant downside in having thin wrappers around the pointer functions. Googling a bit reveals at least some issues that have cropped up in gcc: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36834 (MSVC vs. gcc) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9506 (bug on freebsd) I'd imagine the situation vs. compilers is here a bit similar to C++ ABIs and sounds like it's a less tested corner of the calling conventions. No idea whether this matters in practice, but at least the above MSVC vs. gcc issue sounds like it might bite. Pauli ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
