Hello,
>> If a double is always returned, I'm wondering whether keeping the ipow
>> version makes much sense: In case of double loss of precision, the
>> precision is lost, too bad, and casting back to int won't bring it back.
>
> I've kept it because knowing that both are ints enables not making a lot of
> checks (done in math.h pow) so it's way faster. In my system it's 2-3ns vs
> ~40ns. I'm willing to settle for using just pow() if that makes it clearer.
Ok, performance is a good argument. I would not have thought that the
double performance would be so bad, but probably no miracle.
As of precision, there is another case where the int computation
overflows, so that the int result is stupid and the double version is a
better approximation. Now that can be controled by providing double or int
arguments to the function, so for me it is ok.
> Attached the updated patch.
Ok.
I have marked it as ready to committer.
Basically for me this is an inferior version, not specially behaving that
better with respect to SQL, but if it eventually gets through a committer
maybe it is worth it.
--
Fabien.