<br><br><div class="gmail_quote">On Wed, Feb 25, 2009 at 11:54 PM, David Cournapeau <span dir="ltr">&lt;<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, Feb 24, 2009 at 7:01 AM, Charles R Harris<br>
<div class="Ih2E3d">&lt;<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt;<br>
</div><div><div></div><div class="Wj3C7c">&gt; On Mon, Feb 23, 2009 at 2:02 PM, David Cournapeau &lt;<a href="mailto:cournape@gmail.com">cournape@gmail.com</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On Fri, Feb 20, 2009 at 5:26 PM, Pauli Virtanen &lt;<a href="mailto:pav@iki.fi">pav@iki.fi</a>&gt; wrote:<br>
&gt;&gt; &gt; Fri, 20 Feb 2009 01:05:03 +0900, David Cournapeau wrote:<br>
&gt;&gt; &gt; [clip]<br>
&gt;&gt; &gt;&gt;&gt; I think they should be. Then we could easily use C99 complex math<br>
&gt;&gt; &gt;&gt;&gt; functions on plaforms on which they are available (and so get the<br>
&gt;&gt; &gt;&gt;&gt; &quot;correct&quot; corner-case semantics for free on these platforms).<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; maybe we could change the names, then ? nc is not very clear IMHO (and<br>
&gt;&gt; &gt;&gt; since they were static up to now, we are free to change them I<br>
&gt;&gt; &gt;&gt; believe).<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I think it would make sense to change them to follow C99 function names,<br>
&gt;&gt; &gt; with a npy_ prefix.<br>
&gt;&gt;<br>
&gt;&gt; The problem of complex functions is that they don&#39;t follow the C99<br>
&gt;&gt; conventions at all. IN particular, they accept pointers instead of<br>
&gt;&gt; values. I don&#39;t know whether the rational for using pointers is still<br>
&gt;&gt; valid (it is mentioned that how to pass structure is compiler<br>
&gt;<br>
&gt; The usual rational is that it is more efficient to pass a pointer than to<br>
&gt; push two floats on the stack. It is also an easier way to return values,<br>
&gt; although recent versions of gcc do a good job of copying the return values<br>
&gt; where they need to go. I would stick with the pointers, although we could<br>
&gt; probably dispense with the structure and just use a pointer to the<br>
&gt; underlying type with the assumption that the real &amp; imaginary parts are<br>
&gt; contiguous in memory. The ufuncs make that assumption in any case.<br>
<br>
</div></div>Ok, what about making the decision for complex functions later, and<br>
merging now the the real functions (the one with clear API) ? Having<br>
coremath in trunk would help me tracking down crashes on windows x64<br>
(the trunk does not build right now because of some configuration<br>
problems which are not a concern anymore witht the coremath branch),<br>
<div><div></div><div class="Wj3C7c"></div></div></blockquote><div><br>Sounds good, I don&#39;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.<br>
<br>I&#39;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.<br>
<br>Chuck<br></div><br></div><br>