Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #400968 > unrolled thread

why is there not a ipow version of pow?

Back to article view | Back to comp.lang.c

Contents

  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 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10  Next page →

#401229

bart <bc@freeuk.com> writes:

> [a C version of someone's ipow() function]
>
>  long long int ipow(long long a, int n) {
>     long long int res;
>
>     res = 1;
>     if (n < 0) {
>         res = 0;
>
>     } else if (n == 0) {
>         res = 1;
>
>     } else if (n == 1) {
>         res = a;
>
>     } else if ((n & 1) == 0) {        // n is even
>         res = ipow(a*a, n/2);
>
>     } else {                          // n is odd
>         res = ipow(a*a, (n-1)/2)*a;
>     }
>
>     return res;
>  }

Two observations:

One: one of the recursive calls is not properly tail recursive so
the recursion isn't always optimized out.

Two: it gets wrong answers for in some cases with negative
exponents.

[toc] | [prev] | [next] | [standalone]

#401232

On 2026-08-16 16:33, Tim Rentsch wrote:
> bart <bc@freeuk.com> writes:
> 
>> [a C version of someone's ipow() function]
>>
>>   long long int ipow(long long a, int n) {
>>      long long int res;
>>
>>      res = 1;
>>      if (n < 0) {
>>          res = 0;
>>
>>      } else if (n == 0) {
>>          res = 1;
>>
>>      } else if (n == 1) {
>>          res = a;
>>
>>      } else if ((n & 1) == 0) {        // n is even
>>          res = ipow(a*a, n/2);
>>
>>      } else {                          // n is odd
>>          res = ipow(a*a, (n-1)/2)*a;
>>      }
>>
>>      return res;
>>   }
> 
> Two observations:
> 
> One: one of the recursive calls is not properly tail recursive so
> the recursion isn't always optimized out.

You could as well write that also from the beginning in an iterative
form (and not rely on optimizations of recursive functions - in case
that this is a problem for the compilers in mind).

(But personally I find the recursive form clearer than an iterative.)

> 
> Two: it gets wrong answers for in some cases with negative
> exponents.

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

Thanks.

Janis

[toc] | [prev] | [next] | [standalone]

#401234

On 16/08/2026 17:12, Janis Papanagnou wrote:
> On 2026-08-16 16:33, Tim Rentsch wrote:
>> bart <bc@freeuk.com> writes:
>>
>>> [a C version of someone's ipow() function]
>>>
>>>   long long int ipow(long long a, int n) {
>>>      long long int res;
>>>
>>>      res = 1;
>>>      if (n < 0) {
>>>          res = 0;
>>>
>>>      } else if (n == 0) {
>>>          res = 1;
>>>
>>>      } else if (n == 1) {
>>>          res = a;
>>>
>>>      } else if ((n & 1) == 0) {        // n is even
>>>          res = ipow(a*a, n/2);
>>>
>>>      } else {                          // n is odd
>>>          res = ipow(a*a, (n-1)/2)*a;
>>>      }
>>>
>>>      return res;
>>>   }
>>
>> Two observations:
>>
>> One: one of the recursive calls is not properly tail recursive so
>> the recursion isn't always optimized out.
> 
> You could as well write that also from the beginning in an iterative
> form (and not rely on optimizations of recursive functions - in case
> that this is a problem for the compilers in mind).
> 
> (But personally I find the recursive form clearer than an iterative.)
> 
>>
>> Two: it gets wrong answers for in some cases with negative
>> exponents.
> 
> Ah, a typical non-answer! - Given that negative exponents are (here)
> generally handled to provide a result of 0 - and assuming that is
> accepted as result, since other libraries may provide an exception
> or error here - what are these "some cases with negative exponents"
> you have in mind; if you are so deign to give an answer this time.
> 

1 ** n will be 1, even for negative n.  And -1 ** n will be 1 for even 
negative n, -1 for odd negative n.  (Tim does not seem to give useful 
answers much these days - he does drive-bys every few months and leaves 
comments that are not much better than "I'm smarter than you".  He used 
to take more active part in threads, so you'd at least get a more 
helpful response within a few days, but unfortunately that is now uncommon.)

It might not be unreasonable to have fast special cases for n = 1 or -1 
at the start.

gcc and clang have no problem generating iterative code from this 
function, but MSVC did not manage it (or possibly I don't know the right 
MSVC flags - "/O2" was not sufficient in a quick godbolt test).

I don't know how Bart's own compiler copes with such recursive functions 
- I am curious if it can generate an iterative loop here.

[toc] | [prev] | [next] | [standalone]

#401235

On 2026-08-16 17:51, David Brown wrote:
> On 16/08/2026 17:12, Janis Papanagnou wrote:
>> On 2026-08-16 16:33, Tim Rentsch wrote:
>>> bart <bc@freeuk.com> writes:
>>>
>>>> [a C version of someone's ipow() function]
>>>>
>>>>   long long int ipow(long long a, int n) {
>>>>      long long int res;
>>>>
>>>>      res = 1;
>>>>      if (n < 0) {
>>>>          res = 0;
>>>>
>>>>      } else if (n == 0) {
>>>>          res = 1;
>>>>
>>>>      } else if (n == 1) {
>>>>          res = a;
>>>>
>>>>      } else if ((n & 1) == 0) {        // n is even
>>>>          res = ipow(a*a, n/2);
>>>>
>>>>      } else {                          // n is odd
>>>>          res = ipow(a*a, (n-1)/2)*a;
>>>>      }
>>>>
>>>>      return res;
>>>>   }
>>>
>>> Two observations:
>>>
>>> One: one of the recursive calls is not properly tail recursive so
>>> the recursion isn't always optimized out.
>>
>> You could as well write that also from the beginning in an iterative
>> form (and not rely on optimizations of recursive functions - in case
>> that this is a problem for the compilers in mind).
>>
>> (But personally I find the recursive form clearer than an iterative.)
>>
>>>
>>> Two: it gets wrong answers for in some cases with negative
>>> exponents.
>>
>> Ah, a typical non-answer! - Given that negative exponents are (here)
>> generally handled to provide a result of 0 - and assuming that is
>> accepted as result, since other libraries may provide an exception
>> or error here - what are these "some cases with negative exponents"
>> you have in mind; if you are so deign to give an answer this time.
>>
> 
> 1 ** n will be 1, even for negative n. 

For the integer-exponentiation case as topic of the thread - where
negative exponents make little sense - and specifically for bart's
presented code "negative n" is ruled out, or rather it leads always
to 0.

I'd assume you (and Tim) just missed that? (Or what did I miss?)

> And -1 ** n will be 1 for even negative n,

I'd say it would be at best undefined. In the posted code it would
be 0, which is not unsound if we'd read (now coming from the general
case) x**-y as 1/(x**y), which goes (in the 'real' domain) towards 0.

As said, other languages or libraries just bail out for the negative
exponent case  ipow: int x int -> int  (or rather  int x nat -> nat ).

> -1 for odd negative n.  (Tim does not seem to give useful 
> answers much these days - he does drive-bys every few months and leaves 
> comments that are not much better than "I'm smarter than you".  He used 
> to take more active part in threads, so you'd at least get a more 
> helpful response within a few days, but unfortunately that is now 
> uncommon.)

Yes, that's obvious. (But it's cumbersome and not worthwhile to talk
about - crude or else - personalities.)

> [...]
> 
> I don't know how Bart's own compiler copes with such recursive functions 
> - I am curious if it can generate an iterative loop here.

Well, Bart's tools are of little interest - to me at least. But his
posted algorithm is sound, I'd say. And an iterative replacement not
hard to derive. Maybe something like (replacing long long for brevity)

long ipow (long a, int n)
{
     if (n < 0) return 0;

     long res = 1;
     long base = a;  // note: we could also operate on 'a'

     while (n > 0) {
         if (n & 1)
             res *= base;

         base *= base;
         n /= 2;
     }

     return res;
}

But as said, for _clarity_ of code I prefer the functional form.

Janis

[toc] | [prev] | [next] | [standalone]

#401236

On 2026-08-16 18:35, Janis Papanagnou wrote:
> 
> As said, other languages or libraries just bail out for the negative
> exponent case  ipow: int x int -> int  (or rather  int x nat -> nat ).

Oops, typo...    ipow: int x int -> int  (or rather  int x nat -> int ).

Janis

[toc] | [prev] | [next] | [standalone]

#401237

On 16/08/2026 18:35, Janis Papanagnou wrote:
> On 2026-08-16 17:51, David Brown wrote:
>> On 16/08/2026 17:12, Janis Papanagnou wrote:
>>> On 2026-08-16 16:33, Tim Rentsch wrote:
>>>> bart <bc@freeuk.com> writes:
>>>>
>>>>> [a C version of someone's ipow() function]
>>>>>
>>>>>   long long int ipow(long long a, int n) {
>>>>>      long long int res;
>>>>>
>>>>>      res = 1;
>>>>>      if (n < 0) {
>>>>>          res = 0;
>>>>>
>>>>>      } else if (n == 0) {
>>>>>          res = 1;
>>>>>
>>>>>      } else if (n == 1) {
>>>>>          res = a;
>>>>>
>>>>>      } else if ((n & 1) == 0) {        // n is even
>>>>>          res = ipow(a*a, n/2);
>>>>>
>>>>>      } else {                          // n is odd
>>>>>          res = ipow(a*a, (n-1)/2)*a;
>>>>>      }
>>>>>
>>>>>      return res;
>>>>>   }
>>>>
>>>> Two observations:
>>>>
>>>> One: one of the recursive calls is not properly tail recursive so
>>>> the recursion isn't always optimized out.
>>>
>>> You could as well write that also from the beginning in an iterative
>>> form (and not rely on optimizations of recursive functions - in case
>>> that this is a problem for the compilers in mind).
>>>
>>> (But personally I find the recursive form clearer than an iterative.)
>>>
>>>>
>>>> Two: it gets wrong answers for in some cases with negative
>>>> exponents.
>>>
>>> Ah, a typical non-answer! - Given that negative exponents are (here)
>>> generally handled to provide a result of 0 - and assuming that is
>>> accepted as result, since other libraries may provide an exception
>>> or error here - what are these "some cases with negative exponents"
>>> you have in mind; if you are so deign to give an answer this time.
>>>
>>
>> 1 ** n will be 1, even for negative n. 
> 
> For the integer-exponentiation case as topic of the thread - where
> negative exponents make little sense - and specifically for bart's
> presented code "negative n" is ruled out, or rather it leads always
> to 0.
> 
> I'd assume you (and Tim) just missed that? (Or what did I miss?)


I can't speak for Tim, though I would assume he is entirely aware that 
using negative n usually makes little sense for an "ipow" function - and 
I suspect that since the function takes a signed int for "n" and does 
not specify that it is non-negative, he felt the return value should be 
correct for negative "n" even if it is never used.

For my own part, I am entirely aware that negative "n" makes little 
sense in practice.  In the example code I gave for "ipow" in a different 
thread, I specifically used an unsigned type for "n".

> 
>> And -1 ** n will be 1 for even negative n,
> 
> I'd say it would be at best undefined.

Why?  (-1) ** n is well-defined mathematically for all integer "n".  It 
turns up regularly in sum notation when you want to distinguish between 
odd and even terms.  "a ** -n" is just "1 / (a ** n)", so the results 
here have a clear mathematical meaning.

But I can agree that it would rarely be useful to have a negative "n" 
for an integer power function.  And if you want to specify an "ipow" 
function that is for non-negative "n" only, fair enough.

(The really problematic cases are of course "ipow(0, n)" when n <= 0. 
These are best left as UB in the specifications, but an implementation 
might find it easiest just to return 0.  When there is no right answer, 
any answer is reasonable.)

> In the posted code it would
> be 0, which is not unsound if we'd read (now coming from the general
> case) x**-y as 1/(x**y), which goes (in the 'real' domain) towards 0.
> 

Yes, rounding "a ** n" to 0 for negative "n" is perfectly reasonable, in 
all cases except "a = 1" and "a = -1".

> As said, other languages or libraries just bail out for the negative
> exponent case  ipow: int x int -> int  (or rather  int x nat -> nat ).
> 

They can choose to do that.  That's fine.  But it should either be part 
of the function declaration (such as using an unsigned type for "n"), or 
given in the documentation.

>> [...]
>>
>> I don't know how Bart's own compiler copes with such recursive 
>> functions - I am curious if it can generate an iterative loop here.
> 
> Well, Bart's tools are of little interest - to me at least. 

I have no use for his tools either, but I am interested in how well they 
work with code he writes himself in this style.

> But his
> posted algorithm is sound, I'd say. 

With the addition of documentation about negative "n" being UB, or a fix 
for those cases, I agree that his algorithm is fine.

> And an iterative replacement not
> hard to derive. Maybe something like (replacing long long for brevity)
> 
> long ipow (long a, int n)
> {
>      if (n < 0) return 0;
> 
>      long res = 1;
>      long base = a;  // note: we could also operate on 'a'
> 
>      while (n > 0) {
>          if (n & 1)
>              res *= base;
> 
>          base *= base;
>          n /= 2;
>      }
> 
>      return res;
> }
> 
> But as said, for _clarity_ of code I prefer the functional form.
> 

Me too.

[toc] | [prev] | [next] | [standalone]

#401240

On 16/08/2026 20:30, David Brown wrote:
> On 16/08/2026 18:35, Janis Papanagnou wrote:

>> Well, Bart's tools are of little interest - to me at least. 
> 
> I have no use for his tools either, but I am interested in how well they 
> work with code he writes himself in this style.

They do nothing clever. With the version below, one test I did had these 
results (with the ipow function in a different file from the test code):

  gcc -O3    0.56 s
  clang -O3  0.78 s
  bcc        1.12 s
  lccwin32   1.19 s
  DMC        1.4  s (32-bit code)
  tcc        1.43 s



>> But his
>> posted algorithm is sound, I'd say. 
> 
> With the addition of documentation about negative "n" being UB, or a fix 
> for those cases, I agree that his algorithm is fine.


It's not mine, I just found it somewhere.


-----------------------------------

long long int ipow(long long a, unsigned int n) {
     if (n == 0) {
         return 1;

     } else if (n == 1) {
         return a;

     } else if ((n & 1) == 0) {        // n is even
         return ipow(a*a, n/2);

     } else {                          // n is odd
         return ipow(a*a, (n-1)/2)*a;
     }
  }

[toc] | [prev] | [next] | [standalone]

#401247

On 17/08/2026 00:41, bart wrote:
> On 16/08/2026 20:30, David Brown wrote:
>> On 16/08/2026 18:35, Janis Papanagnou wrote:
> 
>>> Well, Bart's tools are of little interest - to me at least. 
>>
>> I have no use for his tools either, but I am interested in how well 
>> they work with code he writes himself in this style.
> 
> They do nothing clever. With the version below, one test I did had these 
> results (with the ipow function in a different file from the test code):

OK.  I was merely curious if you were able to do tail recursion so that 
your code here was more efficient.  It's not going to make a big 
difference in practice - since real-world code will use small values of 
"n", the recursion depth is going to be very small too.

> 
>   gcc -O3    0.56 s
>   clang -O3  0.78 s
>   bcc        1.12 s
>   lccwin32   1.19 s
>   DMC        1.4  s (32-bit code)
>   tcc        1.43 s
> 
> 
> 
>>> But his
>>> posted algorithm is sound, I'd say. 
>>
>> With the addition of documentation about negative "n" being UB, or a 
>> fix for those cases, I agree that his algorithm is fine.
> 
> 
> It's not mine, I just found it somewhere.
> 
Fair enough.

[toc] | [prev] | [next] | [standalone]

#401244

On 2026-08-16 21:30, David Brown wrote:
> On 16/08/2026 18:35, Janis Papanagnou wrote:
[...]
> 
>> But his posted algorithm is sound, I'd say. 
> 
> With the addition of documentation about negative "n" being UB, or a fix 
> for those cases, I agree that his algorithm is fine.

Actually, programming lots of Algol68 lately, I used a few patterns
from that language also in my iterative code. (I had mentioned the
unnecessary use of the "base" variable, and the 'int' parameter was
also a remains.) In "C" (and forgetting Algol 68 for a moment) I'd
probably have written it more "C-ish"; i.e. using an 'unsigned int'
for the parameter 'n' to more clearly define its range as positive,
operating directly on 'a', and condensing the 'while' loop by 'for'.

long int ipow (long int a, unsigned int n)
{
     long int res = 1;
     for ( ; n > 0; n /= 2) {
         if (n & 1)
             res *= a;
         a *= a;
     }
     return res;
}

The "n < 0" case can then also be omitted completely and adds to its
brevity.

I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
feed the 'ipow' function with '-1', but that's C's inherent problem.

Janis

[toc] | [prev] | [next] | [standalone]

#401248

On 17/08/2026 03:32, Janis Papanagnou wrote:
> On 2026-08-16 21:30, David Brown wrote:
>> On 16/08/2026 18:35, Janis Papanagnou wrote:
> [...]
>>
>>> But his posted algorithm is sound, I'd say. 
>>
>> With the addition of documentation about negative "n" being UB, or a 
>> fix for those cases, I agree that his algorithm is fine.
> 
> Actually, programming lots of Algol68 lately, I used a few patterns
> from that language also in my iterative code. (I had mentioned the
> unnecessary use of the "base" variable, and the 'int' parameter was
> also a remains.) In "C" (and forgetting Algol 68 for a moment) I'd
> probably have written it more "C-ish"; i.e. using an 'unsigned int'
> for the parameter 'n' to more clearly define its range as positive,
> operating directly on 'a', and condensing the 'while' loop by 'for'.
> 
> long int ipow (long int a, unsigned int n)
> {
>      long int res = 1;
>      for ( ; n > 0; n /= 2) {
>          if (n & 1)
>              res *= a;
>          a *= a;
>      }
>      return res;
> }
> 
> The "n < 0" case can then also be omitted completely and adds to its
> brevity.

That was my thought, yes.

> 
> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
> feed the 'ipow' function with '-1', but that's C's inherent problem.
> 

Some people see that as an advantage - being able to write "unsigned 
very_big = -1;".  I dislike it personally, but styles and preferences 
vary, and it has portability advantages over, say, 0xffff'ffff.

[toc] | [prev] | [next] | [standalone]

#401249

On 2026-08-17 08:59, David Brown wrote:
> On 17/08/2026 03:32, Janis Papanagnou wrote:
>>
>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>> feed the 'ipow' function with '-1', but that's C's inherent problem.
> 
> Some people see that as an advantage - being able to write "unsigned 
> very_big = -1;".  I dislike it personally, but styles and preferences 
> vary, and it has portability advantages over, say, 0xffff'ffff.

Actually I'm ambivalent on that one. I've used -1 occasionally when
I'm mentally operating in "C-mode"; each language has its ideograms
and specific code and design patterns. But in other languages I do
use things like 'min int' for that - where it's peculiar that I don't
do that in "C" since it's (meanwhile) also available; but I had been
socialized by K&R and it obviously left its traces.

Usually I prefer languages and compilers to tell me whenever I pass
a value that isn't matching the type.

Janis

[toc] | [prev] | [next] | [standalone]

#401250

David Brown <david.brown@hesbynett.no> writes:
> On 17/08/2026 03:32, Janis Papanagnou wrote:
[...]
>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>> feed the 'ipow' function with '-1', but that's C's inherent problem.
>
> Some people see that as an advantage - being able to write "unsigned
> very_big = -1;".  I dislike it personally, but styles and preferences
> vary, and it has portability advantages over, say, 0xffff'ffff.

Sure, but the advantage isn't applicable in this case.  If ipow's
second parameter is unsigned, ipow(n, -1) is going to overflow,
not compute 1/n.

-- 
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]

#401252

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/08/2026 03:32, Janis Papanagnou wrote:
> [...]
>>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>>> feed the 'ipow' function with '-1', but that's C's inherent problem.
>>
>> Some people see that as an advantage - being able to write "unsigned
>> very_big = -1;".  I dislike it personally, but styles and preferences
>> vary, and it has portability advantages over, say, 0xffff'ffff.
>
> Sure, but the advantage isn't applicable in this case.  If ipow's
> second parameter is unsigned, ipow(n, -1) is going to overflow,
> not compute 1/n.

Well, it's not going to overflow if n is -1 or 1.

-- 
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]

