[Numpy-discussion] Core math library in numpy

Charles R Harris charlesr.harris@gmail....
Thu Feb 26 01:32:25 CST 2009

On Wed, Feb 25, 2009 at 11:54 PM, David Cournapeau <cournape@gmail.com>wrote:

> On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris
> <charlesr.harris@gmail.com> wrote:
> >
> >
> > On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau <cournape@gmail.com>
> > wrote:
> >>
> >> On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen <pav@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),

Sounds good, I don't think the complex functions are a pressing concern. But
I suspect we should start looking forward to a code freeze in a month or so
and getting the build working is a clear priority. Maybe we should start the
release process? I have a short list of things I think I should finish up
and now might be a good time to put together a list of things to do.

I've been thinking a bit about the complex functions. It might be worth
benchmarking a few to see how much it costs to pass full complex numbers
back forth. If the functions were inlined the optimizer could probably do
good things with the FPU registers, but how things will work when the
functions are in a library is another question. And rewriting the functions
will be a lot of work unless we can copy a bunch of them from someone else.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20090226/618ba396/attachment-0001.html 

More information about the Numpy-discussion mailing list