Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #124609 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2026-08-11 03:01 -0500 |
| Last post | 2026-08-18 11:32 +0200 |
| Articles | 20 on this page of 132 — 15 participants |
Back to article view | Back to comp.lang.c++
why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 03:01 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 13:11 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 12:45 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:34 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 14:55 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:19 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:27 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:08 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:18 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:11 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:20 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:32 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:39 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:33 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:39 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 23:31 +0300
Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-11 11:46 -0400
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 18:35 +0200
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-11 22:53 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:08 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 03:58 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 13:31 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:43 +0300
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 13:44 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-13 00:24 +0300
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 16:49 -0500
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 08:38 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 18:59 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 18:51 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 00:58 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:08 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 15:48 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:51 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 16:40 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 19:24 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 22:51 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 22:33 -0700
Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-15 10:40 -0700
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-15 11:41 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:48 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-16 14:58 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-14 08:57 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:46 -0700
Re: why is there not a ipow version of pow? James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-13 12:59 -0400
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-12 20:23 +0000
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 18:19 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:21 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-11 21:10 +0000
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 00:42 +0300
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:41 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 14:19 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:56 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-12 15:32 +0000
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-12 22:05 +0300
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 19:09 -0400
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-11 21:58 +0300
Re: why is there not a ipow version of pow? Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-11 21:44 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 15:45 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:56 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:23 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:24 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 16:23 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:26 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 17:54 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 18:40 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 08:49 +0200
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-12 09:11 -0400
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 16:05 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-12 12:40 -0700
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 15:46 +0200
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-13 14:28 -0700
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:20 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 18:43 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 19:56 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:41 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:42 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-12 10:23 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 20:24 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 20:27 +0100
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 06:45 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:16 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 15:17 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 15:28 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 16:43 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-11 16:47 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-11 17:24 +0200
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-11 09:36 -0400
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:42 -0500
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-11 19:15 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:41 -0500
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 16:49 -0500
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-11 23:28 +0100
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:51 -0500
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 15:33 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-11 17:49 -0500
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-11 16:19 -0700
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 00:32 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 14:08 +0200
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-12 18:40 +0200
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-14 02:50 +0000
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 04:26 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-12 01:37 -0500
Re: why is there not a ipow version of pow? Paul <nospam@needed.invalid> - 2026-08-13 00:12 -0400
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 11:22 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:00 -0500
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 14:47 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 13:54 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-16 22:49 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 14:56 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 23:53 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 19:59 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 02:47 +0000
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-17 15:17 -0500
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:03 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 03:51 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 12:52 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:01 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:27 -0700
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 13:29 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-15 04:49 +0800
Re: why is there not a ipow version of pow? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-14 20:32 -0700
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-12 11:28 +0100
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-12 23:52 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-13 17:19 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-13 19:07 -0500
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-14 10:58 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-14 01:14 -0500
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 06:40 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:40 +0800
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-18 00:42 -0500
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-18 09:34 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 11:32 +0200
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-11 17:16 +0200 |
| Message-ID | <115fed2$1659$6@dont-email.me> |
| In reply to | #124622 |
On 11/08/2026 16:45, bart wrote:
> On 11/08/2026 15:08, David Brown wrote:
>> On 11/08/2026 15:27, Bonita Montero wrote:
>
>> He said that in his language (we don't know what overheads that has,
>> or what other instructions are used) doing "a ** b" in integers, with
>> the example values of "a = 4" and "b = 3", was five times as fast as
>> calling the external MSVCRT floating point "pow" function. That is a
>> completely different thing, and the only thing surprising (to me)
>> about what he wrote is that the difference is so small.
>
> The integer routine was equivalent to this C version:
>
> 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;
> }
>
That will give basically the same results, probably with similar timing
to my version, as long as the compiler can do tail recursion.
> If I try this instead then I get the same results (which was more like 6
> times as fast as a version applying pow() to floats).
>
>
> I can't run an optimised version as the loop I used will just get
> optimised out.
>
For testing in C, use "volatile" on the inputs and outputs of the thing
you are testing - then you can optimise freely.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-11 15:17 +0200 |
| Message-ID | <115f7cq$1659$1@dont-email.me> |
| In reply to | #124611 |
On 11/08/2026 13:45, bart wrote:
> On 11/08/2026 12:11, Bonita Montero wrote:
>> Am 11.08.2026 um 10:01 schrieb Lynn McGuire:
>>
>>> Why is there not a ipow version of pow?
>>> ipow would return an int instead of a double. Or a long long int.
>>
>> Integer multiplies have nearly the same cost as floating point multi-
>> plies.
>
> Have you done any actual measurements?
Apparently Bonita has not done any such checking.
>
> My language has an "**" operator which is overloaded for ints and floats.
>
> Doing a**b, which uses a special recursive routine for integers, is 5
> times as fast as for floats where it calls out to 'pow()' inside msvcrt
> C library.
>
> (This was for a=4, b=3; it will likely vary for integers depending on b,
> but b is unlikely to be large, as the results would overflow anyway.
> However for 2**63 - I'm using 64 bits - the integer version was still
> twice as fast.)
>
> With C, you are dependent on how well a compiler may optimise it. But an
> expression like c = pow(a, b), where a/b/c are all ints, still seemed to
> call pow() even using gcc-O3.
>
> In fact it is slower than with floats since conversion between ints and
> floats is needed.
>
>
Absolutely.
For small values of b, an inlined integer ipow() function (or built-in
feature of a language or compiler extension) will be a lot faster than
an external floating point function. There are all sorts of overheads
involved in the floating point option - some of which you have mentioned
- that apply even if an individual floating point multiply has the same
cost as an integer multiply. (And they are only the same cost on some
processors, in some circumstances.)
For b = 3, you are just doing "a * a * a" - generated inline, that will
be /far/ smaller than the overheads of converting back and forth between
integer and floating point types, and far below the overhead of an
external dll-based function call, even before you get to the calculation.
And a general-purpose floating-point pow() implementation has to cope
with any possible values of "a" and "b" - that means calculating exp(b *
log(a)). Each of "exp" and "log" is perhaps 60 cycles, and you also
have to use various extra complications to retain accuracy for different
ranges of "a" and "b". I would be surprised to find any value of "a"
and "b" for which "(int64_t) pow(a, b)" was faster than a recursive
integer implementation:
int64_t ipow(int64_t a, uint64_t b) {
return b ? ((b & 1) ? a : 1) * ipow(a * a, b >> 1) : 1;
}
A slightly more sophisticated version could have quick checks for small
values of "b", and tail recursion will turn this into a loop (or that
can be done manually). At worst you have 63 rounds, which will likely
still be faster than an external "pow" function, but of course in real
usage "b" will be much smaller or you'd overflow.
I think the reason that there is no "integer power" function in the
standard C library is that integer powers normally use fixed and small
exponents that are easy enough to write it out manually.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-08-11 15:28 +0200 |
| Message-ID | <115f81t$1b5d$2@raubtier-asyl.eternal-september.org> |
| In reply to | #124614 |
Am 11.08.2026 um 15:17 schrieb David Brown: > For small values of b, an inlined integer ipow() function (or built-in > feature of a language or compiler extension) will be a lot faster than > an external floating point function. ... Prove that. > For b = 3, you are just doing "a * a * a" - generated inline, ... I guess Lynn didn't ask for a solution optimized for constants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-11 16:43 +0200 |
| Message-ID | <115fceu$1659$4@dont-email.me> |
| In reply to | #124617 |
On 11/08/2026 15:28, Bonita Montero wrote:
> Am 11.08.2026 um 15:17 schrieb David Brown:
>
>> For small values of b, an inlined integer ipow() function (or built-in
>> feature of a language or compiler extension) will be a lot faster than
>> an external floating point function. ...
>
> Prove that.
#include <stdint.h>
#include <math.h>
int64_t ipow(int64_t a, uint64_t b) {
return b ? ((b & 1) ? a : 1) * ipow(a * a, b >> 1) : 1;
}
#ifdef INT
#define POW ipow
#endif
#ifdef FLOAT
#define POW pow
#endif
#ifdef FIXEDB
#define BVOL const
#else
#define BVOL volatile
#endif
int main(void) {
volatile int64_t a = 29101;
BVOL uint64_t b = 5;
volatile int64_t c;
uint64_t n = 1000 * 1000 * 1000;
while (n--) {
c = POW(a, b);
}
}
$ gcc-14 -O2 -DINT -o powtest_int powtest.c
$ gcc-14 -O2 -DINT -DFIXEDB -o powtest_int_fixed powtest.c
$ gcc-14 -O2 -DFLOAT -o powtest_float powtest.c -lm
$ gcc-14 -O2 -DFLOAT -DFIXEDB -o powtest_float_fixed powtest.c -lm
$ time ./powtest_int
real 0m1.538s
user 0m1.536s
sys 0m0.001s
$ time ./powtest_int_fixed
real 0m0.807s
user 0m0.805s
sys 0m0.002s
$ time ./powtest_float
real 0m11.219s
user 0m11.217s
sys 0m0.002s
$ time ./powtest_float_fixed
real 0m11.028s
user 0m11.027s
sys 0m0.001s
That's a very rough test, with one set of values, on one system, and no
control about what else might cause variations in the values. But an
inlined integer power function for a small fixed "b" is comfortably more
than 10 times the speed of calling "pow".
>
>> For b = 3, you are just doing "a * a * a" - generated inline, ...
>
> I guess Lynn didn't ask for a solution optimized for constants.
>
Lynn did not ask for any solution, merely an answer as to why there is
no standard "ipow" function.
Real-life usages of integer powers are likely to have small, fixed (at
compile-time) values of "b". But of course only Lynn can say exactly
what the usage would be in his own code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-08-11 16:47 +0200 |
| Message-ID | <115fcml$3263$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124621 |
Try my benchmark. The code is much more professional and in C++.
#include <iostream>
#include <chrono>
using namespace std;
using namespace chrono;
volatile double dOne = 1.0;
volatile uint64_t dU64 = 1;
int main()
{
auto tm = []( const char *what, auto fn )
{
time_point start = steady_clock::now();
uint64_t n = fn();
duration dur = steady_clock::now() - start;
int64_t dur64 = dur.count();
cout << what << (double)dur64 / (double)n << endl;
};
double d = ::dOne;
tm( "fp: ", [&]
{
uint64_t r = 0;
for( ; r < 1'000'000'000; d *= d, ++r );
return r;
} );
uint64_t u = ::dU64;
tm( "int: ", [&]
{
uint64_t r = 0;
for( ; r < 1'000'000'000; u *= u, ++r );
return r;
} );
return (int)d + (int)u;
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-11 17:24 +0200 |
| Message-ID | <115fer4$1659$8@dont-email.me> |
| In reply to | #124623 |
On 11/08/2026 16:47, Bonita Montero wrote: > Try my benchmark. The code is much more professional and in C++. > "Professional" means getting paid for the task. If you want to pay me, I will do "more professional" testing.
[toc] | [prev] | [next] | [standalone]
| From | Paul <nospam@needed.invalid> |
|---|---|
| Date | 2026-08-11 09:36 -0400 |
| Message-ID | <115f8g1$1igf$1@dont-email.me> |
| In reply to | #124610 |
On Tue, 8/11/2026 7:11 AM, Bonita Montero wrote:
> Am 11.08.2026 um 10:01 schrieb Lynn McGuire:
>
>> Why is there not a ipow version of pow?
>> ipow would return an int instead of a double. Or a long long int.
>
> Integer multiplies have nearly the same cost as floating point multi-
> plies. pow() is done with binary exponentation. This means that you
> need a lot of bit-checks an multiplies. This is nearly the same as
> with floating point numbers which don't have fractions. So you can
> stick with fp-values. The only difference is the reduced amount of
> bits (24 vs. 32 or 53 vs. 64).
> But I don't think that's there much usage for such a function.
>
With pow(), you can do pow(2.2,3.3) ==> 13.49
https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_pow.c
/* x^y =e^(y log (X)) */
( https://stackoverflow.com/questions/40824677/how-is-pow-calculated-in-c )
There is also a .tbl file in that source.
Apparently the processor has a mixed method for doing log(),
using a Taylor series and a lookup table of some sort. That suggests,
approximately, that using log() of something isn't going to be
blindingly fast. But that also does not mean anyone has to like the
valid range or how many digits it puts out. A person could craft
their own log().
There are some conditional checks for pow(). Maybe ipow()
has some things to check too.
And you can go on a shopping spree. There is more than one of
these out there, but they are cut for speed, not necessarily
for considering absolutely every condition. The domain and range
could differ, compared to a library quality implementation.
# ipow()
https://gist.github.com/orlp/3551590
Paul
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 16:42 -0500 |
| Message-ID | <115g50r$bacf$2@dont-email.me> |
| In reply to | #124618 |
On 8/11/2026 8:36 AM, Paul wrote: > On Tue, 8/11/2026 7:11 AM, Bonita Montero wrote: >> Am 11.08.2026 um 10:01 schrieb Lynn McGuire: >> >>> Why is there not a ipow version of pow? >>> ipow would return an int instead of a double. Or a long long int. >> >> Integer multiplies have nearly the same cost as floating point multi- >> plies. pow() is done with binary exponentation. This means that you >> need a lot of bit-checks an multiplies. This is nearly the same as >> with floating point numbers which don't have fractions. So you can >> stick with fp-values. The only difference is the reduced amount of >> bits (24 vs. 32 or 53 vs. 64). >> But I don't think that's there much usage for such a function. >> > > With pow(), you can do pow(2.2,3.3) ==> 13.49 > > https://github.com/lattera/glibc/blob/master/sysdeps/ieee754/dbl-64/e_pow.c > > /* x^y =e^(y log (X)) */ > > ( https://stackoverflow.com/questions/40824677/how-is-pow-calculated-in-c ) > > There is also a .tbl file in that source. > > Apparently the processor has a mixed method for doing log(), > using a Taylor series and a lookup table of some sort. That suggests, > approximately, that using log() of something isn't going to be > blindingly fast. But that also does not mean anyone has to like the > valid range or how many digits it puts out. A person could craft > their own log(). > > There are some conditional checks for pow(). Maybe ipow() > has some things to check too. > > And you can go on a shopping spree. There is more than one of > these out there, but they are cut for speed, not necessarily > for considering absolutely every condition. The domain and range > could differ, compared to a library quality implementation. > > # ipow() > > https://gist.github.com/orlp/3551590 > > Paul https://stackoverflow.com/questions/101439/the-most-efficient-way-to-implement-an-integer-based-power-function-powint-int Lynn
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-11 19:15 +0200 |
| Message-ID | <115flbl$3fa9a$4@dont-email.me> |
| In reply to | #124609 |
On 2026-08-11 10:01, Lynn McGuire wrote: > Why is there not a ipow version of pow? It may sound strange (at first glance), but the negated answer would probably be easier to answer. If there were one one could easily formulate some advantages compared to the floating point versions. But since there isn't one we can only speculate and say that possible advantages were probably not considered worthwhile an addition. Other languages support it, probably with overloaded operators for a unified looking expressions experience, but underlying functions may nonetheless differ (depending on the involved types and signatures). > ipow would return an int instead of a double. Or a long long int. Yes. Even the semantics may vary (compared to a float version); e.g. while a (primitive) float version might be formulated using exp/ln for the whole range of numbers an int x int -> int version might not be defined for exponents less than zero. (Or, as I've noticed in one of the posted algorithms, might just return 0.) And real x real -> real and real x int -> real might be two other implementations. All three distinct. Curious; is your question just an academical one (out of interest) or do you have a specific demand for it? When I started programming decades ago accuracy was an issue, so the exp/ln approach was not always appropriate. Also speed of computation. But things have changed since then, concerning accuracy of floats and the speed of math operations. So check your requirements and make sure whether the supported "pow" functions do what you need, else implement one or find a good one on the Internet. (I've seen a sensible looking version posted here in this thread.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 16:41 -0500 |
| Message-ID | <115g4u2$bacf$1@dont-email.me> |
| In reply to | #124641 |
On 8/11/2026 12:15 PM, Janis Papanagnou wrote: > On 2026-08-11 10:01, Lynn McGuire wrote: >> Why is there not a ipow version of pow? > > It may sound strange (at first glance), but the negated answer would > probably be easier to answer. > > If there were one one could easily formulate some advantages compared > to the floating point versions. > > But since there isn't one we can only speculate and say that possible > advantages were probably not considered worthwhile an addition. > > Other languages support it, probably with overloaded operators for a > unified looking expressions experience, but underlying functions may > nonetheless differ (depending on the involved types and signatures). > >> ipow would return an int instead of a double. Or a long long int. > > Yes. Even the semantics may vary (compared to a float version); e.g. > while a (primitive) float version might be formulated using exp/ln > for the whole range of numbers an int x int -> int version might > not be defined for exponents less than zero. (Or, as I've noticed in > one of the posted algorithms, might just return 0.) And real x real > -> real and real x int -> real might be two other implementations. > All three distinct. > > Curious; is your question just an academical one (out of interest) or > do you have a specific demand for it? > > When I started programming decades ago accuracy was an issue, so the > exp/ln approach was not always appropriate. Also speed of computation. > But things have changed since then, concerning accuracy of floats and > the speed of math operations. So check your requirements and make sure > whether the supported "pow" functions do what you need, else implement > one or find a good one on the Internet. (I've seen a sensible looking > version posted here in this thread.) > > Janis I have pow of an integer to an integer power in my code, yes. I am converting 800,000 lines of F77 code to C++. Lynn
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 16:49 -0500 |
| Message-ID | <115g5dd$bi1i$1@dont-email.me> |
| In reply to | #124652 |
On 8/11/2026 4:41 PM, Lynn McGuire wrote:
> On 8/11/2026 12:15 PM, Janis Papanagnou wrote:
>> On 2026-08-11 10:01, Lynn McGuire wrote:
>>> Why is there not a ipow version of pow?
>>
>> It may sound strange (at first glance), but the negated answer would
>> probably be easier to answer.
>>
>> If there were one one could easily formulate some advantages compared
>> to the floating point versions.
>>
>> But since there isn't one we can only speculate and say that possible
>> advantages were probably not considered worthwhile an addition.
>>
>> Other languages support it, probably with overloaded operators for a
>> unified looking expressions experience, but underlying functions may
>> nonetheless differ (depending on the involved types and signatures).
>>
>>> ipow would return an int instead of a double. Or a long long int.
>>
>> Yes. Even the semantics may vary (compared to a float version); e.g.
>> while a (primitive) float version might be formulated using exp/ln
>> for the whole range of numbers an int x int -> int version might
>> not be defined for exponents less than zero. (Or, as I've noticed in
>> one of the posted algorithms, might just return 0.) And real x real
>> -> real and real x int -> real might be two other implementations.
>> All three distinct.
>>
>> Curious; is your question just an academical one (out of interest) or
>> do you have a specific demand for it?
>>
>> When I started programming decades ago accuracy was an issue, so the
>> exp/ln approach was not always appropriate. Also speed of computation.
>> But things have changed since then, concerning accuracy of floats and
>> the speed of math operations. So check your requirements and make sure
>> whether the supported "pow" functions do what you need, else implement
>> one or find a good one on the Internet. (I've seen a sensible looking
>> version posted here in this thread.)
>>
>> Janis
>
> I have pow of an integer to an integer power in my code, yes.
>
> I am converting 800,000 lines of F77 code to C++.
>
> Lynn
Here is some of the code:
longint i__1 = *ng;
for (ig = 1; ig <= i__1; ++ig) {
ihold = 0;
ntype = ntpg[ig - 1];
longint i__2 = ntype;
for (it = 1; it <= i__2; ++it) {
++itup;
igo = grou[itup - 1];
if (it == 1) {
ihldty = igo;
}
iun = defaul[igo - 1];
if (igo == 2 && it > 1) {
iun = 2;
}
if (*iflag == 2 && igo == 8) {
iun = 2;
}
if (*iflag == 2 && igo == 7) {
iun = 1;
}
longint i__3 = it - 1;
ihold += iun * pow (mul, i__3);
}
Lynn
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-08-11 23:28 +0100 |
| Message-ID | <115g7n7$c5tn$1@dont-email.me> |
| In reply to | #124655 |
On 11/08/2026 22:49, Lynn McGuire wrote:
> On 8/11/2026 4:41 PM, Lynn McGuire wrote:
>> On 8/11/2026 12:15 PM, Janis Papanagnou wrote:
>>> On 2026-08-11 10:01, Lynn McGuire wrote:
>>>> Why is there not a ipow version of pow?
>>>
>>> It may sound strange (at first glance), but the negated answer would
>>> probably be easier to answer.
>>>
>>> If there were one one could easily formulate some advantages compared
>>> to the floating point versions.
>>>
>>> But since there isn't one we can only speculate and say that possible
>>> advantages were probably not considered worthwhile an addition.
>>>
>>> Other languages support it, probably with overloaded operators for a
>>> unified looking expressions experience, but underlying functions may
>>> nonetheless differ (depending on the involved types and signatures).
>>>
>>>> ipow would return an int instead of a double. Or a long long int.
>>>
>>> Yes. Even the semantics may vary (compared to a float version); e.g.
>>> while a (primitive) float version might be formulated using exp/ln
>>> for the whole range of numbers an int x int -> int version might
>>> not be defined for exponents less than zero. (Or, as I've noticed in
>>> one of the posted algorithms, might just return 0.) And real x real
>>> -> real and real x int -> real might be two other implementations.
>>> All three distinct.
>>>
>>> Curious; is your question just an academical one (out of interest) or
>>> do you have a specific demand for it?
>>>
>>> When I started programming decades ago accuracy was an issue, so the
>>> exp/ln approach was not always appropriate. Also speed of computation.
>>> But things have changed since then, concerning accuracy of floats and
>>> the speed of math operations. So check your requirements and make sure
>>> whether the supported "pow" functions do what you need, else implement
>>> one or find a good one on the Internet. (I've seen a sensible looking
>>> version posted here in this thread.)
>>>
>>> Janis
>>
>> I have pow of an integer to an integer power in my code, yes.
>>
>> I am converting 800,000 lines of F77 code to C++.
>>
>> Lynn
>
> Here is some of the code:
>
> longint i__1 = *ng;
> for (ig = 1; ig <= i__1; ++ig) {
> ihold = 0;
> ntype = ntpg[ig - 1];
> longint i__2 = ntype;
> for (it = 1; it <= i__2; ++it) {
> ++itup;
> igo = grou[itup - 1];
> if (it == 1) {
> ihldty = igo;
> }
> iun = defaul[igo - 1];
> if (igo == 2 && it > 1) {
> iun = 2;
> }
> if (*iflag == 2 && igo == 8) {
> iun = 2;
> }
> if (*iflag == 2 && igo == 7) {
> iun = 1;
> }
> longint i__3 = it - 1;
> ihold += iun * pow (mul, i__3);
> }
That doesn't look like Fortran! So it's already been converted, and it
was decided to turn A**B (or whatever Fortran used) into pow(A, B)?
However I don't really see the problem. Just write some function 'ipow'
for example (you already have a link to one), and use it in place of 'pow'.
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 17:51 -0500 |
| Message-ID | <115g92c$cja2$2@dont-email.me> |
| In reply to | #124656 |
On 8/11/2026 5:28 PM, bart wrote:
...
>>> I have pow of an integer to an integer power in my code, yes.
>>>
>>> I am converting 800,000 lines of F77 code to C++.
>>>
>>> Lynn
>>
>> Here is some of the code:
>>
>> longint i__1 = *ng;
>> for (ig = 1; ig <= i__1; ++ig) {
>> ihold = 0;
>> ntype = ntpg[ig - 1];
>> longint i__2 = ntype;
>> for (it = 1; it <= i__2; ++it) {
>> ++itup;
>> igo = grou[itup - 1];
>> if (it == 1) {
>> ihldty = igo;
>> }
>> iun = defaul[igo - 1];
>> if (igo == 2 && it > 1) {
>> iun = 2;
>> }
>> if (*iflag == 2 && igo == 8) {
>> iun = 2;
>> }
>> if (*iflag == 2 && igo == 7) {
>> iun = 1;
>> }
>> longint i__3 = it - 1;
>> ihold += iun * pow (mul, i__3);
>> }
>
> That doesn't look like Fortran! So it's already been converted, and it
> was decided to turn A**B (or whatever Fortran used) into pow(A, B)?
>
> However I don't really see the problem. Just write some function 'ipow'
> for example (you already have a link to one), and use it in place of 'pow'.
I agree with writing my own "long long int ipow (long long int, long
long int)" code. Both situations that I have found are in my input file
parser code dealing with dimensional unit conversions. So efficiency is
not a big deal, but rigorousness and correctness is very important to me.
I put BigDigits into my software decades ago but all of the power
functions there are unrolled powers of 2.
https://di-mgt.com.au/bigdigits.html
All of my other power calculations are in my double precision code with
lots and lots and lots of looping.
Thanks to all !
Lynn McGuire
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-11 15:33 -0700 |
| Message-ID | <115g7v0$c4r1$1@kst.eternal-september.org> |
| In reply to | #124652 |
Lynn McGuire <lynnmcguire5@gmail.com> writes:
[...]
>> On 2026-08-11 10:01, Lynn McGuire wrote:
>>> Why is there not a ipow version of pow?
[...]
> I have pow of an integer to an integer power in my code, yes.
>
> I am converting 800,000 lines of F77 code to C++.
It's a perfectly valid question, but I don't think any answer is
going to help you with your immediate problem.
I think the best solution to your immediate problem would be to write
your own ipow() function(s). Depending on the actual exponents,
it might be worth optimizing it by using squaring, so for example
ipow(n, 4) performs 2 multiplications rather than 3. As I recall,
you're already modifying the C code produced by f2c.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 17:49 -0500 |
| Message-ID | <115g8un$cja2$1@dont-email.me> |
| In reply to | #124657 |
On 8/11/2026 5:33 PM, Keith Thompson wrote:
> Lynn McGuire <lynnmcguire5@gmail.com> writes:
> [...]
>>> On 2026-08-11 10:01, Lynn McGuire wrote:
>>>> Why is there not a ipow version of pow?
> [...]
>> I have pow of an integer to an integer power in my code, yes.
>>
>> I am converting 800,000 lines of F77 code to C++.
>
> It's a perfectly valid question, but I don't think any answer is
> going to help you with your immediate problem.
>
> I think the best solution to your immediate problem would be to write
> your own ipow() function(s). Depending on the actual exponents,
> it might be worth optimizing it by using squaring, so for example
> ipow(n, 4) performs 2 multiplications rather than 3. As I recall,
> you're already modifying the C code produced by f2c.
I agree with writing my own "long long int ipow (long long int, long
long int)" code. Both situations that I have found are in my input file
parser code dealing with dimensional unit conversions. So efficiency is
not a big deal, but rigorousness and correctness is very important to me.
I put BigDigits into my software decades ago but all of the power
functions there are unrolled powers of 2.
https://di-mgt.com.au/bigdigits.html
All of my other power calculations are in my double precision code with
lots and lots and lots of looping.
Thanks to all !
Lynn McGuire
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-11 16:19 -0700 |
| Message-ID | <115gamn$c4r1$2@kst.eternal-september.org> |
| In reply to | #124658 |
Lynn McGuire <lynnmcguire5@gmail.com> writes:
> On 8/11/2026 5:33 PM, Keith Thompson wrote:
>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>> [...]
>>>> On 2026-08-11 10:01, Lynn McGuire wrote:
>>>>> Why is there not a ipow version of pow?
>> [...]
>>> I have pow of an integer to an integer power in my code, yes.
>>>
>>> I am converting 800,000 lines of F77 code to C++.
>> It's a perfectly valid question, but I don't think any answer is
>> going to help you with your immediate problem.
>> I think the best solution to your immediate problem would be to
>> write
>> your own ipow() function(s). Depending on the actual exponents,
>> it might be worth optimizing it by using squaring, so for example
>> ipow(n, 4) performs 2 multiplications rather than 3. As I recall,
>> you're already modifying the C code produced by f2c.
>
> I agree with writing my own "long long int ipow (long long int, long
> long int)" code. Both situations that I have found are in my input
> file parser code dealing with dimensional unit conversions. So
> efficiency is not a big deal, but rigorousness and correctness is very
> important to me.
The name "ipow" doesn't suggest an operation on long long.
If you want generality, you might want something like:
int ipow(int, int);
long ipowl(long, int);
long long ipowll(long long, int);
(Or you can overload ipow() if you're using C++, but I thought
you were just converting Fortran to C, which makes me wonder why
you cross-posted.)
Note that I'm assuming the exponent is an int in all cases.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-12 00:32 -0500 |
| Message-ID | <115h0hp$ih3k$1@dont-email.me> |
| In reply to | #124661 |
On 8/11/2026 6:19 PM, Keith Thompson wrote: > Lynn McGuire <lynnmcguire5@gmail.com> writes: >> On 8/11/2026 5:33 PM, Keith Thompson wrote: >>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>> [...] >>>>> On 2026-08-11 10:01, Lynn McGuire wrote: >>>>>> Why is there not a ipow version of pow? >>> [...] >>>> I have pow of an integer to an integer power in my code, yes. >>>> >>>> I am converting 800,000 lines of F77 code to C++. >>> It's a perfectly valid question, but I don't think any answer is >>> going to help you with your immediate problem. >>> I think the best solution to your immediate problem would be to >>> write >>> your own ipow() function(s). Depending on the actual exponents, >>> it might be worth optimizing it by using squaring, so for example >>> ipow(n, 4) performs 2 multiplications rather than 3. As I recall, >>> you're already modifying the C code produced by f2c. >> >> I agree with writing my own "long long int ipow (long long int, long >> long int)" code. Both situations that I have found are in my input >> file parser code dealing with dimensional unit conversions. So >> efficiency is not a big deal, but rigorousness and correctness is very >> important to me. > > The name "ipow" doesn't suggest an operation on long long. > > If you want generality, you might want something like: > > int ipow(int, int); > long ipowl(long, int); > long long ipowll(long long, int); > > > (Or you can overload ipow() if you're using C++, but I thought > you were just converting Fortran to C, which makes me wonder why > you cross-posted.) > > Note that I'm assuming the exponent is an int in all cases. I am converting my F77 code to C++. I am really big on type safety after writing a bunch of Smalltalk code back in the 1980s and 1990s. Lynn
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-08-12 14:08 +0200 |
| Message-ID | <115hnoa$pov1$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124668 |
The difference between my code and that of Fortran 77 are:
* 0 ^ 0 is forbidden with F77, the result of my code is one.
* 0 ^ -n is forbidden with F77, the result of my code is infinite
/ unexpected( true ).
* F77 doesn't have an overflow detection, I return unexpected( false ).
The following code is slightly changed in it's API.
template<typename Int>
constexpr expected<Int, bool> ipow( Int b, Int e )
{
constexpr bool Sgn = is_signed_v<Int>;
using uint = make_unsigned_t<Int>;
constexpr auto
Infinite = unexpected( true ),
Overflow = unexpected( false );
if( !b )
if constexpr( Sgn )
if( e >= 0 )
return !e;
else
return Infinite;
else
return !e;
uint ub = b, ue = e;
if constexpr( Sgn )
if( constexpr auto *Abs = +[]( Int v ) -> uint { return v >= 0 ? v :
0u - (uint)v; };
e >= 0 ) [[likely]]
{
ub = Abs( b );
ue = Abs( e );
}
else
{
Int neg = -(e & 1);
return ((Abs( b ) == 1 ? b : 0) ^ neg) - neg;
}
uint result = 1, sq = ub;
for( int xskip = 0; ue; xskip = 1 ) [[likely]]
{
int skip = countr_zero( ue );
for( int s = skip + xskip; s; sq *= sq, --s ) [[likely]]
if( (uint)(sq * sq) / sq != sq ) [[unlikely]]
return Overflow;
if( (uint)(result * sq) / sq != result ) [[unlikely]]
return Overflow;
result *= sq;
ue >>= skip;
ue >>= 1;
}
constexpr uint UMax = numeric_limits<Int>::min();
if constexpr( Sgn )
if( b < 0 && (e & 1) ) [[unlikely]]
if( result <= UMax ) [[likely]]
result = -(Int)result;
else
return Overflow;
else
if( result >= UMax ) [[unlikely]]
return Overflow;
return (Int)result;
}
A return value of unexpected( true ) is infinity and unexpected( false )
is an overflow.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2026-08-12 18:40 +0200 |
| Message-ID | <115i7m3$vdd6$1@raubtier-asyl.eternal-september.org> |
| In reply to | #124676 |
Nice fact: clang++ and g++ are *much* faster than MSVC with my code. I asked my self why is that and I had a look at the compiled code. I do a "b * e / b == b" check. MSVC uses a division for that. g++ and clang++ just check the overflow flag after doing the multipli- cation. I guess that makes the difference since the other code is similar.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-08-14 02:50 +0000 |
| Message-ID | <115lvp4$2639l$4@dont-email.me> |
| In reply to | #124682 |
On Wed, 12 Aug 2026 18:40:37 +0200, Bonita Montero wrote: > Nice fact: clang++ and g++ are *much* faster than MSVC with my code. > I asked my self why is that and I had a look at the compiled code. I > do a "b * e / b == b" check. MSVC uses a division for that. g++ and > clang++ just check the overflow flag after doing the multiplication. Clever. :)
[toc] | [prev] | [next] | [standalone]
Page 5 of 7 — ← Prev page 1 2 3 4 [5] 6 7 Next page →
Back to top | Article view | comp.lang.c++
csiph-web