#401253

On 17/08/2026 13:25, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 17/08/2026 03:32, Janis Papanagnou wrote:
>> [...]
>>>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>>>> feed the 'ipow' function with '-1', but that's C's inherent problem.
>>>
>>> Some people see that as an advantage - being able to write "unsigned
>>> very_big = -1;".  I dislike it personally, but styles and preferences
>>> vary, and it has portability advantages over, say, 0xffff'ffff.
>>
>> Sure, but the advantage isn't applicable in this case.  

Agreed.

>> If ipow's
>> second parameter is unsigned, ipow(n, -1) is going to overflow,
>> not compute 1/n.
> 
> Well, it's not going to overflow if n is -1 or 1.
> 

[toc] | [prev] | [next] | [standalone]

#401257

David Brown <david.brown@hesbynett.no> writes:
>On 17/08/2026 03:32, Janis Papanagnou wrote:
>> On 2026-08-16 21:30, David Brown wrote:
>>> On 16/08/2026 18:35, Janis Papanagnou wrote:
>> [...]
>>>
>>>> But his posted algorithm is sound, I'd say. 
>>>
>>> With the addition of documentation about negative "n" being UB, or a 
>>> fix for those cases, I agree that his algorithm is fine.
>> 
>> Actually, programming lots of Algol68 lately, I used a few patterns
>> from that language also in my iterative code. (I had mentioned the
>> unnecessary use of the "base" variable, and the 'int' parameter was
>> also a remains.) In "C" (and forgetting Algol 68 for a moment) I'd
>> probably have written it more "C-ish"; i.e. using an 'unsigned int'
>> for the parameter 'n' to more clearly define its range as positive,
>> operating directly on 'a', and condensing the 'while' loop by 'for'.
>> 
>> long int ipow (long int a, unsigned int n)
>> {
>>      long int res = 1;
>>      for ( ; n > 0; n /= 2) {
>>          if (n & 1)
>>              res *= a;
>>          a *= a;
>>      }
>>      return res;
>> }
>> 
>> The "n < 0" case can then also be omitted completely and adds to its
>> brevity.
>
>That was my thought, yes.
>
>> 
>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>> feed the 'ipow' function with '-1', but that's C's inherent problem.
>> 
>
>Some people see that as an advantage - being able to write "unsigned 
>very_big = -1;".  I dislike it personally, but styles and preferences 
>vary, and it has portability advantages over, say, 0xffff'ffff.
>

