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-18 11:32 +0200 |
| Articles | 20 on this page of 189 — 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? 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-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? 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
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| 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 | 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]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-11 16:41 -0500 |
| Message-ID | <115g4u2$bacf$1@dont-email.me> |
| In reply to | #401012 |
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 | #401032 |
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 | #401035 |
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 | #401036 |
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 | #401032 |
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 | #401037 |
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 | #401038 |
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 | #401041 |
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 | #401054 |
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]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web