<br><br><div class="gmail_quote">On Mon, Jun 1, 2009 at 10:22 AM, Francesc Alted <span dir="ltr"><<a href="mailto:faltet@pytables.org">faltet@pytables.org</a>></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;">
Hi,<br>
<br>
In the process of adding single precision support to Numexpr, I'm<br>
experimenting a divergence between Numexpr and NumPy computations.  It all<br>
boils down to the fact that my implementation defined single precision<br>
functions completely.  As for one, consider my version of expm1f:<br>
<br>
inline static float expm1f(float x)<br>
{<br>
    float u = expf(x);<br>
    if (u == 1.0) {<br>
        return x;<br>
    } else if (u-1.0 == -1.0) {<br>
        return -1;<br>
    } else {<br>
        return (u-1.0) * x/logf(u);<br>
    }<br>
}<br>
<br>
while NumPy seems to declare expm1f as:<br>
<br>
static float expm1f(float x)<br>
{<br>
    return (float) expm1((double)x);<br>
}<br>
<br>
This leads to different results on Windows when computing expm1(x) for large<br>
values of x (like 99.), where my approach returns a 'nan', while NumPy returns<br>
an 'inf'.  Curiously, on Linux both approaches returns 'inf'.<br>
<br>
I suppose that the NumPy crew already experimented this divergence and finally<br>
used the cast approach for computing the single precision functions.</blockquote><div><br>It was inherited and was no doubt the simplest approach at the time. It has always bothered me a bit, however, and if you have good single/long double routines we should look at including them. It will affect the build so David needs to weigh in here.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">However,<br>
this is effectively preventing the use of optimized functions for single<br>
precision (i.e. double precision 'exp' and 'log' are used instead of single<br>
precision specific 'expf' and 'logf'), which could perform potentially better.</blockquote><div><br>That depends on the architecture and how fast single vs double computations are. I don't know how the timings compare on current machines.<br>
 <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
So, I'm wondering if it would not be better to use a native implementation<br>
instead.  Thoughts?<br>
</blockquote><div><br>Some benchmarks would be interesting. Could this be part of the corepy GSOC project?<br><br>Chuck <br></div><br></div><br>