<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title></title>
</head>
<body>
<div name="messageBodySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;">Hi everyone,
<div><br /></div>
<div>Thanks for this. It looks absolutely fantastic. I've been putting off using numexpr but it looks like I don't have a choice anymore. ;)</div>
<div><br /></div>
<div>Regarding feature requests, I've always found it off putting that I have to wrap my expressions in a string to speed them up. Has anyone explored the possibility of using Python 3.6's frame evaluation API to do this? I remember a vague discussion on this list a while back but I don't know whether anything came of it.</div>
<div><br /></div>
<div>Thanks!</div>
<div><br /></div>
<div>Juan.</div>
</div>
<div name="messageReplySection" style="font-size: 14px; font-family: -apple-system, BlinkMacSystemFont, sans-serif;"><br />
On 18 Feb 2017, 3:42 AM +1100, Robert McLeod <robbmcleod@gmail.com>, wrote:<br />
<blockquote type="cite" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #1abc9c;">
<div dir="ltr">Hi David,
<div><br /></div>
<div>Thanks for your comments, reply below the fold.</div>
<div class="gmail_extra"><br />
<div class="gmail_quote">On Fri, Feb 17, 2017 at 4:34 PM, Daπid <span dir="ltr"><<a href="mailto:davidmenhur@gmail.com" target="_blank">davidmenhur@gmail.com</a>></span> wrote:<br />
<blockquote class="gmail_quote" style="margin: 5px 5px; padding-left: 10px; border-left: thin solid #e67e22;">This is very nice indeed!<br />
<span class="m_6893650384400306529gmail-"><br />
On 17 February 2017 at 12:15, Robert McLeod <<a href="mailto:robbmcleod@gmail.com" target="_blank">robbmcleod@gmail.com</a>> wrote:<br />
> * bytes and unicode support<br />
> * reductions (mean, sum, prod, std)<br />
<br /></span>I use both a lot, maybe I can help you get them working.<br />
<br />
Also, regarding "Vectorization hasn't been done yet with cmath<br />
functions for real numbers (such as sqrt(), exp(), etc.), only for<br />
complex functions". What is the bottleneck? Is it in GCC or just<br />
someone has to sit down and adapt it?</blockquote>
<div><br /></div>
<div>I just haven't done it yet.  Basically I'm moving from Switzerland to Canada in a week so this was the gap to push something out that's usable if not perfect. Rather I just import cmath functions, which are inlined but I suspect what's needed is to break them down into their components. For example, the complex arccos function looks like this:</div>
<div><br /></div>
<div>
<div>static void</div>
<div>nc_acos( npy_intp n, npy_complex64 *x, npy_complex64 *r)</div>
<div>{</div>
<div>    npy_complex64 a;</div>
<div>    for( npy_intp I = 0; I < n; I++ ) {</div>
<div>        a = x[I];</div>
<div>        _inline_mul( x[I], x[I], r[I] );</div>
<div>        _inline_sub( Z_1, r[I], r[I] );</div>
<div>        _inline_sqrt( r[I], r[I] );</div>
<div>        _inline_muli( r[I], r[I] );</div>
<div>        _inline_add( a, r[I], r[I] );</div>
<div>        _inline_log( r[I] , r[I] );</div>
<div>        _inline_muli( r[I], r[I] );</div>
<div>        _inline_neg( r[I], r[I]);</div>
<div>    }</div>
<div>}</div>
</div>
<div><br /></div>
<div>I haven't sat down and inspected whether the cmath versions get vectorized, but there's not a huge speed difference between NE2 and 3 for such a function on float (but their is for complex), so my suspicion is they aren't.  Another option would be to add a library such as Yeppp! as LIB_YEPPP or some other library that's faster than glib.  For example the glib function "fma(a,b,c)" is slower than doing "a*b+c" in NE3, and that's not how it should be.  Yeppp is also built with Python generating C code, so it could either be very easy or very hard.  </div>
<div><br /></div>
<div>On bytes and unicode, I haven't seen examples for how people use it, so I'm not sure where to start. Since there's practically not a limitation on the number of operations now (the library is 1.3 MB now, compared to 1.2 MB for NE2 with gcc 5.4) the string functions could grow significantly from what we have in NE2.</div>
<div> </div>
<div>With regards to reductions, NumExpr never multi-threaded them, and could only do outer reductions, so in the end there was no speed advantage to be had compared to having NumPy do them on the result.  I suspect the primary value there was in PyTables and Pandas where the expression had to do everything.  One of the things I've moved away from in NE3 is doing output buffering (rather it pre-allocates the output array), so for reductions the understanding NumExpr has of broadcasting would have to be deeper.</div>
<div><br /></div>
<div>In any event contributions would certainly be welcome.</div>
<div><br /></div>
<div>Robert</div>
<div><br /></div>
</div>
--<br />
<div class="m_6893650384400306529gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div dir="ltr">Robert McLeod, Ph.D.<br />
Center for Cellular Imaging and Nano Analytics (C-CINA)</div>
<div dir="ltr">Biozentrum der Universität Basel</div>
<div dir="ltr">Mattenstrasse 26, 4058 Basel<br />
Work: <a href="tel:061%20387%2032%2025" value="+41613873225" target="_blank">+41.061.387.3225</a><br />
<a href="mailto:robert.mcleod@unibas.ch" target="_blank">robert.mcleod@unibas.ch</a></div>
<div dir="ltr"><span style="font-size:small"><a href="mailto:robert.mcleod@ethz.ch" target="_blank">robert.mcleod@bsse.ethz.ch</a></span></div>
<div><a href="mailto:robbmcleod@gmail.com" target="_blank">robbmcleod@gmail.com</a><br /></div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br />
NumPy-Discussion mailing list<br />
NumPy-Discussion@scipy.org<br />
https://mail.scipy.org/mailman/listinfo/numpy-discussion<br /></blockquote>
</div>
</body>
</html>