[Numpy-discussion] Core math library in numpy

[David Cournapeau]

On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau <cournape at gmail.com>
> wrote:
>>
>> On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav at iki.fi> wrote:
>> > Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:
>> > [clip]
>> >>> I think they should be. Then we could easily use C99 complex math
>> >>> functions on plaforms on which they are available (and so get the
>> >>> "correct" corner-case semantics for free on these platforms).
>> >>
>> >> maybe we could change the names, then ? nc is not very clear IMHO (and
>> >> since they were static up to now, we are free to change them I
>> >> believe).
>> >
>> > I think it would make sense to change them to follow C99 function names,
>> > with a npy_ prefix.
>>
>> The problem of complex functions is that they don't follow the C99
>> conventions at all. IN particular, they accept pointers instead of
>> values. I don't know whether the rational for using pointers is still
>> valid (it is mentioned that how to pass structure is compiler
>
> The usual rational is that it is more efficient to pass a pointer than to
> push two floats on the stack. It is also an easier way to return values,
> although recent versions of gcc do a good job of copying the return values
> where they need to go. I would stick with the pointers, although we could
> probably dispense with the structure and just use a pointer to the
> underlying type with the assumption that the real & imaginary parts are
> contiguous in memory. The ufuncs make that assumption in any case.

Ok, what about making the decision for complex functions later, and
merging now the the real functions (the one with clear API) ? Having
coremath in trunk would help me tracking down crashes on windows x64
(the trunk does not build right now because of some configuration
problems which are not a concern anymore witht the coremath branch),

cheers,

David