I also dislike that use of -1.  I prefer using ~0ul to get all-ones.

[toc] | [prev] | [next] | [standalone]

#401258

On 17/08/2026 16:26, Scott Lurndal wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 17/08/2026 03:32, Janis Papanagnou wrote:
>>> On 2026-08-16 21:30, David Brown wrote:
>>>> On 16/08/2026 18:35, Janis Papanagnou wrote:
>>> [...]
>>>>
>>>>> But his posted algorithm is sound, I'd say.
>>>>
>>>> With the addition of documentation about negative "n" being UB, or a
>>>> fix for those cases, I agree that his algorithm is fine.
>>>
>>> Actually, programming lots of Algol68 lately, I used a few patterns
>>> from that language also in my iterative code. (I had mentioned the
>>> unnecessary use of the "base" variable, and the 'int' parameter was
>>> also a remains.) In "C" (and forgetting Algol 68 for a moment) I'd
>>> probably have written it more "C-ish"; i.e. using an 'unsigned int'
>>> for the parameter 'n' to more clearly define its range as positive,
>>> operating directly on 'a', and condensing the 'while' loop by 'for'.
>>>
>>> long int ipow (long int a, unsigned int n)
>>> {
>>>       long int res = 1;
>>>       for ( ; n > 0; n /= 2) {
>>>           if (n & 1)
>>>               res *= a;
>>>           a *= a;
>>>       }
>>>       return res;
>>> }
>>>
>>> The "n < 0" case can then also be omitted completely and adds to its
>>> brevity.
>>
>> That was my thought, yes.
>>
>>>
>>> I'd suppose the 'unsigned' wouldn't prevent a "C" user to nonetheless
>>> feed the 'ipow' function with '-1', but that's C's inherent problem.
>>>
>>
>> Some people see that as an advantage - being able to write "unsigned
>> very_big = -1;".  I dislike it personally, but styles and preferences
>> vary, and it has portability advantages over, say, 0xffff'ffff.
>>
> 
> I also dislike that use of -1.  I prefer using ~0ul to get all-ones.

