Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: why is there not a ipow version of pow?
Date: Mon, 17 Aug 2026 10:22:44 -0700
Organization: A noiseless patient Spider
Lines: 55
Message-ID: <864igs3bmj.fsf@linuxsc.com>
References: <115eks4$3pn1s$1@dont-email.me> <115f01a$3ugcg$1@raubtier-asyl.eternal-september.org> <115f20j$3un9e$1@dont-email.me> <115f64m$ml3$1@raubtier-asyl.eternal-september.org> <115f7h5$1659$2@dont-email.me> <115f7v8$1b5d$1@raubtier-asyl.eternal-september.org> <115facm$1659$3@dont-email.me> <115fchf$2e17$1@dont-email.me> <86y0e62kzd.fsf@linuxsc.com> <115sk02$189sr$4@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 17 Aug 2026 17:22:45 +0000 (UTC)
Injection-Info: dont-email.me; logging-data="1227499"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Oyopgkr8PtZ/7h8ajjZ5MjY2BxIxj3Yg="; posting-host="4b2648bd9e4eaa6a53d150b77bea6188"
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Gzd6zxroiTqdmwYFGNI0HC4a1wQ= sha1:xZuVjbLtuMK/ByG5hB7jezssd3Q= sha256:KFlp8EKEf47G1/hcnFyJWV3KFin3LJSK4QzdAQ7GTqc= sha1:AePT1cRp8VIoap/Z7SrbA1Z81w4= sha256:kOwox3w795A0/Oo8ok9atNfvVFByWocK9d7iRNp5+lc=
Xref: csiph.com comp.lang.c:401260

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 2026-08-16 16:33, Tim Rentsch wrote:
>
>> bart <bc@freeuk.com> writes:
>>
>>> [a C version of someone's ipow() function]
>>>
>>>   long long int ipow(long long a, int n) {
>>>      long long int res;
>>>
>>>      res = 1;
>>>      if (n < 0) {
>>>          res = 0;
>>>
>>>      } else if (n == 0) {
>>>          res = 1;
>>>
>>>      } else if (n == 1) {
>>>          res = a;
>>>
>>>      } else if ((n & 1) == 0) {        // n is even
>>>          res = ipow(a*a, n/2);
>>>
>>>      } else {                          // n is odd
>>>          res = ipow(a*a, (n-1)/2)*a;
>>>      }
>>>
>>>      return res;
>>>   }
>>
>> Two observations:
>>
>> One: one of the recursive calls is not properly tail recursive so
>> the recursion isn't always optimized out.
>
> You could as well write that also from the beginning in an iterative
> form (and not rely on optimizations of recursive functions - in case
> that this is a problem for the compilers in mind).

I find it easier simply to write a properly tail-recursive
implementation from the outset, where I know compilers will have
no difficulty optimizing out the tail calls.

>> Two: it gets wrong answers for in some cases with negative
>> exponents.
>
> Ah, a typical non-answer! - Given that negative exponents are (here)
> generally handled to provide a result of 0 - and assuming that is
> accepted as result, since other libraries may provide an exception
> or error here - what are these "some cases with negative exponents"
> you have in mind;  if you are so deign to give an answer this time.

What is typical is your usual fractious misdirection style.  You
might consider trying to lower your talking-to-thinking ratio.