Hello Robert,
>>> 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.
>
> This version looks good to me, except that I wonder if we should try to
> switch to the floating-point version if the integer version would/does
> overflow.
My 0.02€ is that it is under the user control who provides either ints or
doubles as arguments. So I do not think that we should bother, for what my
opinion is worth.
If this is a new requirement, detecting the integer overflow is probably
possible with some testing, eg unexpected changes of sign, but that would
probably add two tests per round, and probably double the computation
cost.
--
Fabien.
