Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #396916 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2026-03-12 07:24 +0100 |
| Last post | 2026-03-27 17:03 +0000 |
| Articles | 20 on this page of 231 — 18 participants |
Back to article view | Back to comp.lang.c
Isn't that beauty ? Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 07:24 +0100
Re: Isn't that beauty ? Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 07:26 +0100
Re: Isn't that beauty ? Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-12 09:32 +0100
Re: Isn't that beauty ? Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 11:36 +0100
Re: Isn't that beauty ? Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-12 20:15 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-12 10:00 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 15:03 +0100
Re: Isn't that beauty ? (no it's not) tTh <tth@none.invalid> - 2026-03-12 15:27 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 15:34 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 15:13 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-12 10:43 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:10 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-12 11:22 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:25 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:25 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:48 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-12 20:25 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 00:57 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou@hotmail.com> - 2026-03-13 02:19 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 06:14 +0100
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 01:48 -0700
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 09:49 +0100
[OT] AI - questions and answers (was Re: Isn't that beauty ? (no it's not)) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-13 10:27 +0100
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 11:59 -0700
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-12 21:22 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 06:15 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 06:48 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-14 03:29 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-12 16:44 +0100
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-12 17:32 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 00:56 +0100
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 11:54 -0700
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 01:14 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-12 16:18 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 01:06 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 01:27 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 16:11 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 06:01 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-14 01:49 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 07:23 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-14 02:58 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 07:52 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 07:53 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-14 03:05 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 08:10 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-14 03:17 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 08:59 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 09:12 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-14 12:15 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 14:00 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 16:43 -0400
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-16 20:57 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 19:07 -0400
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-17 00:49 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-17 05:21 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-18 12:40 -0400
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-18 17:06 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-18 15:46 -0400
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-18 22:14 +0000
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-19 22:39 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-18 16:14 -0400
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-19 22:42 +0000
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-17 14:46 +0000
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-16 22:26 +0000
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-16 22:35 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 19:09 -0400
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-16 23:17 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 19:21 -0400
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-16 23:34 +0000
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-17 00:09 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 21:45 -0400
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-17 10:42 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-17 13:04 +0100
Re: Isn't that beauty ? (no it's not) Richard Harnden <richard.nospam@gmail.invalid> - 2026-03-17 12:17 +0000
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-17 12:31 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 21:27 -0400
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-16 22:26 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-16 19:41 -0400
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-17 00:29 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-17 05:38 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-17 11:47 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-17 13:08 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-17 12:37 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-18 02:40 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-18 11:21 +0200
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-18 10:49 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-18 15:10 +0000
Re: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-03-18 21:20 +0000
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-18 23:13 +0000
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 13:23 -0700
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-18 11:20 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-18 21:57 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-18 22:01 +0100
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-19 10:43 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 12:23 +0200
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-19 15:22 +0100
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-19 15:07 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 04:16 +0100
Re: Isn't that beauty ? (no it's not) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-20 02:14 -0700
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 12:38 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-20 13:06 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 13:27 +0100
Re: Isn't that beauty ? (no it's not) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-20 13:22 -0700
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-21 02:25 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-19 16:13 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 17:41 +0200
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 04:01 +0100
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-20 08:35 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 12:47 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 14:42 +0200
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-22 04:39 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-22 08:33 +0200
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-20 17:10 -0400
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-21 02:53 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-20 22:35 -0400
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-21 14:42 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-22 04:57 +0100
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 12:32 -0700
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-22 04:50 +0100
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-21 15:39 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-22 15:48 -0400
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-22 23:04 +0100
Re: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-03-19 13:28 +0000
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 03:45 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 11:19 +0200
Re: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-19 10:49 +0100
Re: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-03-19 14:09 +0000
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-19 14:49 +0000
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 17:09 +0200
sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 17:29 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-19 18:33 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-19 21:40 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-19 23:53 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-20 00:15 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 05:05 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 12:58 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 12:53 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 13:13 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-20 13:26 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 15:08 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-20 13:43 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 15:51 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) David Brown <david.brown@hesbynett.no> - 2026-03-20 14:47 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-22 02:03 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-22 04:03 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 15:13 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-04-07 02:22 +0300
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 21:00 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-04-07 09:37 +0300
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 21:54 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-09 16:06 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-11 09:04 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-11 19:55 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-04-07 14:46 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 20:04 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-09 21:15 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-04-10 01:31 +0300
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-12 06:17 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-11 21:32 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-12 04:59 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-26 07:29 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-04-09 23:33 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-10 11:35 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-12 07:13 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-13 20:44 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-25 15:47 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-27 02:04 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-26 22:27 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-04-27 14:41 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 14:01 +0200
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 13:48 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-04-07 01:58 +0300
Re: sorting Was: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-04-07 01:02 +0100
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 08:01 -0700
Re: sorting Was: Isn't that beauty ? (no it's not) antispam@fricas.org (Waldek Hebisch) - 2026-03-19 23:21 +0000
Re: sorting Was: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-06 18:37 -0700
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-20 04:33 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-20 14:24 +0200
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-22 05:06 +0100
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-03-22 09:30 +0200
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-07 02:12 -0700
Re: Isn't that beauty ? (no it's not) Michael S <already5chosen@yahoo.com> - 2026-04-07 14:00 +0300
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-16 10:23 -0700
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-04-07 16:39 -0400
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-04-12 11:16 -0700
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-25 00:45 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-17 06:25 +0100
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-20 01:33 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-20 07:42 +0100
Re: Isn't that beauty ? (no it's not) Tristan Wibberley <tristan.wibberley+netnews2@alumni.manchester.ac.uk> - 2026-03-20 12:16 +0000
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-14 16:22 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 18:04 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-14 17:39 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 19:25 +0100
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-13 00:54 +0000
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 00:31 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 06:24 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 01:40 -0400
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 01:34 -0400
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-13 14:38 +0000
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-13 15:31 +0000
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 13:15 -0700
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-16 15:18 +0000
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-23 21:23 -0700
Re: Isn't that beauty ? (no it's not) James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-03-13 18:47 -0400
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-15 14:38 -0700
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 07:24 +0100
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 01:51 -0700
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 09:54 +0100
Re: Isn't that beauty ? (no it's not) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-03-13 10:29 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 10:33 +0100
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 11:57 -0700
Re: Isn't that beauty ? (no it's not) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-03-13 11:58 -0700
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-13 14:29 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 08:08 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 04:19 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 09:53 +0100
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 09:56 +0100
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-13 05:10 -0400
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 10:14 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-13 17:32 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-13 18:44 +0100
Re: Isn't that beauty ? (no it's not) Bart <bc@freeuk.com> - 2026-03-13 19:36 +0000
Re: Isn't that beauty ? (no it's not) Bonita Montero <Bonita.Montero@gmail.com> - 2026-03-14 06:03 +0100
Re: Isn't that beauty ? (no it's not) scott@slp53.sl.home (Scott Lurndal) - 2026-03-12 16:56 +0000
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-20 23:07 -0700
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-22 16:55 -0400
Re: Isn't that beauty ? (no it's not) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-03-26 20:08 -0700
Re: Isn't that beauty ? (no it's not) DFS <nospam@dfs.com> - 2026-03-27 00:35 -0400
Re: Isn't that beauty ? (no it's not) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-03-26 21:53 -0700
Re: Isn't that beauty ? (no it's not) gazelle@shell.xmission.com (Kenny McCormack) - 2026-03-27 17:03 +0000
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-17 11:47 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pbf0q$2rtq3$1@dont-email.me> |
| In reply to | #397031 |
On 17/03/2026 04:38, Janis Papanagnou wrote: > On 2026-03-17 01:29, Bart wrote: >> >> (Also I quite like using bubble sort because so many deride it!) > > How miserable! (I feel so sorry for you.) Why would that be miserable? Bubble sort is perfectly fine for smallish values of N and where it is not frequently used. I also like it because I can easily write custom sort routines from memory. This function is used to sort the export tables for Windows's DLL files: https://github.com/sal55/langs/blob/master/bubble.m Such a table might have from tens of exported functions to perhaps hundreds. Bubble-sorting even 1000 strings takes about 10ms, which is small fraction of overall build-time of a library exporting 1000 functions. For a mere 100 functions, sort time is negligible.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-17 13:08 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pbg8f$2spms$2@dont-email.me> |
| In reply to | #397042 |
On 2026-03-17 12:47, Bart wrote: > On 17/03/2026 04:38, Janis Papanagnou wrote: >> On 2026-03-17 01:29, Bart wrote: >>> >>> (Also I quite like using bubble sort because so many deride it!) >> >> How miserable! (I feel so sorry for you.) > > Why would that be miserable? Because of the reason you pretend for using it. > [...] > > Bubble-sorting even 1000 strings takes about 10ms, which is small > fraction of overall build-time of a library exporting 1000 functions. > > For a mere 100 functions, sort time is negligible. And because of reason here based on arbitrary absolute times instead of actual algorithmic complexity. Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-17 12:37 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pbhud$2tbk0$2@dont-email.me> |
| In reply to | #397044 |
On 17/03/2026 12:08, Janis Papanagnou wrote: > On 2026-03-17 12:47, Bart wrote: >> On 17/03/2026 04:38, Janis Papanagnou wrote: >>> On 2026-03-17 01:29, Bart wrote: >>>> >>>> (Also I quite like using bubble sort because so many deride it!) >>> >>> How miserable! (I feel so sorry for you.) >> >> Why would that be miserable? > > Because of the reason you pretend for using it. > >> [...] >> >> Bubble-sorting even 1000 strings takes about 10ms, which is small >> fraction of overall build-time of a library exporting 1000 functions. >> >> For a mere 100 functions, sort time is negligible. > > And because of reason here based on arbitrary absolute times instead > of actual algorithmic complexity. No, timing is considered relative to the rest of the task. If this ever became a bottleneck then it is a trivial upgrade to a better routine. (The real problem however is why MS require programs that generate DLL files to do their own sorting, since it doesn't specify the sort criteria. If it doesn't exactly match MS's compare function for looking up symbol names, then it won't work.)
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-18 02:40 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pcvr2$3ednq$2@dont-email.me> |
| In reply to | #397047 |
On 2026-03-17 13:37, Bart wrote: > On 17/03/2026 12:08, Janis Papanagnou wrote: >> On 2026-03-17 12:47, Bart wrote: >>> On 17/03/2026 04:38, Janis Papanagnou wrote: >>>> On 2026-03-17 01:29, Bart wrote: >>>>> >>>>> (Also I quite like using bubble sort because so many deride it!) >>>> >>>> How miserable! (I feel so sorry for you.) >>> >>> Why would that be miserable? >> >> Because of the reason you pretend for using it. >> >>> [...] >>> >>> Bubble-sorting even 1000 strings takes about 10ms, which is small >>> fraction of overall build-time of a library exporting 1000 functions. >>> >>> For a mere 100 functions, sort time is negligible. >> >> And because of reason here based on arbitrary absolute times instead >> of actual algorithmic complexity. > > No, timing is considered relative to the rest of the task. > > If this ever became a bottleneck then it is a trivial upgrade to a > better routine. If there are simple better algorithms there's no reason but ignorance to not use them in the first place! - It's really stupid to deliberately use inferior, or (as here) even the worst existing algorithms. - What do professionals? - Let's have a look at a Quicksort implementation on a CDC mainframe back in the 1980's. They implemented it in a way that scales according to the CS state-of-the-art; divide-et-impera for the Quicksort, pick pivot element from a set of three, and sort divided runs of length smaller than 10 with a straight insertion sort algorithm. - No educated computer scientist would have decided to choose Bubblesort in any place here. Let alone for your "reason" that this algorithm is "derided". There's a reason why it's derided; that's called scientific analysis of its quality. Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-18 11:21 +0200 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <20260318112151.000021dc@yahoo.com> |
| In reply to | #397060 |
On Wed, 18 Mar 2026 02:40:50 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 2026-03-17 13:37, Bart wrote: > > On 17/03/2026 12:08, Janis Papanagnou wrote: > >> On 2026-03-17 12:47, Bart wrote: > >>> On 17/03/2026 04:38, Janis Papanagnou wrote: > >>>> On 2026-03-17 01:29, Bart wrote: > >>>>> > >>>>> (Also I quite like using bubble sort because so many deride > >>>>> it!) > >>>> > >>>> How miserable! (I feel so sorry for you.) > >>> > >>> Why would that be miserable? > >> > >> Because of the reason you pretend for using it. > >> > >>> [...] > >>> > >>> Bubble-sorting even 1000 strings takes about 10ms, which is small > >>> fraction of overall build-time of a library exporting 1000 > >>> functions. > >>> > >>> For a mere 100 functions, sort time is negligible. > >> > >> And because of reason here based on arbitrary absolute times > >> instead of actual algorithmic complexity. > > > > No, timing is considered relative to the rest of the task. > > > > If this ever became a bottleneck then it is a trivial upgrade to a > > better routine. > > If there are simple better algorithms there's no reason but > ignorance to not use them in the first place! - It's really > stupid to deliberately use inferior, or (as here) even the > worst existing algorithms. Bubble sort is not the worst existing, far from it. It is O(n**2). Some algos, which names I don't remember are O(n**3). The problem with bubble sort is that relatively to other popular O(n**2) sorting algorithms, i.e. using Knuth's nomenclature, Straight Insertion and Straight Selection, it is not just measurably slower, but also a little more complicated to code. However it has one pro point to it: it is very fast when applied to almost sorted data sets. > - What do professionals? - Let's > have a look at a Quicksort implementation on a CDC mainframe > back in the 1980's. They implemented it in a way that scales > according to the CS state-of-the-art; divide-et-impera for > the Quicksort, pick pivot element from a set of three, and > sort divided runs of length smaller than 10 with a straight > insertion sort algorithm. - All that is good, except of use of CDC mainframe in 1980s, which I'd consider more sub-optimal choice than bubble sort algorithm. > No educated computer scientist > would have decided to choose Bubblesort in any place here. > Let alone for your "reason" that this algorithm is "derided". > There's a reason why it's derided; that's called scientific > analysis of its quality. > > Janis > > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-18 10:49 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pdsfp$3n1pk$1@dont-email.me> |
| In reply to | #397062 |
On 2026-03-18 10:21, Michael S wrote: > > Bubble sort is not the worst existing, far from it. It is O(n**2). It is the worst. It's used in academia to show the most primitive algorithm and compare all others against it (as the lowest bound). > Some algos, which names I don't remember are O(n**3). If you don't put deliberately unnecessary code into the algorithm you will hardly find one - the question is; why would you do that! A commonly known algorithm with exponential complexity was/is the Shellsort (with n**1.2, IIRC). This is a bit of an outlier since most good algorithms are O(N log N), and the O(N²) used just for special cases. The only case where Bubblesort is acceptable is in the corner case that your data is anyway already or almost sorted. > [...] > > All that is good, except of use of CDC mainframe in 1980s, What was wrong with the CDC 175/176 supercomputers? (These were amongst the fastest back then! - Don't you remember one the first chess matches against grand masters during the 1980's?) > which I'd > consider more sub-optimal choice than bubble sort algorithm. There's hardly a reason to use suboptimal algorithms when there's plenty good ones available (even if you have to invest a few more bytes to program the standard algorithms). Janis
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-18 15:10 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pef9p$3u9sh$1@dont-email.me> |
| In reply to | #397063 |
On 18/03/2026 09:49, Janis Papanagnou wrote: > On 2026-03-18 10:21, Michael S wrote: >> >> Bubble sort is not the worst existing, far from it. It is O(n**2). > > It is the worst. It's used in academia to show the most primitive > algorithm and compare all others against it (as the lowest bound). My use of it is within a compiler that can approach a million lines per second throughput. Yet when I point out that most other compilers are far slower, even for the same standard of generated code, then that's perfectly fine! c:\mx>tim .\mm -time -dll big\fann4x Compiling big\fann4x.m to big\fann4x.dll ... ----------------------------- Total: 745 ms 100.0 % # internal compile time Time: 0.817 # overall Test input is 740Kloc, 10,000 functions, of which 1,000 are exported to the DLL. DLL binary is 5.6MB. Those 1000 function names are sorted via bubble-sort, which will be something over 10ms of total compile-time. This is the equivalent in C, using gcc: c:\cx\big>tim gcc -shared fann4x.c -s -o fann4x.dll Time: 44.067 1000 of the 10000 functions are not static, which here is sufficient to export them from the DLL. DLL binary is 9.6MB. (I couldn't test with TCC; it won't export unless '__declspec(dllexport)' is applied, but this generated errors. However the time for a version for 100% static functions was 0.86s, slower than mine, although the C code has a higher line count.) It might be hard to believe, but perhaps I know what I'm doing! I like to use the simplest possible algorithms unless there's a pressing reason to use something more elaborate.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-03-18 21:20 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pf4uj$375m9$1@paganini.bofh.team> |
| In reply to | #397065 |
Bart <bc@freeuk.com> wrote:
> On 18/03/2026 09:49, Janis Papanagnou wrote:
>> On 2026-03-18 10:21, Michael S wrote:
>>>
>>> Bubble sort is not the worst existing, far from it. It is O(n**2).
>>
>> It is the worst. It's used in academia to show the most primitive
>> algorithm and compare all others against it (as the lowest bound).
>
> My use of it is within a compiler that can approach a million lines per
> second throughput.
>
> Yet when I point out that most other compilers are far slower, even for
> the same standard of generated code, then that's perfectly fine!
>
> c:\mx>tim .\mm -time -dll big\fann4x
> Compiling big\fann4x.m to big\fann4x.dll
> ...
> -----------------------------
> Total: 745 ms 100.0 % # internal compile time
> Time: 0.817 # overall
>
> Test input is 740Kloc, 10,000 functions, of which 1,000 are exported to
> the DLL. DLL binary is 5.6MB.
>
> Those 1000 function names are sorted via bubble-sort, which will be
> something over 10ms of total compile-time.
>
>
> This is the equivalent in C, using gcc:
>
> c:\cx\big>tim gcc -shared fann4x.c -s -o fann4x.dll
> Time: 44.067
>
> 1000 of the 10000 functions are not static, which here is sufficient to
> export them from the DLL. DLL binary is 9.6MB.
Well, some day will come Bart^2 and feed your compiler with different
data. One on my codebases is about 210 k wc lines (about 120 k sloc).
There is about 15000 functions there, of which about 8000 is exported.
So, the thing is much smaller than your test file, but has much
more exported functions. If you scale it keeping the same
average function size and proportion of exported functions you
will quickly arrive at cases when this single sort dominates.
FYI, I have an old Modula-2 to C translater (written in late eighties
by a team in Karlsruche). It is reasonably fast handling 10000 lines,
it is hard to exactly measure execution time, but speed is
somewhere between 150 klps and 750 klps (not as fast as your
compiler, but quite respectable IMO). On smaller files (and possibly
this one) its execution time seem to be dominated by startup time.
But it slows down on bigger files. For curiosity I tracked the
problem and it is in handling of symbol table. While most
things use asymptoticaly fast algorithms parts that looks up
symbols is quadratic and this single thing dominates runtime.
> I like to use the simplest possible algorithms unless there's a pressing
> reason to use something more elaborate.
Heapsort is only marginaly more complex than bubble sort and has N*log(N)
worst case complexity. On average heapsort is not as fast as quicksort
(main factor seem to by much worse cache behaviour), but IMO is pretty
good choice is average speed is not critical but you want to avoid
catastrophic blow up of execution time on some data.
Merge sort sort is pretty simple too. There is a variation
of shell sort and buble sort called "comb sort". It performs
predetermined number of passes like bubble sort, but with
bigger and decreasing steps, once step is 1 it works as
usual bubble sort. Authors of "comb sort" claimed that
its performance is quite good, but of course, like quicksort
it may be quadratic on some data.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2026-03-18 23:13 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pfbj7$8mln$1@dont-email.me> |
| In reply to | #397074 |
On 18/03/2026 21:20, Waldek Hebisch wrote:
> Bart <bc@freeuk.com> wrote:
>> On 18/03/2026 09:49, Janis Papanagnou wrote:
>>> On 2026-03-18 10:21, Michael S wrote:
>>>>
>>>> Bubble sort is not the worst existing, far from it. It is O(n**2).
>>>
>>> It is the worst. It's used in academia to show the most primitive
>>> algorithm and compare all others against it (as the lowest bound).
>>
>> My use of it is within a compiler that can approach a million lines per
>> second throughput.
>>
>> Yet when I point out that most other compilers are far slower, even for
>> the same standard of generated code, then that's perfectly fine!
>>
>> c:\mx>tim .\mm -time -dll big\fann4x
>> Compiling big\fann4x.m to big\fann4x.dll
>> ...
>> -----------------------------
>> Total: 745 ms 100.0 % # internal compile time
>> Time: 0.817 # overall
>>
>> Test input is 740Kloc, 10,000 functions, of which 1,000 are exported to
>> the DLL. DLL binary is 5.6MB.
>>
>> Those 1000 function names are sorted via bubble-sort, which will be
>> something over 10ms of total compile-time.
>>
>>
>> This is the equivalent in C, using gcc:
>>
>> c:\cx\big>tim gcc -shared fann4x.c -s -o fann4x.dll
>> Time: 44.067
>>
>> 1000 of the 10000 functions are not static, which here is sufficient to
>> export them from the DLL. DLL binary is 9.6MB.
>
> Well, some day will come Bart^2 and feed your compiler with different
> data. One on my codebases is about 210 k wc lines (about 120 k sloc).
> There is about 15000 functions there, of which about 8000 is exported.
> So, the thing is much smaller than your test file, but has much
> more exported functions. If you scale it keeping the same
> average function size and proportion of exported functions you
> will quickly arrive at cases when this single sort dominates.
As I say, I'd just update that. But I did try this test program to see
what would happen:
#include <stdio.h>
void yjrsrh(void) {puts("yjrsrh");}
....
void ofcpxg(void) {puts("ofcpxg");}
This is 8001 lines and exports 8000 functions.
I used my C compiler (which uses the same backend as my other one), and
sure enough it was very slow: it took 2 seconds to produce the DLL,
nearly all spent sorting.
However, 50% of sort-time is spent repeatedly extracting the base-names
of my 'decorated' names, used for comparisons. This could just done once
at the start, but since this is C and names are not decorated, that
conversion is not needed anyway and can be disabled.
So it takes 1 second for this test, using bubble-sort.
I then tried it with gcc:
gcc -s c.c -shared -o c.dll
This took 4.5 seconds! It was still slower despite my slow sort.
Further, the DLL produced was 650KB compared with my 360KB.
I can reduce the size using -Os, but only down to 430KB, and it now took
9.6 seconds.
> FYI, I have an old Modula-2 to C translater (written in late eighties
> by a team in Karlsruche). It is reasonably fast handling 10000 lines,
> it is hard to exactly measure execution time, but speed is
> somewhere between 150 klps and 750 klps (not as fast as your
> compiler, but quite respectable IMO).
It's pretty good.
> On smaller files (and possibly
> this one) its execution time seem to be dominated by startup time.
> But it slows down on bigger files. For curiosity I tracked the
> problem and it is in handling of symbol table. While most
> things use asymptoticaly fast algorithms parts that looks up
> symbols is quadratic and this single thing dominates runtime.
The NASM assembler has something wrong like that. You only see it on
large files though.
If I create a c. 270Kloc ASM file (from sql.c) in different formats,
then these are the assembly times I get from various assemblers:
AA 0.12 seconds (my assembler; unoptimised)
AS 0.87 seconds
YASM 1.15 seconds (mostly NASM-compatible)
NASM 232 seconds (using -O0)
NASM 375 seconds (defaults)
There's about 3000 times difference between fastest and slowest. It's
obviously not right!
>
>> I like to use the simplest possible algorithms unless there's a pressing
>> reason to use something more elaborate.
>
> Heapsort is only marginaly more complex than bubble sort
The thing is I can write a bubble sort without needing to think about
it. I need to look up those other sorts, or modify one I have lying around.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-04-06 13:23 -0700 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <86cy0bzvmh.fsf@linuxsc.com> |
| In reply to | #397074 |
antispam@fricas.org (Waldek Hebisch) writes: [...] > Heapsort is only marginaly more complex than bubble sort [...] I think this claim is ridiculous. Code for heapsort is more than twice as long as code for bubble sort, and is both harder to write and harder to understand. Heapsort really needs two functions rather than one. All of the simple sorts (bubble sort, selection sort, insertion sort, merge sort) are IME easily coded without needing any significant thought. Not so for heapsort. Even quicksort, which isn't trivial, is easier than heapsort. > On average heapsort is not as fast as quicksort (main factor seem > to by much worse cache behaviour), More to say on that matter; saving for another reply and hoping to get to that soon.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-18 11:20 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pdu8k$3o60c$1@dont-email.me> |
| In reply to | #397062 |
On 18/03/2026 10:21, Michael S wrote: > On Wed, 18 Mar 2026 02:40:50 +0100 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> On 2026-03-17 13:37, Bart wrote: >>> On 17/03/2026 12:08, Janis Papanagnou wrote: >>>> On 2026-03-17 12:47, Bart wrote: >>>>> On 17/03/2026 04:38, Janis Papanagnou wrote: >>>>>> On 2026-03-17 01:29, Bart wrote: >>>>>>> >>>>>>> (Also I quite like using bubble sort because so many deride >>>>>>> it!) >>>>>> >>>>>> How miserable! (I feel so sorry for you.) >>>>> >>>>> Why would that be miserable? >>>> >>>> Because of the reason you pretend for using it. >>>> >>>>> [...] >>>>> >>>>> Bubble-sorting even 1000 strings takes about 10ms, which is small >>>>> fraction of overall build-time of a library exporting 1000 >>>>> functions. >>>>> >>>>> For a mere 100 functions, sort time is negligible. >>>> >>>> And because of reason here based on arbitrary absolute times >>>> instead of actual algorithmic complexity. >>> >>> No, timing is considered relative to the rest of the task. >>> >>> If this ever became a bottleneck then it is a trivial upgrade to a >>> better routine. >> >> If there are simple better algorithms there's no reason but >> ignorance to not use them in the first place! - It's really >> stupid to deliberately use inferior, or (as here) even the >> worst existing algorithms. > > Bubble sort is not the worst existing, far from it. It is O(n**2). > Some algos, which names I don't remember are O(n**3). Bogosort is O(n * n!) on average - keep rearranging the elements at random, then check if they are sorted. (The worst case is only bounded complexity if your random generator is pseduo-random rather than truly random.) O(n²) worst-case is not uncommon, even amongst sorting algorithms that are quite smart, like quicksort. > The problem with bubble sort is that relatively to other popular > O(n**2) sorting algorithms, i.e. using Knuth's nomenclature, Straight > Insertion and Straight Selection, it is not just measurably slower, > but also a little more complicated to code. I am not convinced on the complexity point - but it will vary by programming language, and what you consider "complicated". > However it has one pro point to it: it is very fast when applied to > almost sorted data sets. > It is also stable, has no memory overhead, exchanges pairs of data in-place, and only ever exchanges adjacent data. These can also be advantages in some situations. (Of course there are alternative sorting algorithms that have these same advantages and are, at least usually, more efficient.) I don't think pure bubblesort has much serious use outside educational purposes, but it is easy to understand, easy to implement correctly in pretty much any language, and can do a perfectly good job if you don't need efficient sorting of large datasets (for small enough datasets, a hand-written bubblesort in C will be faster than calling qsort). But I also think people sometimes jump to simplistic views of efficiency, as though a sorting algorithm can be boiled down to just a single "O(f(n))" complexity. With enough data, things like cache coherency matter more than operation counts - and with little data, efficiency often doesn't matter at all.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-18 21:57 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pf3k4$690h$1@dont-email.me> |
| In reply to | #397064 |
On 2026-03-18 11:20, David Brown wrote: > On 18/03/2026 10:21, Michael S wrote: >> >> Bubble sort is not the worst existing, far from it. It is O(n**2). >> Some algos, which names I don't remember are O(n**3). > > Bogosort is O(n * n!) on average - keep rearranging the elements at > random, then check if they are sorted. (The worst case is only bounded > complexity if your random generator is pseduo-random rather than truly > random.) Just to make clear; the key point is that it makes no sense to implement sorting algorithms of complexities worse that O(N²). With that complexity you can compare and move every element to be sorted with any other element.[*] So Michael's hypothetical O(N**3) algorithm would be just nonsense (or ignorance) for any sensible application in practice. [*] It would otherwise be like implementing some operations on linear lists with an algorithm worse than O(N). Depending on the actual function you usually strive for O(log N) or O(1) by organizing your data appropriately, but never worse than O(N). > > O(n²) worst-case is not uncommon, even amongst sorting algorithms that > are quite smart, like quicksort. Yes. It's indeed not widely known that one of the [practically] fastest algorithm is that "bad" (concerning actual complexity). The point is, for one, that it's on average much better; just in very special cases it's getting quadratic.[**] And the other point is that you can manage its complexity by means mentioned in my previous post (like using a medium-of-three pivot element, for example). (Quicksort has in that respect been thoroughly examined already in the 1980's and various optimizations have been developed.) [**] As opposed to Bubblesort that shows acceptable behavior just in the very rare special case of already sorted elements. But then one should consider to not *sort* the data in the first place but *insert* a new element at the right place to keep the sorting order. > >> The problem with bubble sort is that relatively to other popular >> O(n**2) sorting algorithms, i.e. using Knuth's nomenclature, Straight >> Insertion and Straight Selection, it is not just measurably slower, >> but also a little more complicated to code. > > I am not convinced on the complexity point - but it will vary by > programming language, and what you consider "complicated". If you're lucky you use a programming language where you don't have to implement basic things like the sorting algorithm.[***] My expectation is that standard library functions would support sophisticated efficient O(N log N) algorithms out of the box. [***] Here Bonita Montero with his enthusiasm for C++ has a point that cannot be derived. I would also not be surprised if qsort(3) from the standard "C" lib would be based on Quicksort or Quicksort hybrids (but I've never checked). In C++'s STL you get complexities of algorithms guaranteed at least; that's sensible CS/IT software design! Janis > [...]
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-18 22:01 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pf3qp$690h$2@dont-email.me> |
| In reply to | #397072 |
On 2026-03-18 21:57, Janis Papanagnou wrote: > > [***] Here Bonita Montero with his enthusiasm for C++ has a point > that cannot be derived. ...that cannot be derided. [And should rather be esteemed.] > Janis > >> [...] >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-19 10:43 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pggfc$i81k$1@dont-email.me> |
| In reply to | #397072 |
On 18/03/2026 21:57, Janis Papanagnou wrote: > On 2026-03-18 11:20, David Brown wrote: >> On 18/03/2026 10:21, Michael S wrote: >>> >>> Bubble sort is not the worst existing, far from it. It is O(n**2). >>> Some algos, which names I don't remember are O(n**3). >> >> Bogosort is O(n * n!) on average - keep rearranging the elements at >> random, then check if they are sorted. (The worst case is only >> bounded complexity if your random generator is pseduo-random rather >> than truly random.) > > Just to make clear; the key point is that it makes no sense to > implement sorting algorithms of complexities worse that O(N²). > With that complexity you can compare and move every element to > be sorted with any other element.[*] So Michael's hypothetical > O(N**3) algorithm would be just nonsense (or ignorance) for > any sensible application in practice. Yes, that's fair enough. You have to go out of your way to make a sorting algorithm that is worse than O(n²), so they will not be found in real code. But they certainly do exist. (It is not inconceivable that dedicated hardware solutions doing sorts with many comparisons in parallel do more than O(n²) comparisons, in much less than O(n²) time. But that's a different kind of system.) > > [*] It would otherwise be like implementing some operations on > linear lists with an algorithm worse than O(N). Depending on > the actual function you usually strive for O(log N) or O(1) by > organizing your data appropriately, but never worse than O(N). > >> >> O(n²) worst-case is not uncommon, even amongst sorting algorithms that >> are quite smart, like quicksort. > > Yes. It's indeed not widely known that one of the [practically] > fastest algorithm is that "bad" (concerning actual complexity). > The point is, for one, that it's on average much better; just > in very special cases it's getting quadratic.[**] And the other > point is that you can manage its complexity by means mentioned > in my previous post (like using a medium-of-three pivot element, > for example). (Quicksort has in that respect been thoroughly > examined already in the 1980's and various optimizations have > been developed.) Yes. "Pure" quicksort is O(n²) worst case, and it hits its worst case when the list is already sorted, so it did not take long for variations to be developed. > > [**] As opposed to Bubblesort that shows acceptable behavior > just in the very rare special case of already sorted elements. In many applications, already sorted or nearly sorted can be the usual case, not a rarity. If you want an efficient sorting algorithm for a particular task, you need to know the details of the task. > But then one should consider to not *sort* the data in the first > place but *insert* a new element at the right place to keep the > sorting order. That can sometimes be the best strategy. > >> >>> The problem with bubble sort is that relatively to other popular >>> O(n**2) sorting algorithms, i.e. using Knuth's nomenclature, Straight >>> Insertion and Straight Selection, it is not just measurably slower, >>> but also a little more complicated to code. >> >> I am not convinced on the complexity point - but it will vary by >> programming language, and what you consider "complicated". > > If you're lucky you use a programming language where you don't > have to implement basic things like the sorting algorithm.[***] > My expectation is that standard library functions would support > sophisticated efficient O(N log N) algorithms out of the box. > Usually, yes. But sometimes that is not the fastest tool for the job. I've had occasion to need to sort arrays of numbers (ints or floats) with a compile-time fixed small size - such as 4 or 6 entries. While I did not use bubblesort, a bubblesort would have beaten standard C library qsort by an order of magnitude. The fun of sorting is that there is no single perfect algorithm that is always the best choice. > [***] Here Bonita Montero with his enthusiasm for C++ has a point > that cannot be derived. I would also not be surprised if qsort(3) > from the standard "C" lib would be based on Quicksort or Quicksort > hybrids (but I've never checked). In C++'s STL you get complexities > of algorithms guaranteed at least; that's sensible CS/IT software > design! > C++'s sorts have the advantage of being template based, and thus can be more efficient than generic memcpy() and comparison functions for C's qsort. Usually, at least for larger datasets, sorts are hybrid algorithms, switching between things like quicksort, insertion sort and heap sort at different stages in order to maximise cache hits and to get the balance between the "O" complexity and the constants in the O function. (By that I mean that if you have two algorithms with timing of the form "a.n² + b.n + c", they are both O(n²) and for big n then the factor "a" is all-important. But for small n, b and c can be dominant.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2026-03-19 12:23 +0200 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <20260319122341.0000175d@yahoo.com> |
| In reply to | #397078 |
On Thu, 19 Mar 2026 10:43:08 +0100 David Brown <david.brown@hesbynett.no> wrote: > > C++'s sorts have the advantage of being template based, and thus can > be more efficient than generic memcpy() and comparison functions for > C's qsort. The problem with C qsort is not just lack of efficiency. It's also lacke of flexibilty at API level. In my pratice, in about 30% of the cases sorting, C qsort will either didn't do what I want at all or at very least would not do it in thread-safe manner. qsort_r() (POSIX ?) is a more flexible API that should have been part of C Standard at least since C11. But it still is not.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-03-19 15:22 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10ph0rn$p9cu$1@dont-email.me> |
| In reply to | #397080 |
On 19/03/2026 11:23, Michael S wrote: > On Thu, 19 Mar 2026 10:43:08 +0100 > David Brown <david.brown@hesbynett.no> wrote: > >> >> C++'s sorts have the advantage of being template based, and thus can >> be more efficient than generic memcpy() and comparison functions for >> C's qsort. > > The problem with C qsort is not just lack of efficiency. It's also > lacke of flexibilty at API level. In my pratice, in about 30% of the > cases sorting, C qsort will either didn't do what I want at all or at > very least would not do it in thread-safe manner. qsort_r() (POSIX ?) > is a more flexible API that should have been part of C Standard at least > since C11. But it still is not. > Yes, standard C qsort() has a lot of limitations. A thread-safe version would fix one of these, but miss out on many others.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-03-19 15:07 +0000 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <IiUuR.931277$wcP9.580527@fx24.iad> |
| In reply to | #397083 |
David Brown <david.brown@hesbynett.no> writes: >On 19/03/2026 11:23, Michael S wrote: >> On Thu, 19 Mar 2026 10:43:08 +0100 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> >>> C++'s sorts have the advantage of being template based, and thus can >>> be more efficient than generic memcpy() and comparison functions for >>> C's qsort. >> >> The problem with C qsort is not just lack of efficiency. It's also >> lacke of flexibilty at API level. In my pratice, in about 30% of the >> cases sorting, C qsort will either didn't do what I want at all or at >> very least would not do it in thread-safe manner. qsort_r() (POSIX ?) >> is a more flexible API that should have been part of C Standard at least >> since C11. But it still is not. >> > >Yes, standard C qsort() has a lot of limitations. A thread-safe version >would fix one of these, but miss out on many others. On the other hand, qsort() works just fine for relatively small data sets which I suspect is the common use for qsort (aside from introductory programming exercises).
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-20 04:16 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pie5i$17mc2$3@dont-email.me> |
| In reply to | #397085 |
On 2026-03-19 16:07, Scott Lurndal wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 19/03/2026 11:23, Michael S wrote: >>> On Thu, 19 Mar 2026 10:43:08 +0100 >>> David Brown <david.brown@hesbynett.no> wrote: >>> >>>> C++'s sorts have the advantage of being template based, and thus can >>>> be more efficient than generic memcpy() and comparison functions for >>>> C's qsort. >>> >>> The problem with C qsort is not just lack of efficiency. It's also >>> lacke of flexibilty at API level. [...] I think this is in practice indeed a crucial point. - How flexible it's usable without compromising the basic quality of any underlying algorithm. > > On the other hand, qsort() works just fine for relatively small > data sets which I suspect is the common use for qsort (aside from > introductory programming exercises). Au contraire; given it's outstanding quality concerning the complexity measure it's especially usable for large datasets, and for small sets the hybrid mechanisms should pop in. (You shouldn't notice a difference. - I repeat my disclaimer of not knowing how C's qsort() function is actually implemented, whether it's a Quicksort at all, whether it's hybrid, etc.) Quicksort (as opposed to qsort() - where the details are not obvious) is certainly a case for computer science lectures; I'd only have hoped that these CS basics are broadly known, also with non-CS educated or the many amateur programmers. Janis
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-03-20 02:14 -0700 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <87ldfmual7.fsf@example.invalid> |
| In reply to | #397100 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]
> Quicksort (as opposed to qsort() - where the details are not
> obvious) is certainly a case for computer science lectures;
> I'd only have hoped that these CS basics are broadly known,
> also with non-CS educated or the many amateur programmers.
[...]
C doesn't specify which algorithm qsort() uses. The name is almost
certainly derived from the name of the Quicksort algorithm, but the
C standard only says that the contents of the array are sorted.
A conforming but perverse implemention could use Bubblesort or
Bogosort.
Even the GNU libc documentation doesn't say what algorithm that
implementation uses. (In the source code, I see references to
mergesort and heapsort.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2026-03-20 12:38 +0100 |
| Subject | Re: Isn't that beauty ? (no it's not) |
| Message-ID | <10pjbiv$1h0eh$3@dont-email.me> |
| In reply to | #397105 |
On 2026-03-20 10:14, Keith Thompson wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: > [...] >> Quicksort (as opposed to qsort() - where the details are not >> obvious) is certainly a case for computer science lectures; >> I'd only have hoped that these CS basics are broadly known, >> also with non-CS educated or the many amateur programmers. > [...] > > C doesn't specify which algorithm qsort() uses. The name is almost > certainly derived from the name of the Quicksort algorithm, but the > C standard only says that the contents of the array are sorted. > A conforming but perverse implemention could use Bubblesort or > Bogosort. Yes, there's no [obvious] information; that's the dilemma![*] > > Even the GNU libc documentation doesn't say what algorithm that > implementation uses. (In the source code, I see references to > mergesort and heapsort.) Though the use of Mergesort is somewhat irritating (to me). But both are O(N log N), which is good to know. (And, frankly, I wouldn't have expected any worse O(N^2) algorithm here.) Janis [*] C++/STL has at least guarantees for the complexities. For me that would basically suffice. I don't necessarily need to know whether it's the concrete algorithm A or B.
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web