Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #147715 > unrolled thread
| Started by | DFS <nospam@dfs.com> |
|---|---|
| First post | 2019-11-07 10:39 -0500 |
| Last post | 2019-11-11 00:56 +0000 |
| Articles | 20 on this page of 220 — 19 participants |
Back to article view | Back to comp.lang.c
mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 10:39 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 07:48 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:02 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 11:34 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-07 08:41 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:02 -0500
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:37 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 14:38 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:44 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:01 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:39 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 10:52 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 11:12 +0100
Re: mergesort code segfaulting on smallish arrays Barry Schwarz <schwarzb@delq.com> - 2019-11-07 12:28 -0800
Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-07 13:13 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 00:55 +0000
Re: mergesort code segfaulting on smallish arrays jadill33@gmail.com - 2019-11-08 05:30 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:50 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:31 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:39 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 17:53 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:15 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 20:01 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 00:24 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 09:44 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 15:45 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:30 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:41 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 19:29 +0000
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:59 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:00 +0000
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 11:24 +1300
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 22:48 +0000
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:09 +1300
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 14:46 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:11 +0000
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 17:27 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 14:53 -0800
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-10 12:02 +1300
Re: mergesort code segfaulting on smallish arrays Ian Collins <ian-news@hotmail.com> - 2019-11-09 09:25 +1300
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-09 20:18 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 21:55 -0500
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 09:49 +0000
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-07 10:34 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 16:12 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 12:19 -0500
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-07 17:42 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-07 13:32 -0500
Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 11:15 -0700
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
Re: mergesort code segfaulting on smallish arrays Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-11-07 19:11 -0700
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-07 21:57 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 09:21 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-08 04:10 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 13:21 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 04:12 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 13:55 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 09:20 -0500
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 10:23 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 16:36 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 11:56 -0500
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 09:42 -0800
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 13:39 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:14 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:00 -0500
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-15 08:17 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-15 13:16 -0800
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-15 22:35 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-16 13:34 -0800
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-16 23:01 +0000
Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 08:34 +0000
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:13 +0000
Re: mergesort code segfaulting on smallish arrays Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-11-17 09:30 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-17 13:53 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:27 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-17 09:44 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-17 10:50 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-16 07:26 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 18:07 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-08 12:40 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 20:41 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-14 13:28 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 06:14 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:03 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 02:20 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:21 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 08:30 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 12:50 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:18 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-09 14:27 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 07:46 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 09:32 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-13 09:34 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:01 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:19 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 16:32 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 17:50 +0100
Re: mergesort code segfaulting on smallish arrays chad <cdalten@gmail.com> - 2019-11-13 11:09 -0800
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-13 19:18 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 20:31 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 17:12 -0800
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 20:26 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:16 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:40 +0100
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-14 01:11 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:41 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:42 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:56 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 10:42 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-14 06:39 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-13 21:38 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:33 +0100
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 05:44 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 14:48 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 15:01 +0100
Re: mergesort code segfaulting on smallish arrays Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-11-08 08:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-08 17:12 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-08 16:34 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-12 17:05 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:07 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-08 23:50 +0000
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-08 19:55 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:27 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:33 +0000
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-09 18:05 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:58 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:39 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 12:48 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:38 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 13:42 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 14:46 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:04 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:05 +0100
Re: mergesort code segfaulting on smallish arrays Melzzzzz <Melzzzzz@zzzzz.com> - 2019-11-10 14:09 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:19 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:06 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:22 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:30 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:36 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:59 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:26 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:56 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:21 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:28 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 15:38 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:58 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 16:59 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 16:24 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:37 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 17:22 +0000
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 18:04 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:10 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:14 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 02:14 +0000
Re: mergesort code segfaulting on smallish arrays DFS <nospam@dfs.com> - 2019-11-10 22:07 -0500
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 22:16 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 06:52 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 10:33 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 23:28 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 10:56 +0100
Re: mergesort code segfaulting on smallish arrays "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-11-12 02:35 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:01 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:08 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-12 15:53 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 16:56 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-11 13:45 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:03 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:29 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:18 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 17:27 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 08:43 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:01 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 09:41 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 18:44 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:00 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:03 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:22 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-12 20:24 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-12 11:44 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 06:23 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 06:40 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-13 16:34 +0100
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-13 08:41 -0800
Re: mergesort code segfaulting on smallish arrays James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-11 11:24 -0800
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:13 -0800
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:36 +0000
Re: mergesort code segfaulting on smallish arrays Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-10 05:27 -0800
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 05:25 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 11:30 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:49 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 12:21 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 18:53 +0100
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 13:33 -0500
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 19:37 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-09 18:51 +0000
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 14:46 -0500
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
Re: mergesort code segfaulting on smallish arrays Bart <bc@freeuk.com> - 2019-11-10 14:48 +0000
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:35 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:39 +0100
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 19:54 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 19:55 +0100
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 21:34 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 21:37 +0100
Re: mergesort code segfaulting on smallish arrays Robert Wessel <robertwessel2@yahoo.com> - 2019-11-11 11:12 -0600
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:28 +0100
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 15:41 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:47 -0800
Re: mergesort code segfaulting on smallish arrays David Brown <david.brown@hesbynett.no> - 2019-11-10 15:08 +0100
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-10 14:30 -0800
Re: mergesort code segfaulting on smallish arrays Keith Thompson <kst-u@mib.org> - 2019-11-09 12:43 -0800
Re: mergesort code segfaulting on smallish arrays Richard Damon <Richard@Damon-Family.org> - 2019-11-09 17:16 -0500
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-09 19:27 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 05:55 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-10 16:45 +0000
Re: mergesort code segfaulting on smallish arrays Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-10 17:53 +0100
Re: mergesort code segfaulting on smallish arrays Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-11-11 00:56 +0000
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 20:24 +0100 |
| Message-ID | <qqf0u8$4lf$1@news.albasani.net> |
| In reply to | #147972 |
> Even what I did wasn't really safe since FLT/DBL_EPSILON just guarantees
> that you can add it to 1.0, but theres not a guarantee to subtract it.
The thing is simply that if you do 1.0 - DBL_EPSILON / FLT_RADIX you
can't rely on that the subtract would be done with a larger precision
than a double can hold so that you wouldn't get 1.0. Maybe the following
would be the best.
1.0 - DBL_EPSILON / FLT_RADIX != 1.0 - DBL_EPSILON ?
1.0 - DBL_EPSILON / FLT_RADIX : 1.0 - DBL_EPSILON
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 11:44 -0800 |
| Message-ID | <6cee65fc-3d3a-4b43-906a-e80fa5276d75@googlegroups.com> |
| In reply to | #147974 |
On Tuesday, November 12, 2019 at 2:25:05 PM UTC-5, Bonita Montero wrote: > > Even what I did wasn't really safe since FLT/DBL_EPSILON just guarantees > > that you can add it to 1.0, but theres not a guarantee to subtract it. > > The thing is simply that if you do 1.0 - DBL_EPSILON / FLT_RADIX you > can't rely on that the subtract would be done with a larger precision > than a double can hold so that you wouldn't get 1.0. Subtraction using a larger precision isn't needed; double is required to have enough precision to represent that value. If it doesn't, either FLT_RADIX or DBL_EPSILON have values that violate the requirements of 5.2.4.2.2p11, or the representation of doubles does not provide a good match to the description in 5.2.4.2.2p1-2. Give it a try. Store 1.0-DBLEPSILON/FLT_RADIX in a variable - the excess precision must be discarded (5.2.4.2.2p9). Put the code that sets the value of that variable in a different translation unit than the code which subtracts it from 1.0, to minimize (but not eliminate) the possibility of the code being optimized by eliminating the discarding of the excess precision. You should still see a difference.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-13 06:23 +0100 |
| Message-ID | <qqg40l$pep$1@news.albasani.net> |
| In reply to | #147975 |
> Subtraction using a larger precision isn't needed; ... You rely on IEEE-754-typical behaviour.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-13 06:40 -0800 |
| Message-ID | <1605eae5-58db-42eb-acda-e06e3a5c55e2@googlegroups.com> |
| In reply to | #148215 |
On Wednesday, November 13, 2019 at 12:23:43 AM UTC-5, Bonita Montero wrote: > > Subtraction using a larger precision isn't needed; ... > > You rely on IEEE-754-typical behaviour. In what way? As I told you before, the only things that I am relying on are that the floating point format fits the model described in 5.2.4.2.2p1-2, and that the implementation of C conforms to all of the requirements listed in the rest of 5.2.4.2.2. I only directly used the requirements imposed on the values of FLT_RADIX and DBL_EPSILON by 5.2.4.2.2p11, but I am also indirectly relying upon several of the other requirements in that section. For instance, an implementation with e_max = -1 would not be able to represent 1.0 -DBL_EPSILON/FLT_RADIX, but such an implementation would also violate the lower limit imposed by 5.2.4.2.2p11 on DBL_MAX. If you're sure that my argument rests on something more than those requirements, please explain how it does. One simple way to do so would be to describe a floating point format that is not capable of representing 1.0-DBL_EPSILON/FLT_RADIX, despite fitting that model and meeting those requirements. When I ask you to describe it, I'm not asking for full documentation of the format (though if you could provide a link to such documentation, it certainly wouldn't hurt). All I'm asking for is the following things: * Of the parameters described in 5.2.4.2.2p1, b, e_min, e_max, and p are characteristics of the floating point format. Please provide the values of those parameters for your chosen format. * Please provide the values for DBL_EPSILON and FLT_RADIX for that format. These can be derived from the values of b and p, but I want to verify that you're calculating them correctly. * The other parameters described in that section, s, e, and f_k, are characteristics of the representation of a particular number in that format. Please explain why the representation for which s==+1, e==0, and f_k==b-1 for all values of k, fails to qualify as a valid representation of 1.0 - DBL_EPSILON/FLT_RADIX when using that floating point format. Note: the floating point format that you describe needn't be a real one - I'm much more comfortable with theory than you are. All that is required is that the format you describe fits the model, meets the requirements, and is incapable of representing 1.0 - DBL_EPSILON/FLT_RADIX. If I am indeed relying on IEEE 754 features not covered by those requirements, it should be easy to invent a format demonstrating that fact.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-13 16:34 +0100 |
| Message-ID | <qqh7pu$vln$1@news.albasani.net> |
| In reply to | #148231 |
The thing is simply that a sub might subtract only the overlapping mantissa-parts of two floating-point-values. With that your idea might not work.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-13 08:41 -0800 |
| Message-ID | <0a028424-9728-422b-86d1-5759c7207341@googlegroups.com> |
| In reply to | #148234 |
On Wednesday, November 13, 2019 at 10:34:34 AM UTC-5, Bonita Montero wrote: > The thing is simply that a sub might subtract only the overlapping > mantissa-parts of two floating-point-values. With that your idea > might not work. That's permissible, because unless __STDC_IEC_559__ is pre#defined by the implementation, the C standard allows floating point arithmetic and library functions are allowed to be so inaccurate as to be worse than useless. That is why I only talked about whether the relevant value is representable in a given floating point format, not about whether that expression would actually produce such a value. Do you have any way that you can even imagine, for a floating point format that fits the standard's models, and meets the standard's requirements, to not be able to represent that value?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-11 11:24 -0800 |
| Message-ID | <1ca96484-2548-4ae9-8aba-bfc0d86024a0@googlegroups.com> |
| In reply to | #147905 |
On Sunday, November 10, 2019 at 10:28:48 AM UTC-5, Bonita Montero wrote:
> > for( size_t &d : distrib )
> > cout << d << endl;
> > Output is:
> > average: 3906.25
> > standard deviation: 249.61
> > 3967
> > 3825
> > 3883
> > ....
> > 3899
> > 3922
> > 4035
> > 37
> >
> > average: 250000
> > standard deviation: 0
> > 250000
> > 250000
> > 250000
> > 250000
>
> That's absolutely normal with a PRNG, that you won't get an even
> distribution.
Designing a PRNG that produces an exactly uniform distribution is quite trivial, and to the best of my knowledge is done by almost all of them. Perhaps you're thinking of rescaling the result returned by a PRNG to an arbitrary range?
If you use an acceptance/rejection algorithm (which has been demonstrated in other messages in this thread), the result is exactly uniform, but has the disadvantage that the function will make an unpredictable number of calls to rand(), with no upper limit on that number. However, the usual methods for rescaling can produce an exactly even distribution only if the number of different values in the range divides RAND_MAX+1 evenly.
However, it's quite feasible to do a much better job of evenly
distributing the numbers than your original function. The following
emulates a rand() with a RAND_MAX of 32767, the minimum allowed by the
standard, to make the differences easier to see. but ensures exactly
uniform results by deterministically cycling through all of the possible
values exactly once. I translated "int" to "int16_t" in all of the
relevant functions, to roughly emulate an environment where such a
rand() would be reasonable. This has the convenient result that
"unsigned long" is guaranteed to be able to hold the largest possible
product that could occur in my own function.
#include <fenv.h>
#include <float.h>
#include <stdint.h>
#include <stdio.h>
static int16_t rand=-1;
#define RAND_MAX 32767
static int16_t randInt(int16_t low, int16_t high)
{ // DFS's original function.
return (low + rand / (RAND_MAX / (high - low + 1) + 1));
}
static int16_t randIt(int16_t low, int16_t high)
{ // Bonita's Suggestion 2019-11-08
return low + (int16_t)((uint64_t)rand * (uint16_t)(high - low) /
RAND_MAX);
}
static int16_t randNbr(int16_t low, int16_t high)
{ // Bart's suggestion 2019-11-10
int span=high-low+1;
return rand % span+low; // changed rand() to mrand()
}
static int16_t randIt2(int16_t low, int16_t high)
{ // Bart's fix to Bonita's Suggestion 2019-11-10
return low + (int16_t)((uint64_t)rand * (uint16_t)(high - low+1) /
RAND_MAX);
}
static int16_t rangeRand(int16_t low, int16_t high)
{ // Bonita's alternative suggestion 2019-11-11
double const NEARLY_ONE = 1.0 - DBL_EPSILON;
int rm = fegetround();
fesetround(FE_TOWARDZERO );
uint16_t ret = low + (uint16_t)(rand * ((double)high - low + NEARLY_ONE)
/ RAND_MAX);
fesetround( rm );
return ret;
}
static int16_t randKuyper(int16_t low, int16_t high)
{
return low + (int16_t) ((1UL+2UL*rand)*(1UL + high - low)
/(2UL*(1UL + RAND_MAX)));
}
#define LOW 1
#define HIGH 12
// Check for values less than low or higher than high
#define COUNTS (3+HIGH-LOW)
int main(void)
{
struct {
char *name;
int16_t (*func)(int16_t,int16_t);
unsigned long total;
int count[COUNTS];
} transforms[] = {
{"randInt", randInt},
{"randIt", randIt},
{"randNbr", randNbr},
{"randIt2", randIt2},
{"rangeRand", rangeRand},
{"randKuyper", randKuyper}
};
#define TRANS (sizeof transforms/sizeof *transforms)
do {
rand++;
for(int tran=0; tran<TRANS; tran++)
{
int16_t val = transforms[tran].func(LOW, HIGH);
if(val < 0 || val >= COUNTS)
printf("%s() returned %d for rand=%d.\n",
transforms[tran].name, val, rand);
else {
transforms[tran].count[val]++;
transforms[tran].total += val;
}
}
} while(rand < RAND_MAX);
for(int tran=0; tran<TRANS; tran++)
{
printf("%11s", transforms[tran].name);
for(int val=0; val<COUNTS; val++)
printf("%4d ", transforms[tran].count[val]);
printf("%f\n", transforms[tran].total/(RAND_MAX+1.0));
}
return 0;
}
randIt is one of the worst, producing a value of 12 far too infrequently.
randIt2 is another one of the worst, because it sometimes produces 13.
rangeRand() is pretty good, but uses some expensive floating point
operations to produce results similar to randKuyper(), which only uses
integer operations.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-10 05:13 -0800 |
| Message-ID | <86h83bdgdb.fsf@linuxsc.com> |
| In reply to | #147828 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> Isn't it the case that the routine being discussed is supposed to >> be able to return the value high? ... > > Yes, it should. But DFS' implementation is absolutely confused. Yours is nothing to write home about.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-09 19:36 +0000 |
| Message-ID | <8736ew4zav.fsf@bsb.me.uk> |
| In reply to | #147807 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> int randIt( int low, int high )
>>> {
>>> return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>>> }
>>
>> This function has numerous problems. [...] perhaps the most
>> dangerous is that it can return high. [...]
>
> Isn't it the case that the routine being discussed is supposed to
> be able to return the value high? More specifically, that the
> interval of possible values is meant to include both endpoints?
> I thought it was.
There have been programs posted with both forms -- where the range is
taken to be either [low, high] or [low, high).
The problem here is quite different. The return of the high value is
just a bug in this function since it occurs only when rand() returns
RAND_MAX so either the frequency with which high is returned is wrong,
or the fact that happens at all is wrong.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-11-10 05:27 -0800 |
| Message-ID | <86d0dzdfpl.fsf@linuxsc.com> |
| In reply to | #147845 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>
>>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>
>>>> int randIt( int low, int high )
>>>> {
>>>> return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>>>> }
>>>
>>> This function has numerous problems. [...] perhaps the most
>>> dangerous is that it can return high. [...]
>>
>> Isn't it the case that the routine being discussed is supposed to
>> be able to return the value high? More specifically, that the
>> interval of possible values is meant to include both endpoints?
>> I thought it was.
>
> There have been programs posted with both forms -- where the range is
> taken to be either [low, high] or [low, high).
My impression was they all were meant to be of the [low, high] form.
But then I wasn't paying very close attention so I easily could have
missed something. Anyway, no matter.
> The problem here is quite different. The return of the high value is
> just a bug in this function since it occurs only when rand() returns
> RAND_MAX so either the frequency with which high is returned is wrong,
> or the fact that happens at all is wrong.
Right. I already understood this from your earlier comment and just
didn't say anything about it. We might say the frequency is wrong
in both cases - far too low if high is meant to be included, and far
too high (infinitely so) if it isn't.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-09 05:25 +0100 |
| Message-ID | <qq5f40$cc6$1@news.albasani.net> |
| In reply to | #147802 |
>> int randIt( int low, int high )
>> {
>> return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>> }
> This function has numerous problems. Two signed operations can
> overflow, and you will get entirely unexpected results if RAND_MAX is
> INT_MAX on a machine with 64-bit int.
Which signed operands? rand() is converted to uint64_t and thereby
the whole inner term also. On today's machines INT_MAX - INT_MIN
can be converted to an unsigned and will fit it it. Both terms
multiplied are unlikely to owerflow because an int treated as an
unsigned and an unsigned multiplied will fit into an uint64_t on
any today's compiler. And the division by RAND_MAX gets the margins
back to high - low; so I can safely add low.
So there's nothing which will overflow here.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-09 11:30 -0500 |
| Message-ID | <%QBxF.59077$VR.21809@fx39.iad> |
| In reply to | #147808 |
On 11/8/19 11:25 PM, Bonita Montero wrote:
>>> int randIt( int low, int high )
>>> {
>>> return low + (int)((uint64_t)rand() * (unsigned)(high - low) /
>>> RAND_MAX);
>>> }
>
>> This function has numerous problems. Two signed operations can
>> overflow, and you will get entirely unexpected results if RAND_MAX is
>> INT_MAX on a machine with 64-bit int.
>
> Which signed operands? rand() is converted to uint64_t and thereby
> the whole inner term also. On today's machines INT_MAX - INT_MIN
> can be converted to an unsigned and will fit it it. Both terms
> multiplied are unlikely to owerflow because an int treated as an
> unsigned and an unsigned multiplied will fit into an uint64_t on
> any today's compiler. And the division by RAND_MAX gets the margins
> back to high - low; so I can safely add low.
> So there's nothing which will overflow here.
high and low are signed, so their difference will be signed (and then
the answer converted to unsigned.
On most machines, that won't make a difference, but technically it could.
An actual sequence is:
get rand()
convert to uint64_t and save for later
compute high - low as int
convert difference to unsigned
convert difference to uint64_t
multiply difference by saved rand (as a uint64_t)
divide by RAND_MAX
convert to int
add low
(
If high-low is greater than int max, then the subtraction will overflow
as can the conversion of the division.
The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits.
One weakness in C is that there is no simple way to get a type twice as
big as another type to make sure that a multiply doesn't overflow.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-09 17:49 +0100 |
| Message-ID | <qq6qn0$a7t$1@news.albasani.net> |
| In reply to | #147829 |
> high and low are signed, so their difference will be signed (and then > the answer converted to unsigned. Pure theory. There is actually no machine where the differencee can't be represented in an unsigned as long as low is <= high. > An actual sequence is: > > get rand() > convert to uint64_t and save for later > compute high - low as int > convert difference to unsigned > convert difference to uint64_t > multiply difference by saved rand (as a uint64_t) > divide by RAND_MAX > convert to int > add low That's what I actually do. The conversion of the difference from unsigned to uint64_t is done implicitly. > The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits. There should be no compiler with an int larger than 32 bit.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-09 12:21 -0500 |
| Message-ID | <gACxF.16692$Uy3.10016@fx25.iad> |
| In reply to | #147830 |
On 11/9/19 11:49 AM, Bonita Montero wrote: >> high and low are signed, so their difference will be signed (and then >> the answer converted to unsigned. > > Pure theory. There is actually no machine where the differencee > can't be represented in an unsigned as long as low is <= high. It isn't that the difference can't be expressed as an unsigned (which actually it can't on every machine, as UNSIGNED_MAX might be equal to INT_MAX, this normally happening on machines that use sign-magnitude representation), but that integer overflow is undefined. I know of machines that INT_MAX - INT_MIN would yield INT_MAX, because they used saturating mathematics (these were machines used for signal processing). It may well be that on every machine that YOU have used, signed overflow has quietly wrapped, and thus the statement 'worked', but it is not promised by the Standard (but might be by a given implementation). > >> An actual sequence is: >> >> get rand() >> convert to uint64_t and save for later >> compute high - low as int >> convert difference to unsigned >> convert difference to uint64_t >> multiply difference by saved rand (as a uint64_t) >> divide by RAND_MAX >> convert to int >> add low > > That's what I actually do. The conversion of the difference from > unsigned to uint64_t is done implicitly. > >> The code also assume (perhaps acceptably) that RAND_MAX fits in 32 bits. > > There should be no compiler with an int larger than 32 bit. Yes, I currently know of none, which is why that assumption may be acceptable, but it is possible. By the straight reading of the language, on 64 bit processors, int should have been 64 bits, and long 128 bits. The fact that it would leave a hole in the type system, with no natural name for both 16 and 32 bit types provided a push to make int 'too small' for the machine at 32 bits. (It also helped that much code mistakenly assumes int is 32 bits and that the processors handle 32 bit ints well). My guess is that if/when we get to 128 bit processors, there may well be a need for int to grow up to 64 (or even 128 bits) and we will add types like short short (and maybe even long short). The language might also evolve to assume the 8-bit byte and make the fixed sized types the natural types.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-09 18:53 +0100 |
| Message-ID | <qq6uee$u6p$1@news.albasani.net> |
| In reply to | #147831 |
> It isn't that the difference can't be expressed as an unsigned (which > actually it can't on every machine, as UNSIGNED_MAX might be equal to > INT_MAX, this normally happening on machines that use sign-magnitude > representation), but that integer overflow is undefined. I know of > machines that INT_MAX - INT_MIN would yield INT_MAX, because they used > saturating mathematics (these were machines used for signal processing). Machines that used one's complement and where INT_MAX - INT_MIN couldn't be fit in an unsigned integer don't exist anymore since the 70s. All machines since then give a correct unsigned result of (unsigned)(higher - lower) for all values if higher >= lower. > It may well be that on every machine that YOU have used, signed overflow > has quietly wrapped, and thus the statement 'worked', but it is not > promised by the Standard (but might be by a given implementation). That's pure theory; CPUs that can't handle that don't exist today. > Yes, I currently know of none, which is why that assumption may be > acceptable, but it is possible. By the straight reading of the language, > on 64 bit processors, int should have been 64 bits, and long 128 bits. Quote the part of the standard. > My guess is that if/when we get to 128 bit processors, there may well be > a need for int to grow up to 64 (or even 128 bits) and we will add types > like short short (and maybe even long short). The language might also > evolve to assume the 8-bit byte and make the fixed sized types the > natural types. I think there will be never CPUs with 128 bit general-purpose registers. Everything beyond 64 bit is used for large-integer-arithmetics and that will be composed of smaller data types handled in assembly or with in- trinsic compiler-functions.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-09 13:33 -0500 |
| Message-ID | <EDDxF.50142$kt1.46202@fx46.iad> |
| In reply to | #147834 |
On 11/9/19 12:53 PM, Bonita Montero wrote: >> It isn't that the difference can't be expressed as an unsigned (which >> actually it can't on every machine, as UNSIGNED_MAX might be equal to >> INT_MAX, this normally happening on machines that use sign-magnitude >> representation), but that integer overflow is undefined. I know of >> machines that INT_MAX - INT_MIN would yield INT_MAX, because they used >> saturating mathematics (these were machines used for signal processing). > > Machines that used one's complement and where INT_MAX - INT_MIN couldn't > be fit in an unsigned integer don't exist anymore since the 70s. All > machines since then give a correct unsigned result of (unsigned)(higher > - lower) for all values if higher >= lower. > >> It may well be that on every machine that YOU have used, signed overflow >> has quietly wrapped, and thus the statement 'worked', but it is not >> promised by the Standard (but might be by a given implementation). > > That's pure theory; CPUs that can't handle that don't exist today. How sure you you of that? They may not exist on the 'Desktop', but many things still exist in the embedded market. Saturating math is even an advertised feature on some machines (typically DSPs) >> Yes, I currently know of none, which is why that assumption may be >> acceptable, but it is possible. By the straight reading of the language, >> on 64 bit processors, int should have been 64 bits, and long 128 bits. > > Quote the part of the standard. > 6.2.5p5 An object declared as type signed char occupies the same amount of storage as a “plain” char object. A “plain” int object has the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>). The 'natural' size of a machine, is the size of the registers, thus for a 64 bit machine, the natural size is 64 bits. Maybe you don't go back far enough, but I do remember the industry discussion of how to handle the 64 bit machines, and there even were some experimental implementations where int was 64 bits but there were enough issues with how it worked with the existing code base and language that keeping int at 32 bits was generally decided to be the best option. >> My guess is that if/when we get to 128 bit processors, there may well be >> a need for int to grow up to 64 (or even 128 bits) and we will add types >> like short short (and maybe even long short). The language might also >> evolve to assume the 8-bit byte and make the fixed sized types the >> natural types. > > I think there will be never CPUs with 128 bit general-purpose registers. > Everything beyond 64 bit is used for large-integer-arithmetics and that > will be composed of smaller data types handled in assembly or with in- > trinsic compiler-functions.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-09 19:37 +0100 |
| Message-ID | <qq710e$nrd$1@news.albasani.net> |
| In reply to | #147836 |
> How sure you you of that? They may not exist on the 'Desktop', but many > things still exist in the embedded market. Saturating math is even an > advertised feature on some machines (typically DSPs) CPUs with didn't use 2's complement vanished in the 70s. >> Quote the part of the standard. > 6.2.5p5 > An object declared as type signed char occupies the same amount of > storage as a “plain” char object. A “plain” int object has the natural > size suggested by the architecture of the execution environment (large > enough to contain any value in the range INT_MIN to INT_MAX as defined > in the header <limits.h>). This doesn't say that int should be 64 bit and long should be 128 bit. No language-designer would be so stupid to mandate something like this against all architectures.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-09 18:51 +0000 |
| Message-ID | <pVDxF.498186$7ei.332239@fx36.am4> |
| In reply to | #147837 |
On 09/11/2019 18:37, Bonita Montero wrote: >> How sure you you of that? They may not exist on the 'Desktop', but many >> things still exist in the embedded market. Saturating math is even an >> advertised feature on some machines (typically DSPs) > > CPUs with didn't use 2's complement vanished in the 70s. > >>> Quote the part of the standard. > >> 6.2.5p5 > >> An object declared as type signed char occupies the same amount of >> storage as a “plain” char object. A “plain” int object has the natural >> size suggested by the architecture of the execution environment (large >> enough to contain any value in the range INT_MIN to INT_MAX as defined >> in the header <limits.h>). > > This doesn't say that int should be 64 bit and long should be 128 bit. > No language-designer would be so stupid to mandate something like this > against all architectures. My two private languages have used 64-bit 'int' for a while now. It's perfect, as you rarely need to worry about things overflowing; it will accommodate most things you want to do. It's also conveniently the same size as the natural float type, and the same size as the natural raw pointer type. And of course the same size as the natural machine word size of most proper computers now (micro controllers excepted). C by contrast seems backward with its mere 32-bit ints, and the hassle of dealing with both 32 bits and 64 bits, and the discrepancies (constants and narrow types are implicitly widened to 32 bits in expressions, but need explicit widening to 64 bits), and dealing with L and LL suffixes, and %d, %ld and %lld format codes. I know there is an issue with how to deal with its char - short - int - long - long long designations, but those are only vaguely defined anyway. The int64_t etc types will not have that problem. (I've tried to create a C implementation with a 64-bit 'int', but ran into problems with the library it uses which would still have 32-bit ints, and its function prototypes use 'int' everywhere. So it was a bigger job than I would have liked, just to find out what programs might break.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-11-09 14:46 -0500 |
| Message-ID | <sIExF.40183$0X7.24378@fx09.iad> |
| In reply to | #147838 |
On 11/9/19 1:51 PM, Bart wrote: > On 09/11/2019 18:37, Bonita Montero wrote: >>> How sure you you of that? They may not exist on the 'Desktop', but many >>> things still exist in the embedded market. Saturating math is even an >>> advertised feature on some machines (typically DSPs) >> >> CPUs with didn't use 2's complement vanished in the 70s. >> >>>> Quote the part of the standard. >> >>> 6.2.5p5 >> >>> An object declared as type signed char occupies the same amount of >>> storage as a “plain” char object. A “plain” int object has the natural >>> size suggested by the architecture of the execution environment (large >>> enough to contain any value in the range INT_MIN to INT_MAX as defined >>> in the header <limits.h>). >> >> This doesn't say that int should be 64 bit and long should be 128 bit. >> No language-designer would be so stupid to mandate something like this >> against all architectures. > > > My two private languages have used 64-bit 'int' for a while now. It's > perfect, as you rarely need to worry about things overflowing; it will > accommodate most things you want to do. > > It's also conveniently the same size as the natural float type, and the > same size as the natural raw pointer type. And of course the same size > as the natural machine word size of most proper computers now (micro > controllers excepted). > > C by contrast seems backward with its mere 32-bit ints, and the hassle > of dealing with both 32 bits and 64 bits, and the discrepancies > (constants and narrow types are implicitly widened to 32 bits in > expressions, but need explicit widening to 64 bits), and dealing with L > and LL suffixes, and %d, %ld and %lld format codes. C itself doesn't define the size of an int, except to require that it must be able to span the range of -32767 to 32767. An implementation needs to decide on things like this, and for various reasons the consensus for 64 bit machines has been to make int be 32 bits, in part to have natural types for 8, 16, 32 and 64 bit values, and in part because a lot of code (mistakenly) assumes that int are 32 bits. The implicit widening to int is due to the fact that it is supposed to be the natural size of the machine, and many machines didn't have good support for operations (other than load/store) for items smaller than the natural size. You wouldn't want the language to automatically start using things bigger than an int, as that is likely less efficient. The fact that on a 64 bit machine you may want to do operations normally at 64 bits is a reason to want int to be 64 bits on that platform. > > I know there is an issue with how to deal with its char - short - int - > long - long long designations, but those are only vaguely defined > anyway. The int64_t etc types will not have that problem. > > (I've tried to create a C implementation with a 64-bit 'int', but ran > into problems with the library it uses which would still have 32-bit > ints, and its function prototypes use 'int' everywhere. So it was a > bigger job than I would have liked, just to find out what programs might > break.) Well, your problem here was you weren't creating a full implementation, if you are creating just part of an implementation, like just the compiler, then of course you need to agree with the parts you use on the definitions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-11-10 15:35 +0100 |
| Message-ID | <qq976l$8p2$1@dont-email.me> |
| In reply to | #147838 |
On 09/11/2019 19:51, Bart wrote: > On 09/11/2019 18:37, Bonita Montero wrote: >>> How sure you you of that? They may not exist on the 'Desktop', but many >>> things still exist in the embedded market. Saturating math is even an >>> advertised feature on some machines (typically DSPs) >> >> CPUs with didn't use 2's complement vanished in the 70s. >> >>>> Quote the part of the standard. >> >>> 6.2.5p5 >> >>> An object declared as type signed char occupies the same amount of >>> storage as a “plain” char object. A “plain” int object has the natural >>> size suggested by the architecture of the execution environment (large >>> enough to contain any value in the range INT_MIN to INT_MAX as defined >>> in the header <limits.h>). >> >> This doesn't say that int should be 64 bit and long should be 128 bit. >> No language-designer would be so stupid to mandate something like this >> against all architectures. > > > My two private languages have used 64-bit 'int' for a while now. It's > perfect, as you rarely need to worry about things overflowing; it will > accommodate most things you want to do. > When you are dealing with a new language, or one without significant existing code, a 64-bit basic type is a good idea. So I agree with your decision for your own languages. But C and C++ are not such languages, and making changes to what people assume is not to be done lightly. It is easy to say that any well-written C code that works with 32-bit int should continue to work with 64-bit int - but it is not always that way in practice, and not all code is well-written. There is also the fact that some code could get significantly slower if int gets bigger, due to lower cache hit rates and higher memory bus loads.
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web