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 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-14 22:51 -0500 |
| Message-ID | <115onn9$32bb8$1@dont-email.me> |
| In reply to | #401194 |
On 8/14/2026 9:24 PM, Chris M. Thomasson wrote: > On 8/14/2026 2:40 PM, Lynn McGuire wrote: >> On 8/14/2026 3:51 PM, Chris M. Thomasson wrote: >>> On 8/14/2026 1:48 PM, Lynn McGuire wrote: >>>> On 8/14/2026 2:08 PM, Chris M. Thomasson wrote: >>>>> On 8/13/2026 10:58 PM, Lynn McGuire wrote: >>>>>> On 8/13/2026 8:51 PM, Chris M. Thomasson wrote: >>>>>>> On 8/13/2026 4:59 PM, Lynn McGuire wrote: >>>>>>> [...] >>>>>>>> Mine is coming from a chemical process simulator where chemicals >>>>>>>> are moving between the four phases of matter that we support: >>>>>>>> vapor, hydrocarbon liquid, aqueous liquid, and solids, based on >>>>>>>> temperature and pressure. The tables are incredibly non-linear. >>>>>>>> >>>>>>>> This is my people and I: >>>>>>>> https://www.winsim.com/ >>>>>>> >>>>>>> Notice any fractal growth in there? >>>>>> >>>>>> We don't do that. >>>>> Let me clarify... Do you make renders of a simulation? If so, do >>>>> some of them look fractal? >>>> >>>> In short, no. We have a diagrammatic user interface that allows our >>>> users to build a diagram of a chemical process flow diagram such as >>>> a refinery, a natural gas plan, a pipeline with compressor stations, >>>> or a chemical plant. >>>> https://www.winsim.com/screenshots.html >>>> >>>> And we have a calculation engine that takes a textual version of >>>> that diagram and solves it thermodynamically. If, it can be solved >>>> as not all chemical processes can be solved due to constraints or >>>> violation of the laws of thermodynamics. >>> Ahhhh! So, you are not making any animations of the processes. Okay. >>> But you have the data to do so... >>> >>> Fwiw, I bet you already have the data to make one of my 2d examples >>> here: >>> >>> https://youtu.be/YS-tyDJVy4M >> >> Actually, I do make an animation of the process simulation diagram (PSD). > > Can you give me a link to some screenshots so I can get on the same > page? Thanks. Are you almost done with your Fortran port? ... https://www.winsim.com/screenshots.html I am about 1/3rd of the way done with my 800,000 lines of F77 code to C++ code. My custom version of F2C is doing about 60 to 70% of the work. I am equating the task as equivalent to translating about ten long engineering books from German to French. Lots of idioms and basic incompatibilities that have to be ironed out. I was shooting for the end of 2026 but that ship has sailed. Maybe middle of 2027. Then I have to port to x64 but the port should be easy (he says with the ship sitting in ten feet of mud in the harbor). Lynn
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-14 22:33 -0700 |
| Message-ID | <115otme$33pc0$1@dont-email.me> |
| In reply to | #401198 |
On 8/14/2026 8:51 PM, Lynn McGuire wrote: > On 8/14/2026 9:24 PM, Chris M. Thomasson wrote: >> On 8/14/2026 2:40 PM, Lynn McGuire wrote: >>> On 8/14/2026 3:51 PM, Chris M. Thomasson wrote: >>>> On 8/14/2026 1:48 PM, Lynn McGuire wrote: >>>>> On 8/14/2026 2:08 PM, Chris M. Thomasson wrote: >>>>>> On 8/13/2026 10:58 PM, Lynn McGuire wrote: >>>>>>> On 8/13/2026 8:51 PM, Chris M. Thomasson wrote: >>>>>>>> On 8/13/2026 4:59 PM, Lynn McGuire wrote: >>>>>>>> [...] >>>>>>>>> Mine is coming from a chemical process simulator where >>>>>>>>> chemicals are moving between the four phases of matter that we >>>>>>>>> support: vapor, hydrocarbon liquid, aqueous liquid, and solids, >>>>>>>>> based on temperature and pressure. The tables are incredibly >>>>>>>>> non-linear. >>>>>>>>> >>>>>>>>> This is my people and I: >>>>>>>>> https://www.winsim.com/ >>>>>>>> >>>>>>>> Notice any fractal growth in there? >>>>>>> >>>>>>> We don't do that. >>>>>> Let me clarify... Do you make renders of a simulation? If so, do >>>>>> some of them look fractal? >>>>> >>>>> In short, no. We have a diagrammatic user interface that allows >>>>> our users to build a diagram of a chemical process flow diagram >>>>> such as a refinery, a natural gas plan, a pipeline with compressor >>>>> stations, or a chemical plant. >>>>> https://www.winsim.com/screenshots.html >>>>> >>>>> And we have a calculation engine that takes a textual version of >>>>> that diagram and solves it thermodynamically. If, it can be solved >>>>> as not all chemical processes can be solved due to constraints or >>>>> violation of the laws of thermodynamics. >>>> Ahhhh! So, you are not making any animations of the processes. Okay. >>>> But you have the data to do so... >>>> >>>> Fwiw, I bet you already have the data to make one of my 2d examples >>>> here: >>>> >>>> https://youtu.be/YS-tyDJVy4M >>> >>> Actually, I do make an animation of the process simulation diagram >>> (PSD). >> >> Can you give me a link to some screenshots so I can get on the same >> page? Thanks. Are you almost done with your Fortran port? > ... > > https://www.winsim.com/screenshots.html > > I am about 1/3rd of the way done with my 800,000 lines of F77 code to C+ > + code. My custom version of F2C is doing about 60 to 70% of the work. > I am equating the task as equivalent to translating about ten long > engineering books from German to French. Lots of idioms and basic > incompatibilities that have to be ironed out. > > I was shooting for the end of 2026 but that ship has sailed. Maybe > middle of 2027. Then I have to port to x64 but the port should be easy > (he says with the ship sitting in ten feet of mud in the harbor). > > Lynn > Love the flow sheet. Now from there, can you create a vector field?
[toc] | [prev] | [next] | [standalone]
| From | Ross Finlayson <ross.a.finlayson@gmail.com> |
|---|---|
| Date | 2026-08-15 10:40 -0700 |
| Message-ID | <p8ydnaRNrf8_OR33nZ2dnZfqn_idnZ2d@giganews.com> |
| In reply to | #401198 |
On 08/14/2026 08:51 PM, Lynn McGuire wrote: > On 8/14/2026 9:24 PM, Chris M. Thomasson wrote: >> On 8/14/2026 2:40 PM, Lynn McGuire wrote: >>> On 8/14/2026 3:51 PM, Chris M. Thomasson wrote: >>>> On 8/14/2026 1:48 PM, Lynn McGuire wrote: >>>>> On 8/14/2026 2:08 PM, Chris M. Thomasson wrote: >>>>>> On 8/13/2026 10:58 PM, Lynn McGuire wrote: >>>>>>> On 8/13/2026 8:51 PM, Chris M. Thomasson wrote: >>>>>>>> On 8/13/2026 4:59 PM, Lynn McGuire wrote: >>>>>>>> [...] >>>>>>>>> Mine is coming from a chemical process simulator where >>>>>>>>> chemicals are moving between the four phases of matter that we >>>>>>>>> support: vapor, hydrocarbon liquid, aqueous liquid, and solids, >>>>>>>>> based on temperature and pressure. The tables are incredibly >>>>>>>>> non-linear. >>>>>>>>> >>>>>>>>> This is my people and I: >>>>>>>>> https://www.winsim.com/ >>>>>>>> >>>>>>>> Notice any fractal growth in there? >>>>>>> >>>>>>> We don't do that. >>>>>> Let me clarify... Do you make renders of a simulation? If so, do >>>>>> some of them look fractal? >>>>> >>>>> In short, no. We have a diagrammatic user interface that allows >>>>> our users to build a diagram of a chemical process flow diagram >>>>> such as a refinery, a natural gas plan, a pipeline with compressor >>>>> stations, or a chemical plant. >>>>> https://www.winsim.com/screenshots.html >>>>> >>>>> And we have a calculation engine that takes a textual version of >>>>> that diagram and solves it thermodynamically. If, it can be solved >>>>> as not all chemical processes can be solved due to constraints or >>>>> violation of the laws of thermodynamics. >>>> Ahhhh! So, you are not making any animations of the processes. Okay. >>>> But you have the data to do so... >>>> >>>> Fwiw, I bet you already have the data to make one of my 2d examples >>>> here: >>>> >>>> https://youtu.be/YS-tyDJVy4M >>> >>> Actually, I do make an animation of the process simulation diagram >>> (PSD). >> >> Can you give me a link to some screenshots so I can get on the same >> page? Thanks. Are you almost done with your Fortran port? > ... > > https://www.winsim.com/screenshots.html > > I am about 1/3rd of the way done with my 800,000 lines of F77 code to > C++ code. My custom version of F2C is doing about 60 to 70% of the > work. I am equating the task as equivalent to translating about ten > long engineering books from German to French. Lots of idioms and basic > incompatibilities that have to be ironed out. > > I was shooting for the end of 2026 but that ship has sailed. Maybe > middle of 2027. Then I have to port to x64 but the port should be easy > (he says with the ship sitting in ten feet of mud in the harbor). > > Lynn > Translating the idioms right makes for "naturals" alignment and storage, and so on. Then the numerical methods one imagines are involved in solving linearities for invariants and process control, then that's involved itself, and the relevance of the compatibility of the numerical methods, for their mathematical guarantees, for their physical estimates, about how many traincars and truckloads of feeder stock under what conditions and augury make diapers or galoshes or legos or condoms or pipe or contact lenses or lacquer or petrochemicals or drugs or otherwise usually enough more refined materials from more raw materials. Here it's like "measure-twice cut-once" the old "build a fence a mile, could you move it a foot?" If the great difference for FORTRAN and C is the account of the column-major or row-major and that of arrays and loops, then besides a simplest sort of transpose, or organization and alignment and storage, then is for the model of computation the entry-points and the state & scope, the modules, point being here it's perceived as a quite impressive and thoroughgoing sort of account of quite very much the value the algorithms and numerical methods express as models of control theory. The Bessemer furnace, .... https://en.wikipedia.org/wiki/Bessemer_process Then, there was mentioned "violations of the thermo second law", or rather, "accommodations to effects of resonance theory", these sorts acconts of "effects", which are basically anything outside otherwise the theory, or "exceptions", yes one imagines that those make for the accounts of state & scope the quite complicated, which for example "exception specification" provides in higher-level languages with exception specification as a critical component of safety in the modules of software, quite invokes the deliberations of "why" instead of merely "because". The, "term-rewriting", or a bit more holistically the "term-graph-rewriting", is definitely a thing in software since that "generative programming" is a term from the 1960's, and "program translation" is is quite usual, then for "models of computation" and "modules of computation". Long story short such an endeavor is perceived to be a store of great _value_, and such porting effort is quite a study of both the numerical methods, which as usually approximations need their error-bounds modeled, like Runge-Kutta for example after Gregory & Coates as Newton's, or about Leontief and so on, numerical methods and linear systems and linear solvers, then with regards to standard and empirical units, which are not necessarily the same and where regimes of effect are according to their own units, good luck with that, it sounds like something vital to the real-world economy.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-15 11:41 -0700 |
| Message-ID | <115qbs8$3k7td$1@dont-email.me> |
| In reply to | #401215 |
On 8/15/2026 10:40 AM, Ross Finlayson wrote: [...] > Long story short such an endeavor is perceived to be a store of > great _value_, and such porting effort is quite a study of both > the numerical methods, which as usually approximations need > their error-bounds modeled, like Runge-Kutta for example after > Gregory & Coates as Newton's, or about Leontief and so on, > numerical methods and linear systems and linear solvers, > then with regards to standard and empirical units, which are > not necessarily the same and where regimes of effect are > according to their own units, good luck with that, it sounds > like something vital to the real-world economy. Long story short... I am not using RK for the intermediate vector field integration points, but its still pretty good. Example: https://youtu.be/Doeci7xBYh0
[toc] | [prev] | [next] | [standalone]
| From | Lynn McGuire <lynnmcguire5@gmail.com> |
|---|---|
| Date | 2026-08-17 14:48 -0500 |
| Message-ID | <115voif$19c26$1@dont-email.me> |
| In reply to | #401215 |
On 8/15/2026 12:40 PM, Ross Finlayson wrote: > On 08/14/2026 08:51 PM, Lynn McGuire wrote: >> On 8/14/2026 9:24 PM, Chris M. Thomasson wrote: >>> On 8/14/2026 2:40 PM, Lynn McGuire wrote: >>>> On 8/14/2026 3:51 PM, Chris M. Thomasson wrote: >>>>> On 8/14/2026 1:48 PM, Lynn McGuire wrote: >>>>>> On 8/14/2026 2:08 PM, Chris M. Thomasson wrote: >>>>>>> On 8/13/2026 10:58 PM, Lynn McGuire wrote: >>>>>>>> On 8/13/2026 8:51 PM, Chris M. Thomasson wrote: >>>>>>>>> On 8/13/2026 4:59 PM, Lynn McGuire wrote: >>>>>>>>> [...] >>>>>>>>>> Mine is coming from a chemical process simulator where >>>>>>>>>> chemicals are moving between the four phases of matter that we >>>>>>>>>> support: vapor, hydrocarbon liquid, aqueous liquid, and solids, >>>>>>>>>> based on temperature and pressure. The tables are incredibly >>>>>>>>>> non-linear. >>>>>>>>>> >>>>>>>>>> This is my people and I: >>>>>>>>>> https://www.winsim.com/ >>>>>>>>> >>>>>>>>> Notice any fractal growth in there? >>>>>>>> >>>>>>>> We don't do that. >>>>>>> Let me clarify... Do you make renders of a simulation? If so, do >>>>>>> some of them look fractal? >>>>>> >>>>>> In short, no. We have a diagrammatic user interface that allows >>>>>> our users to build a diagram of a chemical process flow diagram >>>>>> such as a refinery, a natural gas plan, a pipeline with compressor >>>>>> stations, or a chemical plant. >>>>>> https://www.winsim.com/screenshots.html >>>>>> >>>>>> And we have a calculation engine that takes a textual version of >>>>>> that diagram and solves it thermodynamically. If, it can be solved >>>>>> as not all chemical processes can be solved due to constraints or >>>>>> violation of the laws of thermodynamics. >>>>> Ahhhh! So, you are not making any animations of the processes. Okay. >>>>> But you have the data to do so... >>>>> >>>>> Fwiw, I bet you already have the data to make one of my 2d examples >>>>> here: >>>>> >>>>> https://youtu.be/YS-tyDJVy4M >>>> >>>> Actually, I do make an animation of the process simulation diagram >>>> (PSD). >>> >>> Can you give me a link to some screenshots so I can get on the same >>> page? Thanks. Are you almost done with your Fortran port? >> ... >> >> https://www.winsim.com/screenshots.html >> >> I am about 1/3rd of the way done with my 800,000 lines of F77 code to >> C++ code. My custom version of F2C is doing about 60 to 70% of the >> work. I am equating the task as equivalent to translating about ten >> long engineering books from German to French. Lots of idioms and basic >> incompatibilities that have to be ironed out. >> >> I was shooting for the end of 2026 but that ship has sailed. Maybe >> middle of 2027. Then I have to port to x64 but the port should be easy >> (he says with the ship sitting in ten feet of mud in the harbor). >> >> Lynn >> > > Translating the idioms right makes for "naturals" alignment and storage, > and so on. Then the numerical methods one imagines are > involved in solving linearities for invariants and process control, > then that's involved itself, and the relevance of the compatibility > of the numerical methods, for their mathematical guarantees, for > their physical estimates, about how many traincars and truckloads > of feeder stock under what conditions and augury make diapers or > galoshes or legos or condoms or pipe or contact lenses or lacquer > or petrochemicals or drugs or otherwise usually enough more refined > materials from more raw materials. > > Here it's like "measure-twice cut-once" the old "build a fence > a mile, could you move it a foot?" > > If the great difference for FORTRAN and C is the account of > the column-major or row-major and that of arrays and loops, > then besides a simplest sort of transpose, or organization > and alignment and storage, then is for the model of computation > the entry-points and the state & scope, the modules, point being here > it's perceived as a quite impressive and thoroughgoing sort of > account of quite very much the value the algorithms and numerical > methods express as models of control theory. > > The Bessemer furnace, .... > > https://en.wikipedia.org/wiki/Bessemer_process > > Then, there was mentioned "violations of the thermo second law", > or rather, "accommodations to effects of resonance theory", > these sorts acconts of "effects", which are basically anything > outside otherwise the theory, or "exceptions", yes one imagines > that those make for the accounts of state & scope the quite > complicated, which for example "exception specification" provides > in higher-level languages with exception specification as a critical > component of safety in the modules of software, quite invokes the > deliberations of "why" instead of merely "because". > > > The, "term-rewriting", or a bit more holistically the > "term-graph-rewriting", is definitely a thing in software since that > "generative programming" is a term from the 1960's, and "program > translation" is is quite usual, then for "models of computation" > and "modules of computation". > > > Long story short such an endeavor is perceived to be a store of > great _value_, and such porting effort is quite a study of both > the numerical methods, which as usually approximations need > their error-bounds modeled, like Runge-Kutta for example after > Gregory & Coates as Newton's, or about Leontief and so on, > numerical methods and linear systems and linear solvers, > then with regards to standard and empirical units, which are > not necessarily the same and where regimes of effect are > according to their own units, good luck with that, it sounds > like something vital to the real-world economy. Sorry, I lost you in the first part of your reply. If you are saying that it is a tough translation, yes it is. Especially since much of our Fortran was written back in the middle 1960s with Fortran II and Fortran IV (66). We did not convert to Fortran 77 until 1995 or so due to the 2X cost to compile code on the mainframes using the F77 compiler instead of the F66 compiler. And the source code is mostly uncommented since we paid a penny a line / time period (day ? month ? year?) to store the source code on the Univac 1108. The worst part of the translation is converting from arrays starting at one to arrays starting at zero. My translation tool is converting all of the multiple dimensioned arrays to single dimensioned arrays for me to get out of the array ordering issues. I am equating the translation to converting a dozen highly technical books written in German to French. Lynn
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-16 14:58 -0700 |
| Message-ID | <115tbpj$h6t7$1@dont-email.me> |
| In reply to | #401189 |
On 8/14/2026 2:40 PM, Lynn McGuire wrote: [...] Fwiw, check this out, another one of my field renders: https://youtu.be/ygmp_XvdaqQ
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-14 08:57 +0200 |
| Message-ID | <115me88$28idv$1@dont-email.me> |
| In reply to | #401133 |
On 14/08/2026 01:59, Lynn McGuire wrote: > On 8/13/2026 1:38 AM, David Brown wrote: >> On 12/08/2026 23:49, Lynn McGuire wrote: [...] >>> I have found over the years that 200 points seems to be best when >>> performing a numerical integration of a curve. For me, 200 points is >>> the point where diminishing returns has set in. Of course, YMMV. >>> >> >> Your mileage may very much vary. The best number of points depends on >> many factors, such as the type of curve (how "wiggly" it is, whether >> it has additional characteristics like monoticity that you can use, >> etc.), whether you are using linearly separated points or free points, >> how your interpolation works, what characteristics you need for the >> generated results, your required precision, etc. Characteristics of >> the target architecture can influence the best choice of points - >> bigger tables may let you use simpler calculations, but calculations >> may be cheaper than more complicated table lookup schemes. There is >> no single guideline for the number of points in such tables that can >> be useful in any general sense. >> [...] > > Mine is coming from a chemical process simulator where chemicals are > moving between the four phases of matter that we support: vapor, > hydrocarbon liquid, aqueous liquid, and solids, based on temperature and > pressure. The tables are incredibly non-linear. > Sure, for particularly "wiggly" curves, or paths with discontinuities, you need a lot more information to describe them - that means more points, or more complex interpolation between them. (I am using "interpolation" in a general sense here, including any kind of polynomial approximation - not specifically simple linear interpolation.) I have no doubt that you need more points than I need - there is no universal rule of thumb for table size that suits a range of applications.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2026-08-14 12:46 -0700 |
| Message-ID | <115nraf$2qa1t$1@dont-email.me> |
| In reply to | #401152 |
On 8/13/2026 11:57 PM, David Brown wrote:
> On 14/08/2026 01:59, Lynn McGuire wrote:
>> On 8/13/2026 1:38 AM, David Brown wrote:
>>> On 12/08/2026 23:49, Lynn McGuire wrote:
> [...]
>>>> I have found over the years that 200 points seems to be best when
>>>> performing a numerical integration of a curve. For me, 200 points
>>>> is the point where diminishing returns has set in. Of course, YMMV.
>>>>
>>>
>>> Your mileage may very much vary. The best number of points depends
>>> on many factors, such as the type of curve (how "wiggly" it is,
>>> whether it has additional characteristics like monoticity that you
>>> can use, etc.), whether you are using linearly separated points or
>>> free points, how your interpolation works, what characteristics you
>>> need for the generated results, your required precision, etc.
>>> Characteristics of the target architecture can influence the best
>>> choice of points - bigger tables may let you use simpler
>>> calculations, but calculations may be cheaper than more complicated
>>> table lookup schemes. There is no single guideline for the number of
>>> points in such tables that can be useful in any general sense.
>>>
> [...]
>>
>> Mine is coming from a chemical process simulator where chemicals are
>> moving between the four phases of matter that we support: vapor,
>> hydrocarbon liquid, aqueous liquid, and solids, based on temperature
>> and pressure. The tables are incredibly non-linear.
>>
>
> Sure, for particularly "wiggly" curves, or paths with discontinuities,
> you need a lot more information to describe them - that means more
> points, or more complex interpolation between them. (I am using
> "interpolation" in a general sense here, including any kind of
> polynomial approximation - not specifically simple linear
> interpolation.) I have no doubt that you need more points than I need -
> there is no universal rule of thumb for table size that suits a range of
> applications.
>
Here is a fairly interesting interpolation... Fwiw, here is my driver
code. I learned about this algo on a BASIC group. too funny! I ported it
over to my system. It generates some frames for an animation:
#pragma once
#include "ct_multi_thread_field_final.hpp"
#include "ct_cairo.hpp"
#include "ct_complex.hpp"
#include "ct_geometry.hpp"
#include "ct_glm.hpp"
#include <iostream>
#include <vector>
#include <cstdlib>
#include <cstdio>
#include <string>
namespace ct {
namespace swimmer {
struct settings
{
float radius = 1;
float t = 0;
int n_points = 3000;
float lw = 1;
float sin_mul0 = 450;
float sin_mul1 = 930;
};
void
draw(
ct::plot::cairo::plot_2d& plot,
settings const& cfg
) {
glm::vec2 prev(0.0f, 0.0f);
for (int i = 0; i < cfg.n_points; ++i)
{
float a = (float)i / (cfg.n_points - 1);
float at = 2 * a * CT_PI - 8 * cfg.t;
float b = glm::sin(cfg.sin_mul0 * a) * (0.7f +
glm::sin(cfg.sin_mul1 * a));
float e = 2 * a * glm::exp(-a * 8);
float l = 1.5f * (0.7f - a) * (1 - b * b / 8) + cfg.t;
float w = e * b - glm::sin(at) / 12 + 0.75f;
glm::vec2 p(w * glm::cos(l), w * glm::sin(l));
p *= cfg.radius;
if (i > 0)
{
int col = (int)(128 + 127 * glm::cos(4 * b - a * 6));
unsigned char red = (unsigned char)glm::clamp(col,
0, 255);
unsigned char blue = (unsigned char)glm::clamp(255
- col, 0, 255);
ct::plot::cairo::pixel color = CT_RGB(red, 255, blue);
plot.line(prev, p, color, cfg.lw);
}
prev = p;
}
}
void
draw_pinwheel(
ct::plot::cairo::plot_2d& plot,
float t,
unsigned long n = 10
) {
float normal_base = 1.f / (n - 1);
for (unsigned long i = 0; i < n; ++i)
{
float normal = normal_base * i;
float r = normal;
float local_t = normal * n * 10 + t; // outer t
offsets the whole formation
draw(plot, { .radius = r, .t = local_t, .lw = 2 });
}
}
void
manifest_anime(
ct::plot::cairo::plot_2d& scene,
unsigned long fps,
unsigned long duration
) {
unsigned long frames = fps * duration;
float normal_base = 1.f / frames;
for (unsigned long i = 0; i < frames; ++i)
{
float normal = normal_base * i;
float t = CT_PI2 * normal;
scene.clear(CT_RGBF(0, 0, 0));
draw_pinwheel(scene, t, 16);
{
std::string filename =
"./ct_swimmer/frames/ct_frame_" + std::to_string(i) + ".png";
std::cout << "filename = " << filename << "\n";
std::cout << "normal = " << normal << "\n";
std::cout << "t = " << t << std::endl;
scene.save(filename.c_str());
}
}
}
void
manifest(
ct::plot::cairo::plot_2d& scene
) {
std::cout << "ct::swimmer()\n";
std::cout << "__________________________________\n" <<
std::endl;
{
manifest_anime(scene, 24, 5);
}
{
// draw_pinwheel(scene, 0.0f);
// draw_pinwheel(scene, 0.5f);
// draw_pinwheel(scene, 0.75f);
// draw_pinwheel(scene, 1.f);
// draw_pinwheel(scene, 2.f);
//draw_pinwheel(scene, 3.f);
}
}
}
} // ct::swimmer
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-08-13 14:45 +0200 |
| Subject | Calculation of sine with tables (was Re: why is there not a ipow version of pow?) |
| Message-ID | <115ke9q$189sr$2@dont-email.me> |
| In reply to | #401104 |
On 2026-08-13 08:38, David Brown wrote:
> On 12/08/2026 23:49, Lynn McGuire wrote:
>>> [...]
>>
>> I have found over the years that 200 points seems to be best when
>> performing a numerical integration of a curve. For me, 200 points is
>> the point where diminishing returns has set in. Of course, YMMV.
>
> Your mileage may very much vary. The best number of points depends on
> many factors, [...]
That's what I'd also expect. (As far as interpolation is concerned.)
> [...]
>
> For my own uses, I typically need things like sin functions for motor
> control and other such applications. Tables of perhaps 16 or 32 evenly
> spaced points, with cubic interpolation, are often fine to get the
> accuracy I need in a few clock cycles on a microcontroller. (I don't
> think I have ever needed a floating point "pow" on a microcontroller.)
For the sine function I recall some ROM analysis of the PC 1401 pocket
calculator I did (for fun) in my youth. Between all the hex codes of
the assembler commands I stumbled across irregular appearing data. It
turned out that they were used for the trigonometric functions, and I
identified them as CORDIC constants back then. These tables had been,
surprisingly - I didn't knew anything about the underlying math back
then - rather small. Now with help of Google what I find interesting
to read about those table sizes, in the binary case, and in case of
that pocket calculator which uses internally a 12-digit BCD encoding.
"The size of a CORDIC (COordinate Rotation DIgital Computer) angle
lookup table equals the number of iterations (n), where each entry
stores an arctangent value \(\arctan(2^{-i})\) matching the system's
bit width. For standard precision targets, n matches the precision
bit length (e.g., 16 entries for 16-bit, 32 entries for 32-bit),
requiring only tens to hundreds of bytes."
(Which matches with your numbers above. But from your brief mention
I'm not sure the approach you did was comparable with or was CORDIC.)
"The Sharp PC-1401 pocket computer relies on the Hitachi SC61860
8-bit CMOS processor running a specialized BCD (Binary Coded Decimal)
math library in its 40 KB internal ROM. To compute trigonometric and
hyperbolic functions with 10 to 12 digits of precision, the ROM uses
a customized BCD-variant of the CORDIC (Coordinate Rotation Digital
Computer) algorithm."
"Unlike standard binary-based CORDIC implementations that shift bits
by \(2^{-i}\), the PC-1401 processor implements a digit-by-digit BCD
CORDIC calculation (\(10^{-i}\) shifts).
Table Depth (Steps): 11 to 12 entry levels (corresponding to shifts
from 10⁰ down to 10⁻¹⁰ or 10⁻¹¹).
Data Precision: Numbers are processed internally using an 8-byte
(64-bit) BCD floating-point format.
Total Storage Size: The lookup table for the primary rotation angles
(\(\theta_i = \arctan(10^{-i})\)) occupies exactly 88 to 96 bytes
of the 40 KB system ROM."
(Smaller tables with BCD encoding.)
"Why the Table is So Small
Decimal Shifting: By utilizing BCD, the processor does not need a
massive radix conversion table. It multiplies or divides by powers
of 10 simply by shifting 4-bit nibbles across the internal
registers.
Interleaved Functions: The exact same loop structures and angle
tables are shared globally between SIN, COS, TAN, and their inverse
equivalents (ASN, ACS, ATN), saving critical space in the tightly
packed SC613256 ROM chip."
(And speedy BCD-shifts. - Which reminds me the discussion here about
binary shifts in the float representation of 'pow' when using binary
exp/log representations for optimization purposes.)
One "hammer" (a small CORDIC table) for a whole class of functions;
amazing.
Janis
PS: I'm astonished that Google has all that information - after all
that pocket calculator things are just legacy stuff. (Around 1980,
without the Web (or search engines), it had been really a hard job
to find and identify all that information.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-15 13:00 -0700 |
| Message-ID | <86lda740ix.fsf@linuxsc.com> |
| In reply to | #401086 |
Lynn McGuire <lynnmcguire5@gmail.com> writes: > I have found over the years that 200 points seems to be best when > performing a numerical integration of a curve. For me, 200 points is > the point where diminishing returns has set in. Of course, YMMV. Surely that depends on which integration method is being used.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-15 23:17 +0300 |
| Message-ID | <20260815231716.00002b94@yahoo.com> |
| In reply to | #401219 |
On Sat, 15 Aug 2026 13:00:22 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Lynn McGuire <lynnmcguire5@gmail.com> writes: > > > I have found over the years that 200 points seems to be best when > > performing a numerical integration of a curve. For me, 200 points > > is the point where diminishing returns has set in. Of course, > > YMMV. > > Surely that depends on which integration method is being used. That is smaller of my troubles with this post of Lynn. The bigger trouble is that my post, to which he "answered" did not talk at all about integration.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-17 10:07 -0700 |
| Message-ID | <868q643ccm.fsf@linuxsc.com> |
| In reply to | #401220 |
Michael S <already5chosen@yahoo.com> writes: > On Sat, 15 Aug 2026 13:00:22 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Lynn McGuire <lynnmcguire5@gmail.com> writes: >> >>> I have found over the years that 200 points seems to be best when >>> performing a numerical integration of a curve. For me, 200 points >>> is the point where diminishing returns has set in. Of course, >>> YMMV. >> >> Surely that depends on which integration method is being used. > > That is smaller of my troubles with this post of Lynn. > The bigger trouble is that my post, to which he "answered" did not talk > at all about integration. Yeah. Not too surprising really, considering the general level of the discussion -- an overly long thread for a problem that should take at most 15 minutes to solve just by writing an ipow() function.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-18 00:35 +0300 |
| Message-ID | <20260818003501.00002080@yahoo.com> |
| In reply to | #401259 |
On Mon, 17 Aug 2026 10:07:05 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Sat, 15 Aug 2026 13:00:22 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Lynn McGuire <lynnmcguire5@gmail.com> writes: > >> > >>> I have found over the years that 200 points seems to be best when > >>> performing a numerical integration of a curve. For me, 200 points > >>> is the point where diminishing returns has set in. Of course, > >>> YMMV. > >> > >> Surely that depends on which integration method is being used. > > > > That is smaller of my troubles with this post of Lynn. > > The bigger trouble is that my post, to which he "answered" did not > > talk at all about integration. > > Yeah. Not too surprising really, considering the general level > of the discussion -- an overly long thread for a problem that > should take at most 15 minutes to solve just by writing an > ipow() function. Performance of ipow() is quite important in Elliptic Curve Cryptography (ECC). In this field it's worth spending much more than 15 minutes on optimization of this core primitive. Of course, in case of ECC integers are wider than 64-bit (although not dramatically wider, IIRC, 192 bits are considered good enough in many real-world applications) and arithmetic is modular.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-18 11:22 +0200 |
| Message-ID | <116188o$1l41n$5@dont-email.me> |
| In reply to | #401270 |
On 17/08/2026 23:35, Michael S wrote: > On Mon, 17 Aug 2026 10:07:05 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sat, 15 Aug 2026 13:00:22 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>> >>>>> I have found over the years that 200 points seems to be best when >>>>> performing a numerical integration of a curve. For me, 200 points >>>>> is the point where diminishing returns has set in. Of course, >>>>> YMMV. >>>> >>>> Surely that depends on which integration method is being used. >>> >>> That is smaller of my troubles with this post of Lynn. >>> The bigger trouble is that my post, to which he "answered" did not >>> talk at all about integration. >> >> Yeah. Not too surprising really, considering the general level >> of the discussion -- an overly long thread for a problem that >> should take at most 15 minutes to solve just by writing an >> ipow() function. > > Performance of ipow() is quite important in Elliptic Curve Cryptography > (ECC). In this field it's worth spending much more than 15 minutes on > optimization of this core primitive. > Of course, in case of ECC integers are wider than 64-bit (although not > dramatically wider, IIRC, 192 bits are considered good enough in many > real-world applications) and arithmetic is modular. > Sure - but the key pointer there is that the arithmetic is modular. A modular ipower() function is quite different from a non-modular one, and used with very different values. I'd imagine a great deal of effort goes into making them efficient for cryptography (ECC, RSA, etc.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-18 22:22 +0300 |
| Message-ID | <20260818222239.00003f85@yahoo.com> |
| In reply to | #401293 |
On Tue, 18 Aug 2026 11:22:32 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 17/08/2026 23:35, Michael S wrote: > > On Mon, 17 Aug 2026 10:07:05 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> On Sat, 15 Aug 2026 13:00:22 -0700 > >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >>> > >>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: > >>>> > >>>>> I have found over the years that 200 points seems to be best > >>>>> when performing a numerical integration of a curve. For me, > >>>>> 200 points is the point where diminishing returns has set in. > >>>>> Of course, YMMV. > >>>> > >>>> Surely that depends on which integration method is being used. > >>> > >>> That is smaller of my troubles with this post of Lynn. > >>> The bigger trouble is that my post, to which he "answered" did not > >>> talk at all about integration. > >> > >> Yeah. Not too surprising really, considering the general level > >> of the discussion -- an overly long thread for a problem that > >> should take at most 15 minutes to solve just by writing an > >> ipow() function. > > > > Performance of ipow() is quite important in Elliptic Curve > > Cryptography (ECC). In this field it's worth spending much more > > than 15 minutes on optimization of this core primitive. > > Of course, in case of ECC integers are wider than 64-bit (although > > not dramatically wider, IIRC, 192 bits are considered good enough > > in many real-world applications) and arithmetic is modular. > > > > Sure - but the key pointer there is that the arithmetic is modular. > A modular ipower() function is quite different from a non-modular > one, and used with very different values. I'd imagine a great deal > of effort goes into making them efficient for cryptography (ECC, RSA, > etc.) > > The only big difference that modular makes is that with non-modular you can safely assume that big values of n do not matter (except of trivial cases of a = 0 or 1). Apart from that it's quite similar.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-08-18 21:59 +0200 |
| Message-ID | <1162diq$23v07$1@dont-email.me> |
| In reply to | #401302 |
On 18/08/2026 21:22, Michael S wrote: > On Tue, 18 Aug 2026 11:22:32 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 17/08/2026 23:35, Michael S wrote: >>> On Mon, 17 Aug 2026 10:07:05 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> On Sat, 15 Aug 2026 13:00:22 -0700 >>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>>>> >>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>>>> >>>>>>> I have found over the years that 200 points seems to be best >>>>>>> when performing a numerical integration of a curve. For me, >>>>>>> 200 points is the point where diminishing returns has set in. >>>>>>> Of course, YMMV. >>>>>> >>>>>> Surely that depends on which integration method is being used. >>>>> >>>>> That is smaller of my troubles with this post of Lynn. >>>>> The bigger trouble is that my post, to which he "answered" did not >>>>> talk at all about integration. >>>> >>>> Yeah. Not too surprising really, considering the general level >>>> of the discussion -- an overly long thread for a problem that >>>> should take at most 15 minutes to solve just by writing an >>>> ipow() function. >>> >>> Performance of ipow() is quite important in Elliptic Curve >>> Cryptography (ECC). In this field it's worth spending much more >>> than 15 minutes on optimization of this core primitive. >>> Of course, in case of ECC integers are wider than 64-bit (although >>> not dramatically wider, IIRC, 192 bits are considered good enough >>> in many real-world applications) and arithmetic is modular. >>> >> >> Sure - but the key pointer there is that the arithmetic is modular. >> A modular ipower() function is quite different from a non-modular >> one, and used with very different values. I'd imagine a great deal >> of effort goes into making them efficient for cryptography (ECC, RSA, >> etc.) >> >> > > The only big difference that modular makes is that with non-modular you > can safely assume that big values of n do not matter (except of > trivial cases of a = 0 or 1). > Apart from that it's quite similar. > I don't know the details of ECC implementations, so I may be asking silly questions here. I suppose you can do the modulo operation as a multiply by the scaled reciprocal, as compilers generally do when dividing by a compile-time constant. This reciprocal only needs to be calculated once - after that, it's all just multiplies. Is that correct?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-18 08:38 -0700 |
| Message-ID | <86zeyj1lrw.fsf@linuxsc.com> |
| In reply to | #401270 |
Michael S <already5chosen@yahoo.com> writes: > On Mon, 17 Aug 2026 10:07:05 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Sat, 15 Aug 2026 13:00:22 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Lynn McGuire <lynnmcguire5@gmail.com> writes: >>>> >>>>> I have found over the years that 200 points seems to be best >>>>> when performing a numerical integration of a curve. For me, >>>>> 200 points is the point where diminishing returns has set in. >>>>> Of course, YMMV. >>>> >>>> Surely that depends on which integration method is being used. >>> >>> That is smaller of my troubles with this post of Lynn. >>> The bigger trouble is that my post, to which he "answered" did >>> not talk at all about integration. >> >> Yeah. Not too surprising really, considering the general level >> of the discussion -- an overly long thread for a problem that >> should take at most 15 minutes to solve just by writing an >> ipow() function. > > Performance of ipow() is quite important in Elliptic Curve > Cryptography (ECC). In this field it's worth spending much more > than 15 minutes on optimization of this core primitive. > Of course, in case of ECC integers are wider than 64-bit (although > not dramatically wider, IIRC, 192 bits are considered good enough > in many real-world applications) and arithmetic is modular. For the function originally being asked about, where the operations are being done on basic integer types, I think 15 minutes (or so) should be enough. For applications like Elliptic Curve Cryptography, where the values are multiple-precision integers rather than basic integer types, the same algorithm should be okay, except that attention needs to be given to the (modulo-ized) multi-precision multiplications used. The bottleneck is multiplications, not the overall algorithm structure. As an experiment I took the C implementation I first wrote (which had taken five or ten minutes) and wrote the same algorithm in python, except that multiplications were done mod 2**192. I ran trials with that, including for example >>> ipow( 97, 33333333333333333333333333333333333333333333333333333333333 ) 5528880020554650661730432042596473300798439881536715294689 All the trial invocations returned instantly. So I don't think the original basic algorithm needs to be changed; as long as care is given to how the multiplications are done (which python does a fair job at, for this size of operands), a simple implementation should be okay even for applications like ECC.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-08-18 22:17 +0300 |
| Message-ID | <20260818221740.00002511@yahoo.com> |
| In reply to | #401298 |
On Tue, 18 Aug 2026 08:38:43 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> Michael S <already5chosen@yahoo.com> writes:
>
> > On Mon, 17 Aug 2026 10:07:05 -0700
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> Michael S <already5chosen@yahoo.com> writes:
> >>
> >>> On Sat, 15 Aug 2026 13:00:22 -0700
> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >>>
> >>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
> >>>>
> >>>>> I have found over the years that 200 points seems to be best
> >>>>> when performing a numerical integration of a curve. For me,
> >>>>> 200 points is the point where diminishing returns has set in.
> >>>>> Of course, YMMV.
> >>>>
> >>>> Surely that depends on which integration method is being used.
> >>>
> >>> That is smaller of my troubles with this post of Lynn.
> >>> The bigger trouble is that my post, to which he "answered" did
> >>> not talk at all about integration.
> >>
> >> Yeah. Not too surprising really, considering the general level
> >> of the discussion -- an overly long thread for a problem that
> >> should take at most 15 minutes to solve just by writing an
> >> ipow() function.
> >
> > Performance of ipow() is quite important in Elliptic Curve
> > Cryptography (ECC). In this field it's worth spending much more
> > than 15 minutes on optimization of this core primitive.
> > Of course, in case of ECC integers are wider than 64-bit (although
> > not dramatically wider, IIRC, 192 bits are considered good enough
> > in many real-world applications) and arithmetic is modular.
>
> For the function originally being asked about, where the operations
> are being done on basic integer types, I think 15 minutes (or so)
> should be enough.
>
> For applications like Elliptic Curve Cryptography, where the values
> are multiple-precision integers rather than basic integer types, the
> same algorithm should be okay, except that attention needs to be
> given to the (modulo-ized) multi-precision multiplications used.
> The bottleneck is multiplications, not the overall algorithm
> structure.
>
> As an experiment I took the C implementation I first wrote (which
> had taken five or ten minutes) and wrote the same algorithm in
> python, except that multiplications were done mod 2**192. I ran
> trials with that, including for example
>
> >>> ipow( 97,
> >>> 33333333333333333333333333333333333333333333333333333333333 )
> 5528880020554650661730432042596473300798439881536715294689
>
> All the trial invocations returned instantly. So I don't think the
> original basic algorithm needs to be changed; as long as care is
> given to how the multiplications are done (which python does a fair
> job at, for this size of operands), a simple implementation should
> be okay even for applications like ECC.
In my real world case the target was 32-bit microcontroller-class soft
core without hardware multiplier running at 100 MHz. Also, we should not
forget that a single ECDSA signature validation contains plenty of
ipow() steps. Right now I don't remember how many.
I didn't try algorithm presented here by Bart, but tried something that
can be seen as its mirror image.
wword ipow(wword a, wword n)
{
if (n < 2)
return n == 0 ? 1 : a;
wword y = ipow(a, n/2);
y *= y;
if (n & 1)
y *= a;
return y;
}
Please, treat it as a pseudocode.
Real code was more complicated, with function calls instead of *
and recursion was manually converted to iteration.
The result was slower than the following (pseudo) code:
wword ipow(wword a, wword n)
{
wword y = 1, p = a;
while (1) {
if (n & 1)
y *= p;
n /= 2;
if (!n)
break;
p *= p;
}
return y;
}
I didn't try to investiagete reasons for the difference.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-18 15:42 -0700 |
| Message-ID | <86v797124x.fsf@linuxsc.com> |
| In reply to | #401300 |
Michael S <already5chosen@yahoo.com> writes:
> On Tue, 18 Aug 2026 08:38:43 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Mon, 17 Aug 2026 10:07:05 -0700
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Michael S <already5chosen@yahoo.com> writes:
>>>>
>>>>> On Sat, 15 Aug 2026 13:00:22 -0700
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>>>
>>>>>> Lynn McGuire <lynnmcguire5@gmail.com> writes:
>>>>>>
>>>>>>> I have found over the years that 200 points seems to be best
>>>>>>> when performing a numerical integration of a curve. For me,
>>>>>>> 200 points is the point where diminishing returns has set in.
>>>>>>> Of course, YMMV.
>>>>>>
>>>>>> Surely that depends on which integration method is being used.
>>>>>
>>>>> That is smaller of my troubles with this post of Lynn.
>>>>> The bigger trouble is that my post, to which he "answered" did
>>>>> not talk at all about integration.
>>>>
>>>> Yeah. Not too surprising really, considering the general level
>>>> of the discussion -- an overly long thread for a problem that
>>>> should take at most 15 minutes to solve just by writing an
>>>> ipow() function.
>>>
>>> Performance of ipow() is quite important in Elliptic Curve
>>> Cryptography (ECC). In this field it's worth spending much more
>>> than 15 minutes on optimization of this core primitive.
>>> Of course, in case of ECC integers are wider than 64-bit (although
>>> not dramatically wider, IIRC, 192 bits are considered good enough
>>> in many real-world applications) and arithmetic is modular.
>>
>> For the function originally being asked about, where the operations
>> are being done on basic integer types, I think 15 minutes (or so)
>> should be enough.
>>
>> For applications like Elliptic Curve Cryptography, where the values
>> are multiple-precision integers rather than basic integer types, the
>> same algorithm should be okay, except that attention needs to be
>> given to the (modulo-ized) multi-precision multiplications used.
>> The bottleneck is multiplications, not the overall algorithm
>> structure.
>>
>> As an experiment I took the C implementation I first wrote (which
>> had taken five or ten minutes) and wrote the same algorithm in
>> python, except that multiplications were done mod 2**192. I ran
>> trials with that, including for example
>>
>> >>> ipow( 97,
>> >>> 33333333333333333333333333333333333333333333333333333333333 )
>> 5528880020554650661730432042596473300798439881536715294689
>>
>> All the trial invocations returned instantly. So I don't think the
>> original basic algorithm needs to be changed; as long as care is
>> given to how the multiplications are done (which python does a fair
>> job at, for this size of operands), a simple implementation should
>> be okay even for applications like ECC.
>
> In my real world case the target was 32-bit microcontroller-class
> soft core without hardware multiplier running at 100 MHz. Also,
> we should not forget that a single ECDSA signature validation
> contains plenty of ipow() steps. Right now I don't remember how
> many.
>
> I didn't try algorithm presented here by Bart, but tried something
> that can be seen as its mirror image.
>
> wword ipow(wword a, wword n)
> {
> if (n < 2)
> return n == 0 ? 1 : a;
>
> wword y = ipow(a, n/2);
> y *= y;
> if (n & 1)
> y *= a;
> return y;
> }
>
> Please, treat it as a pseudocode.
> Real code was more complicated, with function calls instead of *
> and recursion was manually converted to iteration.
Huh. An unusual way of handling the recursive nature of the
problem. It's not obvious to me how it works exactly.
> The result was slower than the following (pseudo) code:
That isn't surprising, considering that the recursive call
is not tail recursive.
> wword ipow(wword a, wword n)
> {
> wword y = 1, p = a;
> while (1) {
> if (n & 1)
> y *= p;
> n /= 2;
> if (!n)
> break;
> p *= p;
> }
> return y;
> }
>
> I didn't try to investiagete reasons for the difference.
If I were to take a similar approach, I might write
something like this (disclaimer: not compiled):
wword
xpow( wword a, wword n ){
if( n < 2 ){
// handle powers less than 2
// exercise for the reader
}
wword r = 1;
do {
if( n & 1 ) r *= a;
a *= a;
} while( n /= 2, n > 1 );
return r*a;
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-08-18 17:44 -0700 |
| Message-ID | <86qzjv0wit.fsf@linuxsc.com> |
| In reply to | #401313 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> If I were to take a similar approach, I might write
> something like this (disclaimer: not compiled):
>
> wword
> xpow( wword a, wword n ){
> if( n < 2 ){
> // handle powers less than 2
> // exercise for the reader
> }
>
> wword r = 1;
> do {
> if( n & 1 ) r *= a;
> a *= a;
> } while( n /= 2, n > 1 );
>
> return r*a;
> }
Sorry about that.. darn tab characters..
wword
xpow( wword a, wword n ){
if( n < 2 ){
// handle powers less than 2
// exercise for the reader
}
wword r = 1;
do {
if( n & 1 ) r *= a;
a *= a;
} while( n /= 2, n > 1 );
return r*a;
}
[toc] | [prev] | [next] | [standalone]
Page 3 of 10 — ← Prev page 1 2 [3] 4 5 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web