[Numpy-discussion] [RFC] complex functions in npymath

[Pauli Virtanen]

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