That makes more sense to me, but I can also see how some people find it 
a bit ugly or unclear.  I almost invariably know exactly what size my 
types are (fixed-size types are the norm in my type of coding), so 
explicit values are my preference in most cases.

[toc] | [prev] | [next] | [standalone]

#401282

scott@slp53.sl.home (Scott Lurndal) writes:
> David Brown <david.brown@hesbynett.no> writes:
[...]
>>Some people see that as an advantage - being able to write "unsigned 
>>very_big = -1;".  I dislike it personally, but styles and preferences 
>>vary, and it has portability advantages over, say, 0xffff'ffff.
>
> I also dislike that use of -1.  I prefer using ~0ul to get all-ones.

I'd use ~0ul to get all-ones, -1 or -1u to get the largest value
of the type (or preferably UINT_MAX, but -1 is good if it's not
obvious *which* unsigned type I'm using).

The fact that they happen to be the same value is a technical detail
that I don't necessarily want to worry about.  Whether I use ~0ul
or -1 depends on which concept I want to express.

-- 
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]

#401260

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#401261

On 2026-08-17 19:22, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-08-16 16:33, Tim Rentsch wrote:
> 
>>> [...]
>>
>> Ah, a typical non-answer! - [...]
> 
> What is typical is your usual fractious misdirection style.  You
> might consider trying to lower your talking-to-thinking ratio.

