Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400968 > unrolled thread
| Started by | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| First post | 2026-08-11 03:01 -0500 |
| Last post | 2026-08-24 19:09 -0500 |
| Articles | 20 on this page of 201 — 17 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: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:36 +0000
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) David Brown <david.brown@hesbynett.no> - 2026-08-13 17:07 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 19:07 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) David Brown <david.brown@hesbynett.no> - 2026-08-13 22:24 +0200
Re: Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Ross Finlayson <ross.a.finlayson@gmail.com> - 2026-08-13 16:36 -0700
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
Calculation of sine with tables (was Re: why is there not a ipow version of pow?) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-13 14:45 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 13:00 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-15 23:17 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-17 10:07 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 00:35 +0300
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 11:22 +0200
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 22:22 +0300
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-18 21:59 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 08:38 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-18 22:17 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 15:42 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 17:44 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-19 21:55 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-19 18:25 -0700
Re: why is there not a ipow version of pow? Michael S <already5chosen@yahoo.com> - 2026-08-20 22:03 +0300
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-21 07:31 -0700
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 04:53 +0800
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? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:33 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 17:12 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-16 17:51 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 18:35 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-16 18:41 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-16 21:30 +0200
Re: why is there not a ipow version of pow? bart <bc@freeuk.com> - 2026-08-16 23:41 +0100
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 08:56 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 03:32 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 08:59 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 11:08 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 03:48 -0700
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 04:25 -0700
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 13:44 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-17 14:26 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 16:58 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-17 16:49 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 09:14 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 02:27 +0200
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-25 17:56 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 03:56 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-23 06:50 -0700
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-17 10:22 -0700
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 19:49 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-17 20:00 +0200
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-17 20:37 +0200
Re: why is there not a ipow version of pow? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-08-26 02:48 +0200
Re: why is there not a ipow version of pow? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-18 18:18 -0700
Re: why is there not a ipow version of pow? cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-18 20:26 +0000
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? bart <bc@freeuk.com> - 2026-08-13 01:30 +0100
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-13 02:24 +0000
Re: why is there not a ipow version of pow? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-12 21:13 -0700
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:33 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 16:45 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 14:55 +0000
Re: why is there not a ipow version of pow? Bonita Montero <Bonita.Montero@gmail.com> - 2026-08-13 18:10 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:16 +0000
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:21 +0000
Re: why is there not a ipow version of pow? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-17 06:37 +0000
Re: why is there not a ipow version of pow? Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-17 21:37 +0800
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 17:19 +0200
Re: why is there not a ipow version of pow? scott@slp53.sl.home (Scott Lurndal) - 2026-08-13 16:09 +0000
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-13 18:52 +0200
Re: why is there not a ipow version of pow? antispam@fricas.org (Waldek Hebisch) - 2026-08-18 16:33 +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
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-21 17:22 -0500
Re: why is there not a ipow version of pow? David Brown <david.brown@hesbynett.no> - 2026-08-22 12:30 +0200
Re: why is there not a ipow version of pow? Lynn McGuire <lynnmcguire5@gmail.com> - 2026-08-24 19:09 -0500
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-23 09:14 -0700 |
| Message-ID | <86v790yfu5.fsf@linuxsc.com> |
| In reply to | #401282 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > scott@slp53.sl.home (Scott Lurndal) writes: > >> David Brown <david.brown@hesbynett.no> writes: > > [...] > >>> Some people see that as an advantage - being able to write "unsigned >>> very_big = -1;". I dislike it personally, but styles and preferences >>> vary, and it has portability advantages over, say, 0xffff'ffff. >> >> I also dislike that use of -1. I prefer using ~0ul to get all-ones. > > I'd use ~0ul to get all-ones, -1 or -1u to get the largest value > of the type (or preferably UINT_MAX, but -1 is good if it's not > obvious *which* unsigned type I'm using). The idea that all ones and the largest value should be treated differently seems rather odd. Surely it is immediately obvious that the largest value (of any unsigned type) will have all bits set to one; using -1 will always provide both. > The fact that they happen to be the same value is a technical detail > that I don't necessarily want to worry about. Whether I use ~0ul > or -1 depends on which concept I want to express. This idea seems even odder. Presumably the point of expressing a concept is to convey it to the reader. I think very few readers would understand what distinction is intended by the different writings here. A simpler and more reliable way is just to use a comment size_t k = -1; // largest value size_t mask = -1; // all ones
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 02:27 +0200 |
| Message-ID | <116lbu1$32eog$5@dont-email.me> |
| In reply to | #401282 |
On 2026-08-18 01:49, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> David Brown <david.brown@hesbynett.no> writes: > [...] >>> Some people see that as an advantage - being able to write "unsigned >>> very_big = -1;". I dislike it personally, but styles and preferences >>> vary, and it has portability advantages over, say, 0xffff'ffff. >> >> I also dislike that use of -1. I prefer using ~0ul to get all-ones. > > I'd use ~0ul to get all-ones, Exactly. As '~' is the bit-complement operator it's the most obvious, most consistent, and thus to be expected to be understood by most if not all C-programmers. But do we need the type qualification at all? A quick test seems to indicate that '~0' can be used for all integral types. (That's what my compiler says, don't know about the standard.) > -1 or -1u to get the largest value > of the type (or preferably UINT_MAX, but -1 is good if it's not > obvious *which* unsigned type I'm using). Isn't SIZE_MAX supposed to cover that for size_t at least? Are there other unsigned types that lack such a constant? (I haven't checked.) > > The fact that they happen to be the same value is a technical detail > that I don't necessarily want to worry about. Whether I use ~0ul > or -1 depends on which concept I want to express. IMO bit-ops for bits, and predefined constants (if available) for the maxima of amount types. The '-1' I consider a typical C-kluge; in "C" I'm used to it so I've no problems if I see that or to use it in cases I'm not too much concerned about, um.., call it "symbolic exactness". Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-08-25 17:56 -0700 |
| Message-ID | <116ldkn$8blf$1@kst.eternal-september.org> |
| In reply to | #401489 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-08-18 01:49, Keith Thompson wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>>> Some people see that as an advantage - being able to write "unsigned
>>>> very_big = -1;". I dislike it personally, but styles and preferences
>>>> vary, and it has portability advantages over, say, 0xffff'ffff.
>>>
>>> I also dislike that use of -1. I prefer using ~0ul to get all-ones.
>> I'd use ~0ul to get all-ones,
>
> Exactly. As '~' is the bit-complement operator it's the most obvious,
> most consistent, and thus to be expected to be understood by most if
> not all C-programmers. But do we need the type qualification at all?
> A quick test seems to indicate that '~0' can be used for all integral
> types. (That's what my compiler says, don't know about the standard.)
>
>> -1 or -1u to get the largest value
>> of the type (or preferably UINT_MAX, but -1 is good if it's not
>> obvious *which* unsigned type I'm using).
-1 is an expression of type int. Converting it to an unsigned type
always yields the largest value of that type. Same for -1 of any signed
type.
-1u is of type unsigned int. Converting it to an unsigned type wider
than unsigned int will not give you the largest value of that type.
Using -1u makes sense only if you know you want a value of type unsigned
int.
#include <stdio.h>
int main(void) {
unsigned long long a = -1;
unsigned long long b = -1u;
printf("%llu\n%llu\n", a, b);
}
18446744073709551615
4294967295
(Results may vary.)
> Isn't SIZE_MAX supposed to cover that for size_t at least? Are there
> other unsigned types that lack such a constant? (I haven't checked.)
I don't know of any unsigned types defined in the standard library that
don't have *_MAX macros (I also haven't checked). User-defined unsigned
types likely won't have *_MAX macros. SIZE_MAX didn't exist in C90
(probably not a concern these days).
[...]
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 03:56 +0200 |
| Message-ID | <116lh3g$32eog$7@dont-email.me> |
| In reply to | #401492 |
On 2026-08-26 02:56, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-18 01:49, Keith Thompson wrote: >>> scott@slp53.sl.home (Scott Lurndal) writes: >>>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >>>>> Some people see that as an advantage - being able to write "unsigned >>>>> very_big = -1;". I dislike it personally, but styles and preferences >>>>> vary, and it has portability advantages over, say, 0xffff'ffff. >>>> >>>> I also dislike that use of -1. I prefer using ~0ul to get all-ones. >>> I'd use ~0ul to get all-ones, >> >> Exactly. As '~' is the bit-complement operator it's the most obvious, >> most consistent, and thus to be expected to be understood by most if >> not all C-programmers. But do we need the type qualification at all? >> A quick test seems to indicate that '~0' can be used for all integral >> types. (That's what my compiler says, don't know about the standard.) >> >>> -1 or -1u to get the largest value >>> of the type (or preferably UINT_MAX, but -1 is good if it's not >>> obvious *which* unsigned type I'm using). > > -1 is an expression of type int. Converting it to an unsigned type > always yields the largest value of that type. Same for -1 of any signed > type. > > -1u is of type unsigned int. Converting it to an unsigned type wider > than unsigned int will not give you the largest value of that type. > Using -1u makes sense only if you know you want a value of type unsigned > int. I'm not sure it was clear that my "But do we need the type qualification at all?" remark was meant for the '~0' context and "all-bits-set case". Mind, you had previously written: "I prefer using ~0ul". - And I was asking whether that would be necessary here, i.e. for the bits-case and unknown sizes of the underlying types. - I'd think that a "generic" '~0' would suffice (and impose the least surprises). (To set _subsets_ of bits to all '1' is a different question.) Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-23 06:50 -0700 |
| Message-ID | <868q5xymgw.fsf@linuxsc.com> |
| In reply to | #401257 |
scott@slp53.sl.home (Scott Lurndal) writes: > [on using -1 to produce all ones in an unsigned type] > > I also dislike that use of -1. I prefer using ~0ul to get all-ones. A problem with patterns like ~0ul is that they are type specific. If the type of the destination changes, a wrong value might be the result. Also constructs using a suffix on an integer constant are limited in which types they can accommodate. Recently I have found it useful to employ 128-bit types, including __uint128_t, which cannot be designated using a suffix. Using cast is even worse. By contrast using -1 always works, regardless of the target type, and even for types outside of the standard basic types. If someone feels the use of -1 needs explaining, that is easily done with a comment: some_unsigned_type foo = -1; // all ones Personally I think every serious C developer should be thoroughly familiar with the use of -1 in conjunction with unsigned types, and not even need the comment. But I recognize that some circumstances may benefit from an explicit gloss.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-17 10:22 -0700 |
| Message-ID | <864igs3bmj.fsf@linuxsc.com> |
| In reply to | #401232 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-17 19:49 +0200 |
| Message-ID | <115vhj2$183lr$9@dont-email.me> |
| In reply to | #401260 |
On 2026-08-17 19:22, Tim Rentsch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: > >>> [...] >> >> Ah, a typical non-answer! - [...] > > What is typical is your usual fractious misdirection style. You > might consider trying to lower your talking-to-thinking ratio. I suppose you're too old to expose a sane level of self-reflection. And hypocritical as well. Just in your recent post you complained about "an overly long thread" and regularly contribute non-answers. You might consider thinking and reflecting about your own posts and socio-pathological behavior before suggesting others what they should do. Good luck! Janis
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-17 20:00 +0200 |
| Message-ID | <115vi86$183lr$10@dont-email.me> |
| In reply to | #401260 |
On 2026-08-17 19:22, Tim Rentsch wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: >>> >>> 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, Fair enough. > where I know compilers will have > no difficulty optimizing out the tail calls. Not all might know whether and what sorts of constructs their compilers are able to optimize. To me it's not obvious that simple (but non-tail-) recursions are typically not optimized. YMMV, but sensible optimizations is IMO task of the compilers; it shouldn't be necessary that you have to formulate programs using a specific programming pattern; ideally - but "C" as had been discussed not long ago exposes anyway a peculiar view of optimizations. (I'm sure YMMV.) Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-17 20:37 +0200 |
| Message-ID | <115vkcp$17o4a$1@dont-email.me> |
| In reply to | #401262 |
On 17/08/2026 20:00, Janis Papanagnou wrote: > On 2026-08-17 19:22, Tim Rentsch wrote: >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >>> On 2026-08-16 16:33, Tim Rentsch wrote: >>>> >>>> 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, > > Fair enough. > >> where I know compilers will have >> no difficulty optimizing out the tail calls. > > Not all might know whether and what sorts of constructs their > compilers are able to optimize. To me it's not obvious that > simple (but non-tail-) recursions are typically not optimized. > YMMV, but sensible optimizations is IMO task of the compilers; > it shouldn't be necessary that you have to formulate programs > using a specific programming pattern; ideally - but "C" as had > been discussed not long ago exposes anyway a peculiar view of > optimizations. (I'm sure YMMV.) > You are correct - it is not at all obvious when a compiler might be able to figure out a loop version of a recursive function. In this case, gcc and clang managed to do so with the code as-is. And there are plenty of compilers (or compiler option choices) that cannot manage any kind of tail recursion optimisation. But it is possible to increase the chances of tail recursion optimisation being applied, by writing code in an appropriate style. As I noted earlier, it will make very little difference in this case because the recursion depth is not going to me more than a couple of levels anyway.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-26 02:48 +0200 |
| Message-ID | <116ld5r$32eoh$1@dont-email.me> |
| In reply to | #401263 |
On 2026-08-17 20:37, David Brown wrote:
> [ [tail] recursion optimisation of ipow() ]
>
> As I noted earlier, it will make very little difference in this case
> because the recursion depth is not going to me more than a couple of
> levels anyway.
BTW, out of curiosity I compiled the iterative version that I've shown
upthread[*] with different optimization levels.
Given that the code primitives are, well, primitive and easily mapable
I didn't expect much but - with a bit of additional code-frame to not
constantly feed the same values for 'a' and 'b' - I recall to have had
got a comparably huge performance gain (2.65 vs. 3.65) for an optimized
ipow() function.
Janis
[*] which had been
long int ipow (long int a, unsigned int n)
{
long int res = 1;
for ( ; n > 0; n /= 2) {
if (n & 1)
res *= a;
a *= a;
}
return res;
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-18 18:18 -0700 |
| Message-ID | <86mrui29ih.fsf@linuxsc.com> |
| In reply to | #401262 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > On 2026-08-17 19:22, Tim Rentsch wrote: > >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> >>> On 2026-08-16 16:33, Tim Rentsch wrote: >>> >>>> 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, > > Fair enough. > >> where I know compilers will have >> no difficulty optimizing out the tail calls. > > Not all might know whether and what sorts of constructs their > compilers are able to optimize. I wasn't advising anyone else what to write; just saying what I would find easier. > To me it's not obvious that > simple (but non-tail-) recursions are typically not optimized. By always using a tail-recursive formulation I don't have to care about what other forms are optimized. As a rule when I write recursive calls that are not tail recursive I expect them to generate actual calls; I don't mind if such cases are optimized but I don't care if they aren't. > YMMV, but sensible optimizations is IMO task of the compilers; > it shouldn't be necessary that you have to formulate programs > using a specific programming pattern; Perhaps I have given a wrong impression. I write code in a functional, and sometimes tail-recursive, style, not because I am thinking about whether it will be optimized but because I find it simple and natural and easy to understand. Of course I wouldn't do that if I thought it were going to perform badly, but I know from experience that it usually gets optimized to a non-recursive form. > ideally - but "C" as had > been discussed not long ago exposes anyway a peculiar view of > optimizations. (I'm sure YMMV.) Tail call elimination has both a long history and a good theoretical underpinning. Part of why it is so attractive is that it's easy to accomplish; I've been aware of and making use of tail call elimination since the early 1970s. I don't find it surprising at all that C compilers (and also compilers for other languages) exploit the ease of effecting these transformation, not only to help runtime performance but also as a way of reducing pressure on stack size. It's like compilers recognizing that multiplying or dividing by powers of two can be turned into shifts -- it allows developers to write code in a natural way, without having to think about what low-level transformations might be helpful to get around simplistic code generators. We are well past the primitive code generators of the 1950s.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2026-08-18 20:26 +0000 |
| Message-ID | <1162f4o$ahi$1@reader1.panix.com> |
| In reply to | #401260 |
In article <864igs3bmj.fsf@linuxsc.com>, Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 2026-08-16 16:33, Tim Rentsch wrote: >>> [snip] >>> 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. At the language level, C does not guarantees tail optimization of recursive calls. Thus, the idea of writing, "a proper tail-recursive implementation from the outset" is a non sequitur. At best, expecting tail call optimization in a C program would be highly dependent on the translation environment. - Dan C.
[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 | #400971 |
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 | #400974 |
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 | #400977 |
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 | #400987 |
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 | #400989 |
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 | #400970 |
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 | #400978 |
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 | #400968 |
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]
Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web