<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 20, 2016 at 9:11 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 20, 2016 at 7:58 PM, Charles R Harris<br>
<<a href="mailto:charlesr.harris@gmail.com">charlesr.harris@gmail.com</a>> wrote:<br>
> Hi All,<br>
><br>
> I've put up a preliminary PR for the proposed fpower ufunc. Apart from<br>
> adding more tests and documentation, I'd like to settle a few other things.<br>
> The first is the name, two names have been proposed and we should settle on<br>
> one<br>
><br>
> fpower (short)<br>
> float_power (obvious)<br>
<br>
</span>+0.6 for float_power<br>
<span class=""><br>
> The second thing is the minimum precision. In the preliminary version I have<br>
> used float32, but perhaps it makes more sense for the intended use to make<br>
> the minimum precision float64 instead.<br>
<br>
</span>Can you elaborate on what you're thinking? I guess this is because<br>
float32 has limited range compared to float64, so is more likely to<br>
see overflow? float32 still goes up to 10**38 which is < int64_max**2,<br>
FWIW. Or maybe there's some subtlety with the int->float casting here?<br></blockquote><div><br></div><div>logical, (u)int8, (u)int16, and float16 get converted to float32, which is probably sufficient to avoid overflow and such. My thought was that float32 is something of a "specialized" type these days, while float64 is the standard floating point precision for everyday computation.<br><br></div><div>Chuck <br></div></div></div></div>