I suppose you're too old to expose a sane level of self-reflection.
And hypocritical as well. Just in your recent post you complained
about "an overly long thread" and regularly contribute non-answers.
You might consider thinking and reflecting about your own posts
and socio-pathological behavior before suggesting others what they
should do. Good luck!

Janis

[toc] | [prev] | [next] | [standalone]

#401262

On 2026-08-17 19:22, Tim Rentsch wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-08-16 16:33, Tim Rentsch wrote:
>>>
>>> One: one of the recursive calls is not properly tail recursive so
>>> the recursion isn't always optimized out.
>>
>> You could as well write that also from the beginning in an iterative
>> form (and not rely on optimizations of recursive functions - in case
>> that this is a problem for the compilers in mind).
> 
> I find it easier simply to write a properly tail-recursive
> implementation from the outset,

Fair enough.

> where I know compilers will have
> no difficulty optimizing out the tail calls.

Not all might know whether and what sorts of constructs their
compilers are able to optimize. To me it's not obvious that
simple (but non-tail-) recursions are typically not optimized.
YMMV, but sensible optimizations is IMO task of the compilers;
it shouldn't be necessary that you have to formulate programs
using a specific programming pattern; ideally - but "C" as had
been discussed not long ago exposes anyway a peculiar view of
optimizations. (I'm sure YMMV.)

Janis

[toc] | [prev] | [next] | [standalone]

Page 6 of 10 — ← Prev page 1 … 4 5 [6] 7 8 … 10  Next page →

Back to top | Article view | comp.lang.c

csiph-web