Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #385836 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2024-06-11 10:13 +0100 |
| Last post | 2024-06-11 18:21 +0000 |
| Articles | 20 on this page of 351 — 23 participants |
Back to article view | Back to comp.lang.c
Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 10:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 13:59 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 14:35 +0100
Mac users (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 10:04 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-11 15:16 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 15:35 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-12 00:34 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 00:50 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 18:02 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-11 17:15 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 07:40 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 09:01 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 10:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:20 +0200
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 13:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 12:27 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 14:35 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:13 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 15:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-12 14:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-12 15:46 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 00:29 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-12 23:22 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-13 13:53 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 14:46 +0100
Re: Baby X is bor nagain tTh <tth@none.invalid> - 2024-06-13 17:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-13 16:32 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-14 08:47 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 19:13 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-13 17:43 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-14 18:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-14 19:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-15 12:35 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 02:22 -0400
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-17 07:30 +0000
Are Javascript and Python similarly slow ? (Was: Baby X is bor nagain) Michael S <already5chosen@yahoo.com> - 2024-06-17 12:11 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-17 12:25 +0300
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 10:54 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:23 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 11:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:36 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:11 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 17:38 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:54 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 14:14 -0400
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 20:52 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-18 16:07 -0400
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 15:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 18:15 +0200
Re: Baby X is bor nagain Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-06-18 21:09 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-18 18:40 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-18 17:39 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-18 15:49 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 10:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:42 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 17:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:49 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 21:42 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 22:51 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 12:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 14:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 17:07 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-20 20:28 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 20:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 22:16 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-20 23:40 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 10:02 +0200
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 09:55 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 09:37 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-20 13:18 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 12:24 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 13:36 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:26 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 08:05 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-20 17:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 17:45 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 13:55 -0400
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-20 19:01 +0000
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:41 -0700
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:34 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:44 -0700
Re: Baby X is bor nagain vallor <vallor@cultnix.org> - 2024-06-20 22:21 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-20 22:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:19 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 13:37 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-20 22:39 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-21 00:56 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-21 22:07 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 14:57 -0700
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-20 20:59 -0400
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-20 18:42 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-21 21:10 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 12:19 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-23 10:30 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 11:04 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:33 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 03:28 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:35 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-25 05:38 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-23 16:33 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 07:40 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-24 14:25 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-23 09:47 -0700
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-23 19:55 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 09:34 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-23 23:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-24 01:53 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-25 01:30 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 12:59 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 23:46 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-26 17:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 13:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:44 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-19 02:27 -0700
sort - C, python, C++, glibc Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-19 13:17 +0300
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 12:53 +0200
Re: sort - C, python, C++, glibc Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-19 18:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 07:39 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:26 -0400
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:13 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 11:30 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 15:43 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 16:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:21 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 20:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 21:29 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 22:06 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 08:44 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:21 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 11:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 11:42 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:34 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:47 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:25 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 19:21 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-23 22:09 +0100
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-24 00:52 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 01:25 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 00:56 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:28 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 12:17 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 13:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 14:01 +0100
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 10:16 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 16:09 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 15:00 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 17:09 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:19 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-24 19:15 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:25 +0000
Re: Baby X is bor nagain "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-25 20:29 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 22:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 21:34 +0000
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 22:03 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 10:19 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 12:18 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:08 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:28 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:17 +0200
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 12:52 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 20:39 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-06-25 16:28 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-26 00:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:23 +0200
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-26 15:18 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:45 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-25 12:04 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:21 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-26 08:31 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 13:15 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 12:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 18:10 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 17:51 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 17:02 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 18:50 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-24 18:10 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-24 20:33 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-25 11:36 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 15:56 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 15:08 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 17:12 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-25 16:59 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 16:27 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-25 19:51 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-25 18:11 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-26 00:42 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 09:35 +0200
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-26 13:15 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 12:16 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-27 15:24 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 14:13 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 14:31 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 17:28 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-27 21:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-27 22:47 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:23 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:19 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 10:26 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 15:14 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-29 08:38 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 17:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:42 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:49 +0300
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 15:43 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:43 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:23 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-30 00:36 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-03 17:12 -0400
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-30 01:49 -0700
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:46 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 20:55 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 12:18 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:54 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-30 19:10 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-01 00:20 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-08 19:48 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-29 16:23 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 10:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-29 12:11 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-30 11:48 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 17:47 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 12:22 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-01 13:09 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-01 15:14 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:20 -0700
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:00 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 16:44 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 00:58 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 01:23 +0100
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 00:47 +0000
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-07-03 01:18 +0000
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 01:54 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-03 09:08 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 10:36 +0100
Re: Baby X is bor nagain DFS <nospam@dfs.com> - 2024-07-03 09:41 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-03 17:58 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:33 +0300
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-04 09:14 +0100
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-03 22:58 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:24 +0200
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-02 13:16 -0500
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2025-01-02 20:46 +0000
Re: Baby X is bor nagain Phillip <nntp@fulltermprivacy.com> - 2025-01-02 16:47 -0500
Re: Baby X is bor nagain antispam@fricas.org (Waldek Hebisch) - 2025-01-02 22:22 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 13:48 +0100
Re: Baby X is bor nagain DFS <guhnoo-basher@linux.advocaca> - 2025-01-03 12:04 -0500
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2025-01-03 18:12 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-07-04 10:18 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-03 11:23 +0100
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-03 13:13 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:56 +0200
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:20 +0300
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:52 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 11:05 +0200
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-29 09:15 +0000
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-29 19:11 +0200
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-29 18:51 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-29 21:56 +0300
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-30 11:17 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-28 06:57 +0200
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 13:23 -0700
Re: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-27 15:44 -0700
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 17:50 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 00:16 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-27 23:58 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:21 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:15 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:53 +0000
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-27 18:08 -0700
Re: Baby X is bor nagain Kaz Kylheku <643-408-1753@kylheku.com> - 2024-06-28 03:30 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 11:11 +0300
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 11:41 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 13:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:36 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 15:48 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 20:37 +0100
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-28 15:42 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-28 16:01 +0000
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:45 +0300
tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-01 20:09 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-01 12:14 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 14:48 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-01 15:09 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 11:54 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 12:22 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 16:27 +0300
Re: tcc - first impression. Was: Baby X is bor nagain bart <bc@freeuk.com> - 2024-07-02 15:18 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 17:55 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 13:57 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:50 -0700
Re: tcc - first impression. Was: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-02 06:47 -0700
Re: tcc - first impression. Was: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-02 11:50 -0400
Re: tcc - first impression. Was: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-07-02 10:35 +0100
Re: tcc - first impression. Was: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-07-02 14:33 +0000
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 15:43 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:17 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 16:32 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-02 18:45 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-07-02 17:12 +0100
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 00:42 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-04 00:04 +0300
Re: tcc - first impression. Was: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-07-03 21:07 +0300
Re: Baby X is bor nagain Ben Bacarisse <ben@bsb.me.uk> - 2024-06-27 23:24 +0100
Re: Baby X is bor nagain Richard Harnden <richard.nospam@gmail.invalid> - 2024-06-28 00:44 +0100
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-24 20:41 +0300
Re: Baby X is bor nagain Michael S <already5chosen@yahoo.com> - 2024-06-28 19:39 +0300
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-26 11:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-26 16:43 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 22:01 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 09:01 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-17 19:52 -0400
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 11:26 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-17 20:24 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-18 14:40 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:55 +0100
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 09:39 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 14:58 +0100
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-18 14:33 +0000
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 13:02 -0400
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:06 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 11:07 -0700
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-18 19:22 +0100
Re: Baby X is bor nagain Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-06-18 16:34 -0700
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 10:05 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-19 11:52 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-19 19:53 +0200
Re: Baby X is bor nagain Vir Campestris <vir.campestris@invalid.invalid> - 2024-06-20 21:31 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 12:46 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 14:25 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-21 15:51 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 19:43 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 14:56 +0200
Re: Baby X is bor nagain scott@slp53.sl.home (Scott Lurndal) - 2024-06-23 15:22 +0000
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-21 22:05 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-23 15:11 +0200
Re: Baby X is bor nagain Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-06-17 14:09 +0100
Re: Baby X is bor nagain David Brown <david.brown@hesbynett.no> - 2024-06-17 18:38 +0200
Re: Baby X is bor nagain James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-18 03:28 -0400
Topicality is not your strong suit (Was: Baby X is bor nagain) gazelle@shell.xmission.com (Kenny McCormack) - 2024-06-12 09:40 +0000
Re: Topicality is not your strong suit (Was: Baby X is bor nagain) Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-12 12:59 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 18:09 +0100
Re: Baby X is bor nagain Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-11 20:22 +0200
Re: Baby X is bor nagain bart <bc@freeuk.com> - 2024-06-11 20:31 +0100
Re: Baby X is bor nagain kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-06-11 18:21 +0000
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-25 05:38 -0700 |
| Message-ID | <86o77pdwpb.fsf@linuxsc.com> |
| In reply to | #386491 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> >>>> [on the requirements for qsort] >>>> >>>>> I certainly would favor improved wording that made this clearer. >>>>> In fact, simply explicitly mandating total ordering rather than >>>>> making a vague comment about consistency would probably be the >>>>> best approach. >>>> >>>> Clearly the C standard intends to impose a weaker requirement >>>> than that the comparison function be a total ordering. >>> >>> The plot thickens. Unless, of course, you are referring to the >>> distinction you drew before between an ordering of all possible objects >>> and only those in the array. >> >> Consider the following situation. >> >> We have an array with seven elements, the integers 1 to 7, >> in that order. We call qsort on the array, with a natural >> comparison function that compares the integer values. >> >> The qsort function starts with a check, and for any array >> with eight elements or fewer a simple insertion sort is >> done. Because 1 is less than 2, these elements stay >> where they are. Because 2 is less than 3, there is only >> the one comparison, and 3 stays where it is. And so on... >> at each point in the sort an element is compared to the >> one before it, and nothing changes. Six compares are >> done to sort seven elements. Question: has the program >> encountered any undefined behavior? (I expect you will >> say no.) >> >> Now consider a second situation. >> >> We again have an array with seven elements, the integers 1 >> to 7, but not necessarily in order. We call the same >> qsort function. This time though the argument for the >> comparison function is for a function that just always >> returns -1. The same sequence of events takes place as >> did in the first situation: each element after the first >> is compared to the one before it, and because the previous >> element is deemed "less than" this element no movement >> occurs and we proceed to the next element of the array. >> Six compares are done to "sort" seven elements. Question: >> has the program encountered any undefined behavior? >> >> If there has been undefined behavior, which passages in >> the C standard explains the difference relative to the >> first situation? >> >> If there has not been undefined behavior, what does that >> say about what the requirements are for a call to qsort? > > So you are pointing out that only the comparisons made have to be > "consistent with one another"? BTW, your function that returns -1 is > just the total extension of my partial "dog order" function. Let me try to be clear here. As I read the C standard: whatever we decide "consistent with" means, it is only the results of the calls to the comparison function that were actually performed that matter. If other calls to the comparison function would have given a result not consistent with the results of calls that /were/ performed, but those other calls were not performed, that potential inconsistency doesn't make the behavior be undefined. It makes sense to me that this rule is what was intended. Whatever results qsort gets back, as long as they are consistent with one another the sorting algorithm is going to work okay, in the sense that it won't rely on contradictory information. Conversely, if qsort does get back contradictory information, then it easily might wander off into the weeds and do who knows what. So the condition for undefined behavior matches those cases where qsort could be confused by having received bogus results.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-23 16:33 -0700 |
| Message-ID | <87msnbtes9.fsf@nosuchdomain.example.com> |
| In reply to | #386397 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [on the requirements for qsort]
>
>> I certainly would favor improved wording that made this clearer.
>> In fact, simply explicitly mandating total ordering rather than
>> making a vague comment about consistency would probably be the
>> best approach.
>
> Clearly the C standard intends to impose a weaker requirement
> than that the comparison function be a total ordering.
"That is, for qsort they shall define a total ordering on the
array".
I presume you didn't intend to contradict that requirement, but
I can't figure out what you meant -- unless, as Ben suggested,
you're distinguishing between a total ordering of all possible
arguments and a total ordering of objects present in the array.
But even then, the standard explicitly imposes a total ordering.
(The requirements for bsearch might be weaker, but we're discussing
qsort.)
Can you clarify what you meant?
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-24 07:40 -0700 |
| Message-ID | <861q4mflox.fsf@linuxsc.com> |
| In reply to | #386415 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> [on the requirements for qsort] >> >>> I certainly would favor improved wording that made this clearer. >>> In fact, simply explicitly mandating total ordering rather than >>> making a vague comment about consistency would probably be the >>> best approach. >> >> Clearly the C standard intends to impose a weaker requirement >> than that the comparison function be a total ordering. > > "That is, for qsort they shall define a total ordering on the > array". > > I presume you didn't intend to contradict that requirement, but > I can't figure out what you meant -- unless, as Ben suggested, > you're distinguishing between a total ordering of all possible > arguments and a total ordering of objects present in the array. > But even then, the standard explicitly imposes a total ordering. > (The requirements for bsearch might be weaker, but we're discussing > qsort.) > > Can you clarify what you meant? For starters, saying that the comparison function defines a total ordering of elements actually present in the array is already a weaker requirement than saying that the comparison function defines a total ordering of all values that might legally be present in the array. Now notice that the C standard isn't referring to the comparison function in the statement quoted above. The standard does not say "the comparison function shall define". What it does say is that "/they/ shall define". Those two aren't the same thing.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-24 14:25 -0700 |
| Message-ID | <87v81yrq2c.fsf@nosuchdomain.example.com> |
| In reply to | #386460 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> [on the requirements for qsort]
>>>> I certainly would favor improved wording that made this clearer.
>>>> In fact, simply explicitly mandating total ordering rather than
>>>> making a vague comment about consistency would probably be the
>>>> best approach.
>>>
>>> Clearly the C standard intends to impose a weaker requirement
>>> than that the comparison function be a total ordering.
>>
>> "That is, for qsort they shall define a total ordering on the
>> array".
>>
>> I presume you didn't intend to contradict that requirement, but
>> I can't figure out what you meant -- unless, as Ben suggested,
>> you're distinguishing between a total ordering of all possible
>> arguments and a total ordering of objects present in the array.
>> But even then, the standard explicitly imposes a total ordering.
>> (The requirements for bsearch might be weaker, but we're discussing
>> qsort.)
>>
>> Can you clarify what you meant?
>
> For starters, saying that the comparison function defines a total
> ordering of elements actually present in the array is already a
> weaker requirement than saying that the comparison function defines
> a total ordering of all values that might legally be present in the
> array.
>
> Now notice that the C standard isn't referring to the comparison
> function in the statement quoted above. The standard does not say
> "the comparison function shall define". What it does say is that
> "/they/ shall define". Those two aren't the same thing.
OK, I see your point. It's not the comparison function itself that's
required to define a total ordering. It's the results of the actual
calls to the comparison function that must do so.
In another article, you've constructed an extremely contrived scenario
with a comparison function that, as written, is clearly incorrect (it
always returns -1), but the hypothetical qsort implementation only calls
the comparison function in a way that's consistent with a total ordering
of the array elements.
Practically speaking, it's obvious, I think, that a comparison function
*should* define a total ordering, but there are odd cases where buggy
comparison functions might not result in undefined behavior in a
particular implementation. The only sane way to define a comparison
function that meets the requirements for qsort is to have it actually
define a total ordering for the elements that can appear in the array.
(In some cases it might be appropriate to take some shortcuts based on
knowledge that some things won't actually appear in the array.)
You're right.
Did it ever occur to you to explain this in the first place? One
sentence in your original post would have been sufficient.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-23 09:47 -0700 |
| Message-ID | <868qyvhai4.fsf@linuxsc.com> |
| In reply to | #386379 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: >> >>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>> >>>> Ben Bacarisse <ben@bsb.me.uk> writes: >>>> [...] >>>> >>>>> On a C language point, I don't think the standard says anything >>>>> about sorting with non-order functions like the one above. Is >>>>> an implementation of qsort permitted to misbehave (for example >>>>> by not terminating) when the comparison function does not >>>>> implement a proper order relation? >>>> >>>> N1570 7.22.5p4 (applies to bsearch and qsort): >>>> """ >>>> When the same objects (consisting of size bytes, irrespective of >>>> their current positions in the array) are passed more than once >>>> to the comparison function, the results shall be consistent with >>>> one another. That is, for qsort they shall define a total >>>> ordering on the array, and for bsearch the same object shall >>>> always compare the same way with the key. >>>> """ >>>> >>>> That's a "shall" outside a constraint, so violating it results in >>>> undefined behavior. >>> >>> I think it should be clearer. What the "that is" phrase seems to >>> clarify in no way implies a total order, merely that the repeated >>> comparisons or the same elements are consistent with one another. >>> That the comparison function defines a total order on the elements >>> is, to me, a major extra constraint that should not be written as >>> an apparent clarification to something the does not imply it: >>> repeated calls should be consistent with one another and, in >>> addition, a total order should be imposed on the elements present. >> >> I think you're misreading the first sentence. > > Let's hope so. That's why I said it should be clearer, not that it > was wrong. > >> Suppose we are in >> court listening to an ongoing murder trial. Witness one comes in >> and testifies that Alice left the house before Bob. Witness two >> comes in (after witness one has gone) and testifies that Bob left >> the house before Cathy. Witness three comes in (after the first >> two have gone) and testifies that Cathy left the house before >> Alice. None of the witnesses have contradicted either of the >> other witnesses, but the testimonies of the three witnesses are >> not consistent with one another. > > My (apparently incorrect) reading of the first sentence is that > the consistency is only required between the results of multiple > calls between each pair. In other words, if the witnesses are > repeatedly asked, again and again, if Alice left before Bob and/or > if Bob left before Alice the results would always be consistent > (with, of course, the same required of repeatedly asking about the > other pairs of people). Let me paraphrase that. When the same pair of objects is passed more than once to individual calls of the comparison function, the results of those different calls shall each be consistent with every other one of the results. To paraphrase my reading, when some set of "same" objects is each passed more than once to individual calls of the comparison function, the results of all of those calls taken together shall not imply an ordering contradiction. Are the last two paragraphs fair restatements of our respective readings? Is the second paragraph plain enough so that you would not misconstrue it if read in isolation? Or if not, can you suggest a better phrasing? >> Try a web search >> >> "consistent with" definition >> >> for more explanation. > > Seriously? Yes, it's a serious suggestion, and I'm sorry if it came across as condescending. I did this search myself, and learned something from it. The important point is the "consistent with" is something of an idiomatic phrase, and it doesn't mean "equivalent to" or "the same as". Maybe you already knew that, but I didn't, and learning it helped me see what the quoted passage is getting at. >> Also, for "one another", if we say the >> children in the Jones family get along with one another, we don't >> mean that each child gets along with at least one of the others, >> but instead mean that every child gets along with every other >> child, that is, that they all get along with each other. > > The sentence in question has, to my mind, already stated what the > "one another" refers to -- the multiple calls between pairs > containing the same objects. I get you think that's not the > intended meaning, but I get my reading so strongly that I struggle > to see the other. Yes, I got that. The incongruity between the first sentence and the second sentence prompted me to re-examine the entire paragraph, which is what eventually led me to my current reading. >> Whether >> or not some other reading (of that problem sentence in the C >> standard) is sensible, surely the reading I have suggested is a >> plausible one. Do you agree? It seems clear, given how the >> second sentence is phrased, that this suggested reading is what >> was intended. > > I still can't read it the way you do. Every time I try, I find > the consistency is to be taken as applying to the results of the > multiple calls between pairs of the same objects. Nothing more. > It starts with "When the same objects". It seems so clear that > the consistency is all about the multiple calls with these same > objects. I keep trying to see your reading of it, but I can't. Yes, the phrase "the same objects" starts one down a wrong path. What I think is meant is that "sameness" applies to objects individually, without regard to what the object is being compared to. It's a tricky point because it isn't literally the same object: what is meant is the same "logical" object, not the same physical object. If you think of "the same objects" as meaning a set of individual logical objects, rather than pairs of logical objects, that might be a way to dislodge the (unfortunately all too easy to fall into) initial impression. >> I don't mean to defend the quality of writing in this passage. >> Certainly it would be nice if the meaning could have been stated >> more plainly. But I think it's an overstatement to say that the >> first sentence in no way implies a total order. > > I have a second objection that promoted that remark. If I take the > (apparently) intended meaning of the first sentence, I think that > "consistent" is too weak to imply even a partial order. In dog club > tonight, because of how they get on, I will ensure that Enzo is > walking behind George, that George is walking behind Benji, Benji > behind Gibson, Gibson behind Pepper and Pepper behind Enzo. In what > sense is this "ordering" not consistent? All the calls to the > comparison function are consistent with each other. I understand the objection, and this is the point I was trying to make in the paragraph about children in the Jones family. The phrase "one another" in "the results shall be consistent with one another" is meant to be read as saying "all the results taken together". It is not enough that results not be contradictory taken two at a time; considering all the results at once must not lead to an ordering contradiction. Hopefully this has been helpful for you. If it hasn't I'd like to hear where the sticking points are.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-23 19:55 +0100 |
| Message-ID | <v59r2b$fc9m$1@dont-email.me> |
| In reply to | #386395 |
On 23/06/2024 17:47, Tim Rentsch wrote: > > Yes, it's a serious suggestion, and I'm sorry if it came across as > condescending. I did this search myself, and learned something from > it. The important point is the "consistent with" is something of an > idiomatic phrase, and it doesn't mean "equivalent to" or "the same > as". Maybe you already knew that, but I didn't, and learning it > helped me see what the quoted passage is getting at. > We've established that the wife was in the house at the time when the husband was killed. Which is consistent with her having done the murder. But it doesn't by itself prove that she did the murder. However had we been able to show that she was elsewhere at the time, that would not be consistent with her having done the murder, and so she would be dropped as a suspect. -- Check out my hobby project. http://malcolmmclean.github.io/babyxrc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-24 09:34 -0700 |
| Message-ID | <86sex2e1ve.fsf@linuxsc.com> |
| In reply to | #386400 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 23/06/2024 17:47, Tim Rentsch wrote: > >> Yes, it's a serious suggestion, and I'm sorry if it came across as >> condescending. I did this search myself, and learned something from >> it. The important point is the "consistent with" is something of an >> idiomatic phrase, and it doesn't mean "equivalent to" or "the same >> as". Maybe you already knew that, but I didn't, and learning it >> helped me see what the quoted passage is getting at. > > We've established that the wife was in the house at the time when the > husband was killed. Which is consistent with her having done the > murder. But it doesn't by itself prove that she did the > murder. However had we been able to show that she was elsewhere at the > time, that would not be consistent with her having done the murder, > and so she would be dropped as a suspect. Please don't post this sort of stupid pointless comment again.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-23 23:30 +0100 |
| Message-ID | <87bk3rpa00.fsf@bsb.me.uk> |
| In reply to | #386395 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > >> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> >>> Ben Bacarisse <ben@bsb.me.uk> writes: >>> >>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>> >>>>> Ben Bacarisse <ben@bsb.me.uk> writes: >>>>> [...] >>>>> >>>>>> On a C language point, I don't think the standard says anything >>>>>> about sorting with non-order functions like the one above. Is >>>>>> an implementation of qsort permitted to misbehave (for example >>>>>> by not terminating) when the comparison function does not >>>>>> implement a proper order relation? >>>>> >>>>> N1570 7.22.5p4 (applies to bsearch and qsort): >>>>> """ >>>>> When the same objects (consisting of size bytes, irrespective of >>>>> their current positions in the array) are passed more than once >>>>> to the comparison function, the results shall be consistent with >>>>> one another. That is, for qsort they shall define a total >>>>> ordering on the array, and for bsearch the same object shall >>>>> always compare the same way with the key. >>>>> """ >>>>> >>>>> That's a "shall" outside a constraint, so violating it results in >>>>> undefined behavior. >>>> >>>> I think it should be clearer. What the "that is" phrase seems to >>>> clarify in no way implies a total order, merely that the repeated >>>> comparisons or the same elements are consistent with one another. >>>> That the comparison function defines a total order on the elements >>>> is, to me, a major extra constraint that should not be written as >>>> an apparent clarification to something the does not imply it: >>>> repeated calls should be consistent with one another and, in >>>> addition, a total order should be imposed on the elements present. >>> >>> I think you're misreading the first sentence. >> >> Let's hope so. That's why I said it should be clearer, not that it >> was wrong. >> >>> Suppose we are in >>> court listening to an ongoing murder trial. Witness one comes in >>> and testifies that Alice left the house before Bob. Witness two >>> comes in (after witness one has gone) and testifies that Bob left >>> the house before Cathy. Witness three comes in (after the first >>> two have gone) and testifies that Cathy left the house before >>> Alice. None of the witnesses have contradicted either of the >>> other witnesses, but the testimonies of the three witnesses are >>> not consistent with one another. >> >> My (apparently incorrect) reading of the first sentence is that >> the consistency is only required between the results of multiple >> calls between each pair. In other words, if the witnesses are >> repeatedly asked, again and again, if Alice left before Bob and/or >> if Bob left before Alice the results would always be consistent >> (with, of course, the same required of repeatedly asking about the >> other pairs of people). > > Let me paraphrase that. When the same pair of objects is passed > more than once to individual calls of the comparison function, the > results of those different calls shall each be consistent with > every other one of the results. No, only with the results of the other calls that get passed the same pair. If cmp(&a, &b) == -32 then cmp(&a, &b) must always be negative (though not always -32) and cmp(&b, &a) must always be positive. To me, this reading is backed up by the remark about "regardless of where in the array they are". > To paraphrase my reading, when some set of "same" objects is each > passed more than once to individual calls of the comparison > function, the results of all of those calls taken together shall > not imply an ordering contradiction. > > Are the last two paragraphs fair restatements of our respective > readings? I don't think so. The first does not seem to be what I meant, and the second begs a question: what is an ordering contradiction? Maybe I could work out what you mean by that if I thought about it some more, but this discussion has reminded me why I swore not to discuss wording and interpretation on Usenet. You found the wording adequate. I didn't. I won't mind if no one ever knows exactly why I didn't. C has managed fine with this wording for decades so there is no practical problem. I think enough time has been spent on this discussion already, but I can sense more is likely to spent. > Is the second paragraph plain enough so that you > would not misconstrue it if read in isolation? Or if not, can > you suggest a better phrasing? Since I don't know what an ordering contradiction is, I can't suggest an alternative. >>> Try a web search >>> >>> "consistent with" definition >>> >>> for more explanation. >> >> Seriously? > > Yes, it's a serious suggestion, and I'm sorry if it came across as > condescending. I did this search myself, and learned something from > it. The important point is the "consistent with" is something of an > idiomatic phrase, and it doesn't mean "equivalent to" or "the same > as". Maybe you already knew that, but I didn't, and learning it > helped me see what the quoted passage is getting at. I find that /inconsistent/ with what I've previously inferred about your knowledge of English, but I have to take your word for it. If you care to be less cryptic, maybe you will say what it was about the meaning of "consistent with" that helped you see what the text in question was getting at. >>> Also, for "one another", if we say the >>> children in the Jones family get along with one another, we don't >>> mean that each child gets along with at least one of the others, >>> but instead mean that every child gets along with every other >>> child, that is, that they all get along with each other. >> >> The sentence in question has, to my mind, already stated what the >> "one another" refers to -- the multiple calls between pairs >> containing the same objects. I get you think that's not the >> intended meaning, but I get my reading so strongly that I struggle >> to see the other. > > Yes, I got that. The incongruity between the first sentence and the > second sentence prompted me to re-examine the entire paragraph, > which is what eventually led me to my current reading. > > >>> Whether >>> or not some other reading (of that problem sentence in the C >>> standard) is sensible, surely the reading I have suggested is a >>> plausible one. Do you agree? It seems clear, given how the >>> second sentence is phrased, that this suggested reading is what >>> was intended. >> >> I still can't read it the way you do. Every time I try, I find >> the consistency is to be taken as applying to the results of the >> multiple calls between pairs of the same objects. Nothing more. >> It starts with "When the same objects". It seems so clear that >> the consistency is all about the multiple calls with these same >> objects. I keep trying to see your reading of it, but I can't. > > Yes, the phrase "the same objects" starts one down a wrong path. > What I think is meant is that "sameness" applies to objects > individually, without regard to what the object is being compared > to. It's a tricky point because it isn't literally the same object: > what is meant is the same "logical" object, not the same physical > object. If you think of "the same objects" as meaning a set of > individual logical objects, rather than pairs of logical objects, > that might be a way to dislodge the (unfortunately all too easy > to fall into) initial impression. Can you express this mathematically? I can't follow these words at all. I am clearly getting mentally old. >>> I don't mean to defend the quality of writing in this passage. >>> Certainly it would be nice if the meaning could have been stated >>> more plainly. But I think it's an overstatement to say that the >>> first sentence in no way implies a total order. >> >> I have a second objection that promoted that remark. If I take the >> (apparently) intended meaning of the first sentence, I think that >> "consistent" is too weak to imply even a partial order. In dog club >> tonight, because of how they get on, I will ensure that Enzo is >> walking behind George, that George is walking behind Benji, Benji >> behind Gibson, Gibson behind Pepper and Pepper behind Enzo. In what >> sense is this "ordering" not consistent? All the calls to the >> comparison function are consistent with each other. > > I understand the objection, and this is the point I was trying to > make in the paragraph about children in the Jones family. The > phrase "one another" in "the results shall be consistent with one > another" is meant to be read as saying "all the results taken > together". It is not enough that results not be contradictory taken > two at a time; considering all the results at once must not lead to > an ordering contradiction. So you agree that the first sentence in no way implies a total order? All the results of the dog-order comparison function, taken together, are consistent with the circular order, which is obviously not a total order. I must be missing something because you don't say anything else to indicate a change of opinion. Are you making what to me is a circular argument that consistent means consistent with a total order, not some other ordering relationship? > Hopefully this has been helpful for you. If it hasn't I'd like to > hear where the sticking points are. I think I am a little more confused than I was. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-24 01:53 -0700 |
| Message-ID | <86ikxyg1rs.fsf@linuxsc.com> |
| In reply to | #386404 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: >> >>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >>> >>>> Ben Bacarisse <ben@bsb.me.uk> writes: >>>> >>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >>>>> >>>>>> Ben Bacarisse <ben@bsb.me.uk> writes: >>>>>> [...] >>>>>> >>>>>>> On a C language point, I don't think the standard says anything >>>>>>> about sorting with non-order functions like the one above. Is >>>>>>> an implementation of qsort permitted to misbehave (for example >>>>>>> by not terminating) when the comparison function does not >>>>>>> implement a proper order relation? >>>>>> >>>>>> N1570 7.22.5p4 (applies to bsearch and qsort): >>>>>> """ >>>>>> When the same objects (consisting of size bytes, irrespective of >>>>>> their current positions in the array) are passed more than once >>>>>> to the comparison function, the results shall be consistent with >>>>>> one another. That is, for qsort they shall define a total >>>>>> ordering on the array, and for bsearch the same object shall >>>>>> always compare the same way with the key. >>>>>> """ >>>>>> >>>>>> That's a "shall" outside a constraint, so violating it results in >>>>>> undefined behavior. >>>>> >>>>> I think it should be clearer. What the "that is" phrase seems to >>>>> clarify in no way implies a total order, merely that the repeated >>>>> comparisons or the same elements are consistent with one another. >>>>> That the comparison function defines a total order on the elements >>>>> is, to me, a major extra constraint that should not be written as >>>>> an apparent clarification to something the does not imply it: >>>>> repeated calls should be consistent with one another and, in >>>>> addition, a total order should be imposed on the elements present. >>>> >>>> I think you're misreading the first sentence. >>> >>> Let's hope so. That's why I said it should be clearer, not that it >>> was wrong. >>> >>>> Suppose we are in >>>> court listening to an ongoing murder trial. Witness one comes in >>>> and testifies that Alice left the house before Bob. Witness two >>>> comes in (after witness one has gone) and testifies that Bob left >>>> the house before Cathy. Witness three comes in (after the first >>>> two have gone) and testifies that Cathy left the house before >>>> Alice. None of the witnesses have contradicted either of the >>>> other witnesses, but the testimonies of the three witnesses are >>>> not consistent with one another. >>> >>> My (apparently incorrect) reading of the first sentence is that >>> the consistency is only required between the results of multiple >>> calls between each pair. In other words, if the witnesses are >>> repeatedly asked, again and again, if Alice left before Bob and/or >>> if Bob left before Alice the results would always be consistent >>> (with, of course, the same required of repeatedly asking about the >>> other pairs of people). >> >> Let me paraphrase that. When the same pair of objects is passed >> more than once to individual calls of the comparison function, the >> results of those different calls shall each be consistent with >> every other one of the results. > > No, only with the results of the other calls that get passed the same > pair. [...] Sorry, my oversight. That's is what I meant. "When the same pair of objects is passed more than once to individual calls of the comparison function, the results of those different calls shall each be consistent with every other one of THOSE results." The consistency is meant to be only between results of comparisons of the same pair. (This mistake illustrates how hard it is to write good specifications in the C standard.) >> To paraphrase my reading, when some set of "same" objects is each >> passed more than once to individual calls of the comparison >> function, the results of all of those calls taken together shall >> not imply an ordering contradiction. >> >> Are the last two paragraphs fair restatements of our respective >> readings? > > I don't think so. The first does not seem to be what I meant, and the > second begs a question: what is an ordering contradiction? A conclusion that violates the usual mathematical rules of the relations less than, equal to, greater than: A<B and B<C implies A<C, A<B implies A!=B, A=B implies not A<B, A<B implies B>A, etc. > Maybe I could work out what you mean by that if I thought about it > some more, but this discussion has reminded me why I swore not to > discuss wording and interpretation on Usenet. You found the wording > adequate. I didn't. I won't mind if no one ever knows exactly why > I didn't. C has managed fine with this wording for decades so there > is no practical problem. I think enough time has been spent on this > discussion already, but I can sense more is likely to spent. A small correction: I found the wording understandable. If the question is about adequacy, I certainly can't give the current wording 10 out of 10. I would like to see the specification for qsort stated more plainly. Although, as you can see, I'm having trouble figuring out how to do that. >> Is the second paragraph plain enough so that you >> would not misconstrue it if read in isolation? Or if not, can >> you suggest a better phrasing? > > Since I don't know what an ordering contradiction is, I can't suggest > an alternative. Now that I have explained that phrase, I hope you will have a go at finding a better wording. >>>> Try a web search >>>> >>>> "consistent with" definition >>>> >>>> for more explanation. >>> >>> Seriously? >> >> Yes, it's a serious suggestion, and I'm sorry if it came across as >> condescending. I did this search myself, and learned something from >> it. The important point is the "consistent with" is something of an >> idiomatic phrase, and it doesn't mean "equivalent to" or "the same >> as". Maybe you already knew that, but I didn't, and learning it >> helped me see what the quoted passage is getting at. > > I find that /inconsistent/ with what I've previously inferred about > your knowledge of English, but I have to take your word for it. In many cases my knowledge of English that is on display here comes only after the fact. I routinely look up words and phrases during the process of composing messages for the newsgroups. > If you care to be less cryptic, maybe you will say what it was > about the meaning of "consistent with" that helped you see what > the text in question was getting at. I think the key thing is that "consistent with" doesn't mean the same. If we're comparing the same pair of objects over and over, the results are either the same or they are different. It would be odd to use "consistent with one another" if all that mattered is whether they are all the same. (I suppose some people would think that compare(A,B) < 0 and compare(B,A) > 0 are different results, but at least for qsort I don't.) If "consistent with one another" doesn't mean "all the same", then "the same objects" must not mean the same pairs over and over. I'm guessing about what happened because my thought process was not a completely conscious one, but this line of reasoning seems plausible. >>>> Also, for "one another", if we say the >>>> children in the Jones family get along with one another, we don't >>>> mean that each child gets along with at least one of the others, >>>> but instead mean that every child gets along with every other >>>> child, that is, that they all get along with each other. >>> >>> The sentence in question has, to my mind, already stated what the >>> "one another" refers to -- the multiple calls between pairs >>> containing the same objects. I get you think that's not the >>> intended meaning, but I get my reading so strongly that I struggle >>> to see the other. >> >> Yes, I got that. The incongruity between the first sentence and the >> second sentence prompted me to re-examine the entire paragraph, >> which is what eventually led me to my current reading. >> >> >>>> Whether >>>> or not some other reading (of that problem sentence in the C >>>> standard) is sensible, surely the reading I have suggested is a >>>> plausible one. Do you agree? It seems clear, given how the >>>> second sentence is phrased, that this suggested reading is what >>>> was intended. >>> >>> I still can't read it the way you do. Every time I try, I find >>> the consistency is to be taken as applying to the results of the >>> multiple calls between pairs of the same objects. Nothing more. >>> It starts with "When the same objects". It seems so clear that >>> the consistency is all about the multiple calls with these same >>> objects. I keep trying to see your reading of it, but I can't. >> >> Yes, the phrase "the same objects" starts one down a wrong path. >> What I think is meant is that "sameness" applies to objects >> individually, without regard to what the object is being compared >> to. It's a tricky point because it isn't literally the same object: >> what is meant is the same "logical" object, not the same physical >> object. If you think of "the same objects" as meaning a set of >> individual logical objects, rather than pairs of logical objects, >> that might be a way to dislodge the (unfortunately all too easy >> to fall into) initial impression. > > Can you express this mathematically? I can't follow these > words at all. I am clearly getting mentally old. Something like this: if we label values in the array with their initial position in the array, where the label stays with the value when array elements are exchanged, consider now the set of labels whose corresponding objects are each passed to the comparison function more than once; this in turn induces a set of ordering relationships on the labels. Then the set of label order relationships must obey the usual mathematical rules for the ordering relations less than, equal to, and greater than. Not the best writing I've ever done there. It is at least a bit more mathematical. >>>> I don't mean to defend the quality of writing in this passage. >>>> Certainly it would be nice if the meaning could have been stated >>>> more plainly. But I think it's an overstatement to say that the >>>> first sentence in no way implies a total order. >>> >>> I have a second objection that promoted that remark. If I take the >>> (apparently) intended meaning of the first sentence, I think that >>> "consistent" is too weak to imply even a partial order. In dog club >>> tonight, because of how they get on, I will ensure that Enzo is >>> walking behind George, that George is walking behind Benji, Benji >>> behind Gibson, Gibson behind Pepper and Pepper behind Enzo. In what >>> sense is this "ordering" not consistent? All the calls to the >>> comparison function are consistent with each other. >> >> I understand the objection, and this is the point I was trying to >> make in the paragraph about children in the Jones family. The >> phrase "one another" in "the results shall be consistent with one >> another" is meant to be read as saying "all the results taken >> together". It is not enough that results not be contradictory taken >> two at a time; considering all the results at once must not lead to >> an ordering contradiction. > > So you agree that the first sentence in no way implies a total order? Well, no, I wouldn't say that. The first sentence does in /some/ ways imply a total order. Unfortunately it can be read in other ways that do not imply a total order. But I can't say that in no way does it imply a total order. > All the results of the dog-order comparison function, taken together, > are consistent with the circular order, which is obviously not a total > order. If A<B, B<C, C<D, D<E, and E<A, we can infer from the transitivity of the "less than" relation that A<A. But A<A can never be true, so this set of comparison results is no good. So I guess what we have discovered is that "consistent with one another" is intended to mean "obeys the usual mathematical rules for ordering relations". > I must be missing something because you don't say anything else to > indicate a change of opinion. Are you making what to me is a circular > argument that consistent means consistent with a total order, not some > other ordering relationship? The qsort function takes a pointer-to-function argument to perform comparisons between objects. That function is obligated to return an integer less than, equal to, or greater than zero if the first argument is considered to be respectively less than, equal to, or greater than the second argument. "Consistent with" means that the results indicating less than, equal to, or greater than must obey the usual mathematical rules, as I tried to explain above, for those relationships. That these results define a total ordering is a consequence of the results obeying the usual mathematical rules. It occurs to me now to say that "consistent with" is meant to include logical inference. That distinction is a key difference between "consistent" and "consistent with" (at least as the two terms might be understood). The combination of: one, the results of the comparison function are seen as corresponding to an ordering relation; and two, that "consistent with one another" includes logical inferences considering all of the results together; is what allows us to conclude that the results define a total order. I'm sorry if any of the above sounds like it's just stating the obvious. I'm strugging trying to find a way to explain what to me seems straightforward. >> Hopefully this has been helpful for you. If it hasn't I'd like to >> hear where the sticking points are. > > I think I am a little more confused than I was. I am confident that the click will happen. On the other hand, I was surprised the other day when I looked up "optimist" in the dictionary and found a picture of myself. ;)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-25 01:30 +0100 |
| Message-ID | <87cyo5oodb.fsf@bsb.me.uk> |
| In reply to | #386442 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben@bsb.me.uk> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>
>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>
>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>>
>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>>
>>>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>>>> [...]
>>>>>>>
>>>>>>>> On a C language point, I don't think the standard says anything
>>>>>>>> about sorting with non-order functions like the one above. Is
>>>>>>>> an implementation of qsort permitted to misbehave (for example
>>>>>>>> by not terminating) when the comparison function does not
>>>>>>>> implement a proper order relation?
>>>>>>>
>>>>>>> N1570 7.22.5p4 (applies to bsearch and qsort):
>>>>>>> """
>>>>>>> When the same objects (consisting of size bytes, irrespective of
>>>>>>> their current positions in the array) are passed more than once
>>>>>>> to the comparison function, the results shall be consistent with
>>>>>>> one another. That is, for qsort they shall define a total
>>>>>>> ordering on the array, and for bsearch the same object shall
>>>>>>> always compare the same way with the key.
>>>>>>> """
>>>>>>>
>>>>>>> That's a "shall" outside a constraint, so violating it results in
>>>>>>> undefined behavior.
>>>>>>
>>>>>> I think it should be clearer. What the "that is" phrase seems to
>>>>>> clarify in no way implies a total order, merely that the repeated
>>>>>> comparisons or the same elements are consistent with one another.
>>>>>> That the comparison function defines a total order on the elements
>>>>>> is, to me, a major extra constraint that should not be written as
>>>>>> an apparent clarification to something the does not imply it:
>>>>>> repeated calls should be consistent with one another and, in
>>>>>> addition, a total order should be imposed on the elements present.
>>>>>
>>>>> I think you're misreading the first sentence.
>>>>
>>>> Let's hope so. That's why I said it should be clearer, not that it
>>>> was wrong.
>>>>
>>>>> Suppose we are in
>>>>> court listening to an ongoing murder trial. Witness one comes in
>>>>> and testifies that Alice left the house before Bob. Witness two
>>>>> comes in (after witness one has gone) and testifies that Bob left
>>>>> the house before Cathy. Witness three comes in (after the first
>>>>> two have gone) and testifies that Cathy left the house before
>>>>> Alice. None of the witnesses have contradicted either of the
>>>>> other witnesses, but the testimonies of the three witnesses are
>>>>> not consistent with one another.
>>>>
>>>> My (apparently incorrect) reading of the first sentence is that
>>>> the consistency is only required between the results of multiple
>>>> calls between each pair. In other words, if the witnesses are
>>>> repeatedly asked, again and again, if Alice left before Bob and/or
>>>> if Bob left before Alice the results would always be consistent
>>>> (with, of course, the same required of repeatedly asking about the
>>>> other pairs of people).
>>>
>>> Let me paraphrase that. When the same pair of objects is passed
>>> more than once to individual calls of the comparison function, the
>>> results of those different calls shall each be consistent with
>>> every other one of the results.
>>
>> No, only with the results of the other calls that get passed the same
>> pair. [...]
>
> Sorry, my oversight. That's is what I meant. "When the same pair
> of objects is passed more than once to individual calls of the
> comparison function, the results of those different calls shall
> each be consistent with every other one of THOSE results." The
> consistency is meant to be only between results of comparisons
> of the same pair. (This mistake illustrates how hard it is to
> write good specifications in the C standard.)
>
>>> To paraphrase my reading, when some set of "same" objects is each
>>> passed more than once to individual calls of the comparison
>>> function, the results of all of those calls taken together shall
>>> not imply an ordering contradiction.
>>>
>>> Are the last two paragraphs fair restatements of our respective
>>> readings?
>>
>> I don't think so. The first does not seem to be what I meant, and the
>> second begs a question: what is an ordering contradiction?
>
> A conclusion that violates the usual mathematical rules of the
> relations less than, equal to, greater than: A<B and B<C implies
> A<C, A<B implies A!=B, A=B implies not A<B, A<B implies B>A, etc.
>
>> Maybe I could work out what you mean by that if I thought about it
>> some more, but this discussion has reminded me why I swore not to
>> discuss wording and interpretation on Usenet. You found the wording
>> adequate. I didn't. I won't mind if no one ever knows exactly why
>> I didn't. C has managed fine with this wording for decades so there
>> is no practical problem. I think enough time has been spent on this
>> discussion already, but I can sense more is likely to spent.
>
> A small correction: I found the wording understandable. If the
> question is about adequacy, I certainly can't give the current
> wording 10 out of 10. I would like to see the specification for
> qsort stated more plainly. Although, as you can see, I'm having
> trouble figuring out how to do that.
>
>>> Is the second paragraph plain enough so that you
>>> would not misconstrue it if read in isolation? Or if not, can
>>> you suggest a better phrasing?
>>
>> Since I don't know what an ordering contradiction is, I can't suggest
>> an alternative.
>
> Now that I have explained that phrase, I hope you will have a go
> at finding a better wording.
I would not introduce your new term, "an ordering contradiction", since
it still leaves exactly what kind of order vague. You interpret
"consistent" as "consistent with a total order" so I'd use that phrase:
"when some set of 'same' objects is each passed more than once to
individual calls of the comparison function, the results of all of
those calls taken together shall be consistent with a total order"
Presumably you came to interpret "consistent with one another" as
implying a total order rather because of the sentence that follows
("That is, for qsort they shall define a total ordering on the array").
I could not do that because I was interpreting the text about multiple
calls differently.
>>> ... The important point is the "consistent with" is something of an
>>> idiomatic phrase, and it doesn't mean "equivalent to" or "the same
>>> as". Maybe you already knew that, but I didn't, and learning it
>>> helped me see what the quoted passage is getting at.
...
>> If you care to be less cryptic, maybe you will say what it was
>> about the meaning of "consistent with" that helped you see what
>> the text in question was getting at.
>
> I think the key thing is that "consistent with" doesn't mean the
> same. If we're comparing the same pair of objects over and over,
> the results are either the same or they are different. It would
> be odd to use "consistent with one another" if all that mattered
> is whether they are all the same.
I never thought they were the same. The trouble is that (a) different
results imply the same order (e.g. -1 and -34 all mean <) and (b) the
(old) wording does not say that the objects are passed in the same order
and the result of cmp(a, b) can't be the same as cmp(b, a) but they can
be consistent. This makes "consistent with one another" a perfectly
reasonable thing to say even in my limited view of what results are
being talked about.
...
>>>> I have a second objection that promoted that remark. If I take the
>>>> (apparently) intended meaning of the first sentence, I think that
>>>> "consistent" is too weak to imply even a partial order. In dog club
>>>> tonight, because of how they get on, I will ensure that Enzo is
>>>> walking behind George, that George is walking behind Benji, Benji
>>>> behind Gibson, Gibson behind Pepper and Pepper behind Enzo. In what
>>>> sense is this "ordering" not consistent? All the calls to the
>>>> comparison function are consistent with each other.
>>>
>>> I understand the objection, and this is the point I was trying to
>>> make in the paragraph about children in the Jones family. The
>>> phrase "one another" in "the results shall be consistent with one
>>> another" is meant to be read as saying "all the results taken
>>> together". It is not enough that results not be contradictory taken
>>> two at a time; considering all the results at once must not lead to
>>> an ordering contradiction.
...
>> All the results of the dog-order comparison function, taken together,
>> are consistent with the circular order, which is obviously not a total
>> order.
>
> If A<B, B<C, C<D, D<E, and E<A, we can infer from the transitivity
> of the "less than" relation that A<A. But A<A can never be true, so
> this set of comparison results is no good.
[Technical aside. The relation should be seen as <=. not <. You can't
conclude that I intended A < A from the informal presentation -- no dog
can be behind itself. However, this does not alter your argument in any
significant way.]
> So I guess what we have
> discovered is that "consistent with one another" is intended to mean
> "obeys the usual mathematical rules for ordering relations".
I would say this is backwards. You are assuming the usual rules where I
gave an order that is not at all usual with the purpose of showing that
some sets of comparisons between pairs can be "consistent with one
another" when the ordering is very peculiar.
On a more mathematical note, imagine that the text was describing a
topological sort function. Is there anything in your reading of the
first sentence that would make it inappropriate? If not, that
"consistent with one another" can't imply a total order.
...
> It occurs to me now to say that "consistent with" is meant to
> include logical inference.
Sure.
> That distinction is a key difference
> between "consistent" and "consistent with" (at least as the two
> terms might be understood). The combination of: one, the results
> of the comparison function are seen as corresponding to an ordering
> relation;
But, according to you, only some ordering relations.
> and two, that "consistent with one another" includes
> logical inferences considering all of the results together; is what
> allows us to conclude that the results define a total order.
Could the sentence in question be used in the description of a
topological sort based (rather unusually) on a partial order?
> I'm sorry if any of the above sounds like it's just stating the
> obvious. I'm strugging trying to find a way to explain what to
> me seems straightforward.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-26 12:59 -0700 |
| Message-ID | <86frszeaqn.fsf@linuxsc.com> |
| In reply to | #386490 |
Ben Bacarisse <ben@bsb.me.uk> writes:
(I am lazily keeping everything so I don't have to
think about what to exclude. I have changed some
white space but otherwise it's all here.)
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>
>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>
>>>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>>>
>>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>>>
>>>>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>>>>
>>>>>>>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> On a C language point, I don't think the standard says
>>>>>>>>> anything about sorting with non-order functions like the one
>>>>>>>>> above. Is an implementation of qsort permitted to misbehave
>>>>>>>>> (for example by not terminating) when the comparison
>>>>>>>>> function does not implement a proper order relation?
>>>>>>>>
>>>>>>>> N1570 7.22.5p4 (applies to bsearch and qsort):
>>>>>>>> """
>>>>>>>> When the same objects (consisting of size bytes, irrespective
>>>>>>>> of their current positions in the array) are passed more than
>>>>>>>> once to the comparison function, the results shall be
>>>>>>>> consistent with one another. That is, for qsort they shall
>>>>>>>> define a total ordering on the array, and for bsearch the
>>>>>>>> same object shall always compare the same way with the key.
>>>>>>>> """
>>>>>>>>
>>>>>>>> That's a "shall" outside a constraint, so violating it
>>>>>>>> results in undefined behavior.
>>>>>>>
>>>>>>> I think it should be clearer. What the "that is" phrase seems
>>>>>>> to clarify in no way implies a total order, merely that the
>>>>>>> repeated comparisons or the same elements are consistent with
>>>>>>> one another. That the comparison function defines a total
>>>>>>> order on the elements is, to me, a major extra constraint that
>>>>>>> should not be written as an apparent clarification to
>>>>>>> something the does not imply it: repeated calls should be
>>>>>>> consistent with one another and, in addition, a total order
>>>>>>> should be imposed on the elements present.
>>>>>>
>>>>>> I think you're misreading the first sentence.
>>>>>
>>>>> Let's hope so. That's why I said it should be clearer, not that
>>>>> it was wrong.
>>>>>
>>>>>> Suppose we are in court listening to an ongoing murder trial.
>>>>>> Witness one comes in and testifies that Alice left the house
>>>>>> before Bob. Witness two comes in (after witness one has gone)
>>>>>> and testifies that Bob left the house before Cathy. Witness
>>>>>> three comes in (after the first two have gone) and testifies
>>>>>> that Cathy left the house before Alice. None of the witnesses
>>>>>> have contradicted either of the other witnesses, but the
>>>>>> testimonies of the three witnesses are not consistent with one
>>>>>> another.
>>>>>
>>>>> My (apparently incorrect) reading of the first sentence is that
>>>>> the consistency is only required between the results of multiple
>>>>> calls between each pair. In other words, if the witnesses are
>>>>> repeatedly asked, again and again, if Alice left before Bob
>>>>> and/or if Bob left before Alice the results would always be
>>>>> consistent (with, of course, the same required of repeatedly
>>>>> asking about the other pairs of people).
>>>>
>>>> Let me paraphrase that. When the same pair of objects is passed
>>>> more than once to individual calls of the comparison function,
>>>> the results of those different calls shall each be consistent
>>>> with every other one of the results.
>>>
>>> No, only with the results of the other calls that get passed the
>>> same pair. [...]
>>
>> Sorry, my oversight. That's is what I meant. "When the same pair
>> of objects is passed more than once to individual calls of the
>> comparison function, the results of those different calls shall
>> each be consistent with every other one of THOSE results." The
>> consistency is meant to be only between results of comparisons of
>> the same pair. (This mistake illustrates how hard it is to write
>> good specifications in the C standard.)
>>
>>>> To paraphrase my reading, when some set of "same" objects is each
>>>> passed more than once to individual calls of the comparison
>>>> function, the results of all of those calls taken together shall
>>>> not imply an ordering contradiction.
>>>>
>>>> Are the last two paragraphs fair restatements of our respective
>>>> readings?
>>>
>>> I don't think so. The first does not seem to be what I meant, and
>>> the second begs a question: what is an ordering contradiction?
>>
>> A conclusion that violates the usual mathematical rules of the
>> relations less than, equal to, greater than: A<B and B<C implies
>> A<C, A<B implies A!=B, A=B implies not A<B, A<B implies B>A, etc.
>>
>>> Maybe I could work out what you mean by that if I thought about it
>>> some more, but this discussion has reminded me why I swore not to
>>> discuss wording and interpretation on Usenet. You found the
>>> wording adequate. I didn't. I won't mind if no one ever knows
>>> exactly why I didn't. C has managed fine with this wording for
>>> decades so there is no practical problem. I think enough time has
>>> been spent on this discussion already, but I can sense more is
>>> likely to spent.
>>
>> A small correction: I found the wording understandable. If the
>> question is about adequacy, I certainly can't give the current
>> wording 10 out of 10. I would like to see the specification for
>> qsort stated more plainly. Although, as you can see, I'm having
>> trouble figuring out how to do that.
>>
>>>> Is the second paragraph plain enough so that you would not
>>>> misconstrue it if read in isolation? Or if not, can you suggest
>>>> a better phrasing?
>>>
>>> Since I don't know what an ordering contradiction is, I can't
>>> suggest an alternative.
>>
>> Now that I have explained that phrase, I hope you will have a go
>> at finding a better wording.
>
> I would not introduce your new term, "an ordering contradiction",
> since it still leaves exactly what kind of order vague.
My original thinking was that "ordering contradiction" would be a
good choice for your benefit, not that it would be good phrasing
for the C standard. Apparently my aim was not so good.
> You interpret "consistent" as "consistent with a total order"
Actually I don't. More below.
> so I'd use that phrase:
>
> "when some set of 'same' objects is each passed more than once
> to individual calls of the comparison function, the results of
> all of those calls taken together shall be consistent with a
> total order"
>
> Presumably you came to interpret "consistent with one another" as
> implying a total order rather because of the sentence that follows
> ("That is, for qsort they shall define a total ordering on the
> array").
Actually not. To me the two sentences are not equivalent. More
specifically, the first is weaker than the second. More below.
> I could not do that because I was interpreting the text about
> multiple calls differently.
Yes, I understand that now, moreso than before.
>>>> ... The important point is the "consistent with" is something of
>>>> an idiomatic phrase, and it doesn't mean "equivalent to" or "the
>>>> same as". Maybe you already knew that, but I didn't, and
>>>> learning it helped me see what the quoted passage is getting at.
>
> ...
>
>>> If you care to be less cryptic, maybe you will say what it was
>>> about the meaning of "consistent with" that helped you see what
>>> the text in question was getting at.
>>
>> I think the key thing is that "consistent with" doesn't mean the
>> same. If we're comparing the same pair of objects over and over,
>> the results are either the same or they are different. It would
>> be odd to use "consistent with one another" if all that mattered
>> is whether they are all the same.
>
> I never thought they were the same. The trouble is that (a)
> different results imply the same order (e.g. -1 and -34 all mean
> <) and (b) the (old) wording does not say that the objects are
> passed in the same order and the result of cmp(a, b) can't be the
> same as cmp(b, a) but they can be consistent. This makes
> "consistent with one another" a perfectly reasonable thing to say
> even in my limited view of what results are being talked about.
It's interesting that our mental pictures here are so different.
To me there is no difference between a return value of -1 and a
return value of -34. To say that more generally, different
return values that have the same meaning are the same result.
That idea also applies changing the order of operands, so a
compare( a, b ) being positive is the same result as getting a
negative value from compare( b, a ). "Results" of a comparison
between a and b are either a<b, a==b, or a>b. The actual values
returned are incidental (and probably aren't even looked at
except to compare them to zero).
(That reminds me, I have a little challenge/puzzle exercise that
might be fun for people, and it is related to the previous
paragraph, so maybe that will get me to post it.)
Because I see "sameness of results" as being determined by
meaning, and not by what particular values come back, it wouldn't
have occurred to me to think "consistent with" was there just to
account for differences in the values. That difference in
viewpoint may account for much of the difference in our first
impressions of the "consistent with one another" sentence in the
C standard.
>
> ...
>
>>>>> I have a second objection that promoted that remark. If I take
>>>>> the (apparently) intended meaning of the first sentence, I think
>>>>> that "consistent" is too weak to imply even a partial order. In
>>>>> dog club tonight, because of how they get on, I will ensure that
>>>>> Enzo is walking behind George, that George is walking behind
>>>>> Benji, Benji behind Gibson, Gibson behind Pepper and Pepper
>>>>> behind Enzo. In what sense is this "ordering" not consistent?
>>>>> All the calls to the comparison function are consistent with
>>>>> each other.
>>>>
>>>> I understand the objection, and this is the point I was trying to
>>>> make in the paragraph about children in the Jones family. The
>>>> phrase "one another" in "the results shall be consistent with one
>>>> another" is meant to be read as saying "all the results taken
>>>> together". It is not enough that results not be contradictory
>>>> taken two at a time; considering all the results at once must
>>>> not lead to an ordering contradiction.
>
> ...
>
>>> All the results of the dog-order comparison function, taken
>>> together, are consistent with the circular order, which is
>>> obviously not a total order.
>>
>> If A<B, B<C, C<D, D<E, and E<A, we can infer from the transitivity
>> of the "less than" relation that A<A. But A<A can never be true,
>> so this set of comparison results is no good.
>
> [Technical aside. The relation should be seen as <=. not <. You
> can't conclude that I intended A < A from the informal
> presentation -- no dog can be behind itself. However, this does
> not alter your argument in any significant way.]
Different authors define "total ordering" differently. Also some
authors base the discussion on < rather than <=. I'm taking your
comment above narrowly in that it is meant to apply only to the
dog-order example, and not meant to be universal. However, if
the dog-order relation is meant to be <= rather than <, then the
dog-order example is consistent with "total orderings that allow
equality". The C standard uses "total ordering" in this sense,
because the comparison function can return an "equal" result for
distinct objects. For contrast, the integers have a "total
ordering that does not allow equality": for any two distinct
integers, it is always the case that one of them is less than the
other (and they are never equal). To me it's a little bit funny
to call a set "totally ordered" if equality is allowed, although
of course I understand what is meant in such cases.
>> So I guess what we have discovered is that "consistent with one
>> another" is intended to mean "obeys the usual mathematical rules
>> for ordering relations".
>
> I would say this is backwards. You are assuming the usual rules
> where I gave an order that is not at all usual with the purpose of
> showing that some sets of comparisons between pairs can be
> "consistent with one another" when the ordering is very peculiar.
I didn't understand before that you meant the "behind" relation
to be one that might not satisfy the axioms of "less than", but
rather just the axioms of "less than or equal". So I missed that
point earlier. Hopefully I'm caught up now.
> On a more mathematical note, imagine that the text was describing
> a topological sort function. Is there anything in your reading of
> the first sentence that would make it inappropriate? If not, that
> "consistent with one another" can't imply a total order.
I take up this question when it is raised again below.
> ...
>
>> It occurs to me now to say that "consistent with" is meant to
>> include logical inference.
>
> Sure.
>
>> That distinction is a key difference between "consistent" and
>> "consistent with" (at least as the two terms might be understood).
>> The combination of: one, the results of the comparison function
>> are seen as corresponding to an ordering relation;
>
> But, according to you, only some ordering relations.
I am guilty of somewhat sloppy language there. Strictly speaking
an ordering relation is all the ordered pairs that define the
relationship. The results of all the comparisons done corresponds
(at least usually) to only a subset of the ordered pairs of an
ordering relation. The qsort function needs to do only enough
comparisons so that the closure of those results defines a total
ordering. As long as the set of comparisons actually done is a
subset of some totally ordered relation then the program is okay
and hasn't wandered off into the UB weeds. However, if the set
of all N*(N-1) comparisons (which includes reversing the argument
orders) would give results that are not a subset of a total
ordering, then which total ordering is determined (by a qsort
call that doesn't encounter UB) depends on which comparisons were
actually done. Considering all that I think my last sentence
above is better stated as "the results of the comparison calls
performed corresponds to a subset of some ordering relation".
>> and two, that "consistent with one another" includes logical
>> inferences considering all of the results together; is what
>> allows us to conclude that the results define a total order.
>
> Could the sentence in question be used in the description of a
> topological sort based (rather unusually) on a partial order?
Short answer: doing a topological sort requires a different
interface, and that change of context changes the meaning of the
phrase "consistent with one another".
Longer answer: the comparison function in the qsort interface is
specified as giving one of three results: a<b, a==b, a>b. The
returned value must indicate one of those three possibilities.
To do a (general) topological sort, there needs to be another
possibility, namely, that a and b are unrelated. There are now
four mutually exclusive possibilities. Note that "unrelated"
cannot be the same as "equal". The reason is that "equal" is
transitive but "unrelated" is not. In particular, we can have
a!=!b, b!=!c, but a<c rather than a!=!c (using !=! to mean
"unrelated"). That combination cannot occur for equal: if a==b
and b==c, then a==c. I expect you are already familiar with
these ideas; I'm going through them mainly as a check on my own
thinking.
A literal answer to your question is that the sentence about
being "consistent with one another" could also be used in a
different function that would do topological sorts. But the
meaning of the sentence would be different, because of changes in
how the comparison function would have to be specified. I guess
I should add, as I understand the meaning of these passages in
the C standard.
To me, the meaning of the phrase "consistent with one another" is
meant to be taken relative to the specifications of the comparison
function, whose results are three mutually exclusive cases: less
than, equal to, greater than. The C standard tacitly takes the
view that these operations behave like the ones we learned about
in grade school. As long as the results of comparisons done are
not in conflict with a logically valid deduction, under the usual
mathematical rules for these elementary relationships, with all of
the comparison results assumed as being true as a starting point,
then the condition of the first sentence is satisfied. But that
being true does not by itself show that the comparison results
define a total ordering.
To conclude that the comparison results define a total ordering,
we need to add what the standard says about the return value of
qsort, namely, that array elements are placed in ascending order.
This condition can be achieved only enough comparisons have been
done to determine a total order. The second sentence augments
the "consistent with" condition in the first sentence with a
tacit recognition of the qsort return condition to say comparison
results must define a total ordering. So a full statement might
be that the comparison results shall be consistent with one
another and they shall be sufficient to determine the total
ordering required by the output condition. The C standard
collapses those two parts down into the shorter second sentence.
In any case that's how I read this part of the standard. I hope
that clarifies my earlier statements.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben@bsb.me.uk> |
|---|---|
| Date | 2024-06-26 23:46 +0100 |
| Message-ID | <878qyrmif8.fsf@bsb.me.uk> |
| In reply to | #386569 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > Ben Bacarisse <ben@bsb.me.uk> writes: > > (I am lazily keeping everything so I don't have to > think about what to exclude. I have changed some > white space but otherwise it's all here.) And I have lazily removed it all because I need to call it a day. I am grateful for you very patient replies and I hope you will not be disappointed if I don't reply in detail to you latest. I think I understand your position (though I would not want to try to summarise it) and I think you understand how I was initially reading the text. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-06-26 17:48 -0700 |
| Message-ID | <86bk3ndxda.fsf@linuxsc.com> |
| In reply to | #386580 |
Ben Bacarisse <ben@bsb.me.uk> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Ben Bacarisse <ben@bsb.me.uk> writes: >> >> (I am lazily keeping everything so I don't have to >> think about what to exclude. I have changed some >> white space but otherwise it's all here.) > > And I have lazily removed it all because I need to call it a day. Oh good. Thank you for the extremely brief reply. > I am grateful for you very patient replies and I hope you will not be > disappointed if I don't reply in detail to you latest. I think I > understand your position (though I would not want to try to summarise > it) and I think you understand how I was initially reading the text. Yes, I think so too. A nice way to finish.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-19 13:23 -0700 |
| Message-ID | <878qz0y94t.fsf@nosuchdomain.example.com> |
| In reply to | #386227 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 18/06/2024 23:49, Keith Thompson wrote:
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> [...]
>>> And it didn't take long to get Python to sort the list alphabetically,
>>> but there seemed no way in to the sort comparision function
>>> itself. And I had to give up.
>> <OT>
>> https://docs.python.org/3/library/functions.html#sorted
>> https://docs.python.org/3/library/stdtypes.html#list.sort
>> </OT>
>>
> key specifies a function of one argument that is used to extract a
> comparison key from each element in iterable (for example,
> key=str.lower). The default value is None (compare the elements directly).
>
> You see the problem.
[...]
Yes, I see the problem.
Follow the second link I posted above. The 4th paragraph provides a
solution to your problem.
If you have any questions, ask them in comp.lang.python, not here.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-19 07:44 +0200 |
| Message-ID | <v4tr8c$1qoda$1@dont-email.me> |
| In reply to | #386185 |
On 18/06/2024 18:39, Malcolm McLean wrote: > On 18/06/2024 16:40, Michael S wrote: >> On Tue, 18 Jun 2024 14:36:40 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> >>> Of course if you don't know Python, it will be slower to write it in >>> Python! >>> >> >> I don't know Python well, but it does not meant that I don't know it at >> all. >> Few minutes ago I took a look into docs and it seems that situation with >> writing binary data files with predefined layout is better than what I >> was suspecting. They have something called "Buffer Protocol". It allows >> to specify layout in declarative manner, similarly to C struct or may >> be even to Ada's records with representation clause. >> However attempt to read the doc page further down proved that my >> suspicion about steepness of the learning curve was not wrong :( >> >> > My main experience of Python was that we had some resource files which > were icons, in matching light and dark themes. The light theme had > suffix _L followed by extension, and the dark themes had _D. And they > needed to be sorted alphabetically, except that _L should be placed > before _D. > And it didn't take long to get Python to sort the list alphabetically, > but there seemed no way in to the sort comparision function itself. And > I had to give up. > Python "sort" is a bit like C "qsort" (desperately trying to relate this to the group topicality) in that you can define your own comparison function, and use that for "sort". For simple comparison functions, people often use lambdas, for more complicated ones it's clearer to define a function with a name.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-06-19 02:27 -0700 |
| Message-ID | <87le31xoyf.fsf@nosuchdomain.example.com> |
| In reply to | #386217 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Python "sort" is a bit like C "qsort" (desperately trying to relate
> this to the group topicality) in that you can define your own
> comparison function, and use that for "sort". For simple comparison
> functions, people often use lambdas, for more complicated ones it's
> clearer to define a function with a name.
Not exactly (see the Python documentation), but this isn't the place to
go into the details.
--
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 | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-06-19 13:17 +0300 |
| Subject | sort - C, python, C++, glibc Was: Baby X is bor nagain |
| Message-ID | <20240619131758.0000032e@yahoo.com> |
| In reply to | #386217 |
On Wed, 19 Jun 2024 07:44:44 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 18/06/2024 18:39, Malcolm McLean wrote: > >> > >> > > My main experience of Python was that we had some resource files > > which were icons, in matching light and dark themes. The light > > theme had suffix _L followed by extension, and the dark themes had > > _D. And they needed to be sorted alphabetically, except that _L > > should be placed before _D. > > And it didn't take long to get Python to sort the list > > alphabetically, but there seemed no way in to the sort comparision > > function itself. And I had to give up. > > > > Python "sort" is a bit like C "qsort" (desperately trying to relate > this to the group topicality) in that you can define your own > comparison function, and use that for "sort". For simple comparison > functions, people often use lambdas, for more complicated ones it's > clearer to define a function with a name. > > Off topic: Indeed, Python sort has option for specifying comparison function, but I would not call it very similar to comparison function of C qsort since in Python comparison is not applied directly to the record. Instead, it applied to the keys that are derived from record. Besides, my impression is that in Python sorting by user-supplied comparison function is less idiomatic than doing all heavy lifting in user-supplied key function. For the case, presented by Malcolm, I'd certainly do it all in key(), without custom cmp_to_key(). May be, it's a little less efficient, but significantly easier to comprehend. Back to topic: C qsort() sucks. They forgot to provide an option for 3rd parameter (context) in comparison callback. Back to O.T.: Python's sort bypasses the problem by allowing lambda as a key() function, so it could have visibility of variables of the caller. IMHO, it still sucks. C++ way, where comparison can be functor, sucks far less. I find it less than obvious, but at least all functionality one can ever want is available. Back to topic: why C standard committee still didn't add something like gnu qsort_r() to the standard?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-19 12:53 +0200 |
| Subject | Re: sort - C, python, C++, glibc Was: Baby X is bor nagain |
| Message-ID | <v4udb1$1u14i$2@dont-email.me> |
| In reply to | #386230 |
On 19/06/2024 12:17, Michael S wrote: > On Wed, 19 Jun 2024 07:44:44 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 18/06/2024 18:39, Malcolm McLean wrote: >>>> >>>> >>> My main experience of Python was that we had some resource files >>> which were icons, in matching light and dark themes. The light >>> theme had suffix _L followed by extension, and the dark themes had >>> _D. And they needed to be sorted alphabetically, except that _L >>> should be placed before _D. >>> And it didn't take long to get Python to sort the list >>> alphabetically, but there seemed no way in to the sort comparision >>> function itself. And I had to give up. >>> >> >> Python "sort" is a bit like C "qsort" (desperately trying to relate >> this to the group topicality) in that you can define your own >> comparison function, and use that for "sort". For simple comparison >> functions, people often use lambdas, for more complicated ones it's >> clearer to define a function with a name. >> >> > > Off topic: > Indeed, Python sort has option for specifying comparison function, but > I would not call it very similar to comparison function of C qsort > since in Python comparison is not applied directly to the record. Yes, it seems that the comparison function support in sort() was in Python 2 but was dropped for Python 3. > Instead, it applied to the keys that are derived from record. > Besides, my impression is that in Python sorting by user-supplied > comparison function is less idiomatic than doing all heavy lifting in > user-supplied key function. A key function can be applied once per item, while a comparison function is called once per comparison - thus key functions will be (or at least /can/ be) more efficient. > For the case, presented by Malcolm, I'd certainly do it all in key(), > without custom cmp_to_key(). May be, it's a little less efficient, but > significantly easier to comprehend. > > Back to topic: > C qsort() sucks. They forgot to provide an option for 3rd parameter > (context) in comparison callback. It is also not guaranteed to be stable (which is important in some contexts), and it is a misnomer - it is rarely a quicksort. > Back to O.T.: > Python's sort bypasses the problem by allowing lambda as a key() > function, so it could have visibility of variables of the caller. IMHO, > it still sucks. > C++ way, where comparison can be functor, sucks far less. I find it > less than obvious, but at least all functionality one can ever want is > available. The C++ way is also massively more efficient than C in cases where the comparison function is simple. And it is typesafe. > > Back to topic: why C standard committee still didn't add something like > gnu qsort_r() to the standard? > That is a little more flexible, but it's still ugly!
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-06-19 18:42 +0100 |
| Subject | Re: sort - C, python, C++, glibc Was: Baby X is bor nagain |
| Message-ID | <v4v5ai$230pu$1@dont-email.me> |
| In reply to | #386235 |
On 19/06/2024 11:53, David Brown wrote: > On 19/06/2024 12:17, Michael S wrote: >> On Wed, 19 Jun 2024 07:44:44 +0200 >> David Brown <david.brown@hesbynett.no> wrote: >> >>> On 18/06/2024 18:39, Malcolm McLean wrote: >>>>> >>>> My main experience of Python was that we had some resource files >>>> which were icons, in matching light and dark themes. The light >>>> theme had suffix _L followed by extension, and the dark themes had >>>> _D. And they needed to be sorted alphabetically, except that _L >>>> should be placed before _D. >>>> And it didn't take long to get Python to sort the list >>>> alphabetically, but there seemed no way in to the sort comparision >>>> function itself. And I had to give up. >>> >>> Python "sort" is a bit like C "qsort" (desperately trying to relate >>> this to the group topicality) in that you can define your own >>> comparison function, and use that for "sort". For simple comparison >>> functions, people often use lambdas, for more complicated ones it's >>> clearer to define a function with a name. >>> >>> >> >> Off topic: >> Indeed, Python sort has option for specifying comparison function, but >> I would not call it very similar to comparison function of C qsort >> since in Python comparison is not applied directly to the record. > > Yes, it seems that the comparison function support in sort() was in > Python 2 but was dropped for Python 3. > This is exactly the sort of carry on which causes problems. You have a requirement for a custom sort. And, whilst I'm sure that the sort I ak=sked for is possible to achieve, its not exacty obvious how to achieve it from someone brought up on sort. So you trying looking it up on the web, and every answer is bases on Pyhtn 2 sort, which has been taken away. >> Instead, it applied to the keys that are derived from record. >> Besides, my impression is that in Python sorting by user-supplied >> comparison function is less idiomatic than doing all heavy lifting in >> user-supplied key function. > > A key function can be applied once per item, while a comparison function > is called once per comparison - thus key functions will be (or at least > /can/ be) more efficient. > >> For the case, presented by Malcolm, I'd certainly do it all in key(), >> without custom cmp_to_key(). May be, it's a little less efficient, but >> significantly easier to comprehend. >> >> Back to topic: >> C qsort() sucks. They forgot to provide an option for 3rd parameter >> (context) in comparison callback. > >> Back to topic: why C standard committee still didn't add something like >> gnu qsort_r() to the standard? >> > > That is a little more flexible, but it's still ugly! > You seldom need a context pointer for sort functions. They must be pure functions, or at least they must return the same result for the same two copmarisions. And it's rare that it makes sense to give them extra paeameers. -- Check out my hobby project. http://malcolmmclean.github.io/babyxrc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-06-19 07:39 +0200 |
| Message-ID | <v4tquf$1qn6n$1@dont-email.me> |
| In reply to | #386181 |
On 18/06/2024 17:40, Michael S wrote: > On Tue, 18 Jun 2024 14:36:40 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> >> Of course if you don't know Python, it will be slower to write it in >> Python! >> > > I don't know Python well, but it does not meant that I don't know it at > all. > Few minutes ago I took a look into docs and it seems that situation with > writing binary data files with predefined layout is better than what I > was suspecting. They have something called "Buffer Protocol". It allows > to specify layout in declarative manner, similarly to C struct or may > be even to Ada's records with representation clause. > However attempt to read the doc page further down proved that my > suspicion about steepness of the learning curve was not wrong :( > > "Buffer protocol" is for passing data between Python and C extensions, which is certainly a complicated business. For dealing with binary data in specific formats in Python, the "struct" module is your friend. It lets you pack and unpack data with specific sizes and endianness using a compact format string notation. I've used it for dealing with binary file formats and especially for network packets. There's also the ctypes module which is aimed at duplicating C-style types and structures, primarily for interfacing with DLL's and dynamic so libraries.
[toc] | [prev] | [next] | [standalone]
Page 6 of 18 — ← Prev page 1 … 4 5 [6] 7 8 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web