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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 15:59 +0100 |
| Message-ID | <qq98kj$5mp$1@news.albasani.net> |
| In reply to | #147897 |
> Try adding +1 here to get the correct span:
> int randIt( int low, int high ) {
> return low + (int)((uint64_t)rand() *
> (unsigned)(high - low + 1) / RAND_MAX);
> }
OMG, am I talking to idiots here? That's not necessary! when rand()
returns RAND_MAX I'll get high with my code, but with yours I get
high + 1. Do you want to contend with DFS for the most goony code?
Random-number-APIs have always an _inclusive_ maximum value.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 15:26 +0000 |
| Message-ID | <M_VxF.93271$X82.85919@fx16.am4> |
| In reply to | #147902 |
On 10/11/2019 14:59, Bonita Montero wrote:
>> Try adding +1 here to get the correct span:
>> int randIt( int low, int high ) {
>> return low + (int)((uint64_t)rand() *
>> (unsigned)(high - low + 1) / RAND_MAX);
>> }
>
> OMG, am I talking to idiots here? That's not necessary! when rand()
> returns RAND_MAX I'll get high with my code, but with yours I get
> high + 1. Do you want to contend with DFS for the most goony code?
> Random-number-APIs have always an _inclusive_ maximum value.
This not my code, it is your code with an attempt at a fix. But which
turns out not to work (see my post of a few minutes ago, which also
shows my own function).
If the desired range exceeds RAND_MAX, then I wouldn't bother trying to
fix that; I would just use a new PRNG with a big enough range.
A very simple addition to your C++ test code would have shown obvious
errors with your routine, just by printing out the distrib array.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 15:56 +0100 |
| Message-ID | <qq98e4$5de$1@news.albasani.net> |
| In reply to | #147894 |
> You're completely missing the point. ... > ... > All evenly distributed. Your function returns: > Hist[0] = 798312 > Hist[1] = 801048 > Hist[2] = 800295 > Hist[3] = 800248 > Hist[4] = 97 I didn't do anything wrong; my code is correct and my test proves it. I get a zero-standard-deviation distribution when I set min to 0 and max to 3 and use your "random"-generator which generates numbers in the range 0 to including 31.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 15:21 +0000 |
| Message-ID | <4WVxF.371593$m0L.10694@fx15.am4> |
| In reply to | #147901 |
On 10/11/2019 14:56, Bonita Montero wrote:
>> You're completely missing the point. ...
>> ...
>> All evenly distributed. Your function returns:
>> Hist[0] = 798312
>> Hist[1] = 801048
>> Hist[2] = 800295
>> Hist[3] = 800248
>> Hist[4] = 97
>
> I didn't do anything wrong; my code is correct and my test proves it.
> I get a zero-standard-deviation distribution when I set min to 0 and
> max to 3 and use your "random"-generator which generates numbers in
> the range 0 to including 31.
If you say so.
The trouble is, if you want random numbers in the range 0 to 4 inclusive
for example, such as in this test, then your randIt() has a bug and will
give very skewed results as shown above.
If your test 'proves' your code is correct, then your test is faulty
too. However your own distribution test gives this, if I simply print
out the distrib array using:
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
Notice that odd '37' figure. If put that "+ 1" fix in your routine, the
output becomes:
average: 3906.11
standard deviation: 65.9222
3935
3820
3875
....
3876
3928
4003
average: 187500
standard deviation: 108253
250000
250000
250000
0
The 0..255 set is OK, but now the 0..3 range is off. So your routine
can't be fixed by adding +1 as I'd thought. Substituting my own routine
(here rmax is not needed but must use the same interface):
int rangeRand(int low, int high, int(*randFn)(),unsigned rmax) {
int span=high-low+1;
return (randFn()) % span+low;
}
Then both 0..255 and 0..3 sets have an even distribution. I'm not
claiming my version is perfect, but here it is performing better than
yours, and it is simpler. I think you might want to review your test
methods.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 16:28 +0100 |
| Message-ID | <qq9ab9$q2$1@news.albasani.net> |
| In reply to | #147903 |
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 15:38 +0000 |
| Message-ID | <u9WxF.192709$Pt2.82727@fx23.am4> |
| In reply to | #147905 |
On 10/11/2019 15:28, 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 > That's absolutely normal with a PRNG, that you won't get an even > distribution. Seriously? You might get a slight bias when the span of values you want doesn't divide evenly into the range of the the rand() function. But in this test, the span is 0..255 or 256, and rand() returns a span of 0..32767 or 32768; there should be no bias. Either this is a deliberate wind-up, or you've haven't got a clue.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 16:58 +0100 |
| Message-ID | <qq9c2e$s3a$1@news.albasani.net> |
| In reply to | #147906 |
> Seriously? You might get a slight bias when the span of values you
> want doesn't divide evenly into the range of the the rand() function.
Yes, the distribution of propabilities of values looks like this:
https://abload.de/image.php?img=prngatjaq.png
This was gained with the following code:
#include <iostream>
#include <vector>
#include <cstdlib>
#include <cmath>
#include <algorithm>
#include <utility>
using namespace std;
vector<size_t> test( int low, int high, int (*randFn)(), unsigned rmax );
int dumbRnd()
{
int const WRAP_AROUND = 32;
static int c = WRAP_AROUND - 1;
if( ++c == WRAP_AROUND )
c = 0;
return c % 4;
}
int main()
{
test( 0, 3, dumbRnd, 3 );
cout << endl;
vector<size_t> prop = move( test( 0, 255, ::rand, RAND_MAX ) );
for( size_t i = 0; i != prop.size(); ++i )
cout << i << " " << prop[i] << endl;
}
int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
{
return low + (int)((uint64_t)randFn() * (unsigned)(high - low) / rmax);
}
vector<size_t> test( int low, int high, int (*randFn)(), unsigned rmax )
{
vector<size_t> distrib;
distrib.resize( high - low + 1, 0 );
for( size_t i = 0; i != 100'000; ++i )
++distrib[rangeRand( low, high, randFn, rmax ) - low];
double avg = 0.0;
for( size_t d : distrib )
avg += d;
avg /= distrib.size();
cout << "average: " << avg << endl;
double stdDev = 0.0;
for( size_t d : distrib )
stdDev += (d - avg) * (d - avg);
stdDev = sqrt( stdDev / distrib.size() );
cout << "standard deviation: " << stdDev << endl;
size_t minDistrib = *min_element( &*distrib.begin(), &*distrib.end() ),
maxDistrib = *max_element( &*distrib.begin(), &*distrib.end() );
vector<size_t> prob;
prob.resize( maxDistrib - minDistrib + 1, 0 );
for( size_t d : distrib )
++prob[d - minDistrib];
return move( prob );
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 16:59 +0100 |
| Message-ID | <qq9c5u$s3a$2@news.albasani.net> |
| In reply to | #147908 |
> Yes, the distribution of propabilities of values looks like this: > https://abload.de/image.php?img=prngatjaq.png That's while the distribution of random-value-propabilites is determined by the Erdős–Kac theorem: https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93Kac_theorem
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 16:24 +0000 |
| Message-ID | <SQWxF.149969$Yl3.89199@fx24.am4> |
| In reply to | #147909 |
On 10/11/2019 15:59, Bonita Montero wrote: >> Yes, the distribution of propabilities of values looks like this: >> https://abload.de/image.php?img=prngatjaq.png > > That's while the distribution of random-value-propabilites > is determined by the Erdős–Kac theorem: > https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93Kac_theorem I'm sorry, but I think you're trolling. If you're not, then just admit your function was wrong, because it was.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 17:37 +0100 |
| Message-ID | <qq9ecc$ltm$1@news.albasani.net> |
| In reply to | #147910 |
>>> Yes, the distribution of propabilities of values looks like this: >>> https://abload.de/image.php?img=prngatjaq.png >> That's while the distribution of random-value-propabilites >> is determined by the Erdős–Kac theorem: >> https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93Kac_theorem > I'm sorry, but I think you're trolling. If you're not, then just admit > your function was wrong, because it was. I don't even understand why there's a necessity to test the code. The only issue with "my" code or more córrectly with the idea I copied is, that with high - low > RAND_MAX, there might be gaps and with high - low < RAND_MAX you get not a standard-deviation of zero with your linear-input "random"-number-generator.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-10 17:22 +0000 |
| Message-ID | <875zjr3au2.fsf@bsb.me.uk> |
| In reply to | #147912 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>>>> Yes, the distribution of propabilities of values looks like this:
>>>> https://abload.de/image.php?img=prngatjaq.png
>
>>> That's while the distribution of random-value-propabilites
>>> is determined by the Erdős–Kac theorem:
>>> https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93Kac_theorem
>
>> I'm sorry, but I think you're trolling. If you're not, then just
>> admit your function was wrong, because it was.
>
> I don't even understand why there's a necessity to test the code.
Oh dear. I testing it like this:
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
int randIt( int low, int high )
{
return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
}
int main(void)
{
unsigned long long n = 0;
while (!randIt(0, 1)) n += 1;
printf("Got one at last!\nIt took %llu calls.\n", n);
}
After running for quite some time I get:
$ ./rr
Got one at last!
It took 3603152183 calls.
This is why I first thought returning high was a bug, but it seems you
intended it and just got the frequency wrong by nine orders of
magnitude. (No, I don't believe that.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-11-10 18:04 +0000 |
| Message-ID | <1jYxF.248302$LT2.22442@fx21.am4> |
| In reply to | #147915 |
On 10/11/2019 17:22, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>>>>> Yes, the distribution of propabilities of values looks like this:
>>>>> https://abload.de/image.php?img=prngatjaq.png
>>
>>>> That's while the distribution of random-value-propabilites
>>>> is determined by the Erdős–Kac theorem:
>>>> https://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93Kac_theorem
>>
>>> I'm sorry, but I think you're trolling. If you're not, then just
>>> admit your function was wrong, because it was.
>>
>> I don't even understand why there's a necessity to test the code.
> Oh dear. I testing it like this:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <stdint.h>
>
> int randIt( int low, int high )
> {
> return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
> }
>
> int main(void)
> {
> unsigned long long n = 0;
> while (!randIt(0, 1)) n += 1;
> printf("Got one at last!\nIt took %llu calls.\n", n);
> }
>
> After running for quite some time I get:
>
> $ ./rr
> Got one at last!
> It took 3603152183 calls.
38723 calls on Windows (RAND_MAX=32767). With a dummy rand function like
this:
int myrand(void) {static int r; return (++r & 15);}
and using 15 for RAND_MAX, it took only 14 calls.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 19:10 +0100 |
| Message-ID | <qq9jqb$8n8$1@news.albasani.net> |
| In reply to | #147915 |
If you don't want it the way DFS intended take this:
int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
{
double const NEARLY_ONE = 1.0 - FLT_EPSILON;
return low + (int)(randFn() * ((double)high - (double)low +
NEARLY_ONE) / rmax);
}
If the FPU is set to chop this will gain an almost perfect distribution
if high - low is rmax.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-10 19:14 +0100 |
| Message-ID | <qq9k24$6se$1@news.albasani.net> |
| In reply to | #147920 |
Am 10.11.2019 um 19:10 schrieb Bonita Montero:
> If you don't want it the way DFS intended take this:
>
> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> {
> double const NEARLY_ONE = 1.0 - FLT_EPSILON;
> return low + (int)(randFn() * ((double)high - (double)low +
> NEARLY_ONE) / rmax);
> }
>
> If the FPU is set to chop this will gain an almost perfect distribution
> if high - low is rmax.
Sorry, NEARLY_ONE should be better:
double const NEARLY_ONE = 1.0 - DBL_EPSILON;
^^^
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-11 02:14 +0000 |
| Message-ID | <87bltj17n8.fsf@bsb.me.uk> |
| In reply to | #147921 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
> Am 10.11.2019 um 19:10 schrieb Bonita Montero:
>> If you don't want it the way DFS intended
The point is that /you/ wanted it the way DFS intended, but you
"corrected" DFS's code by making it wrong.
>> take this:
>>
>> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
>> {
>> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
(as per your correction)
>> return low + (int)(randFn() * ((double)high - (double)low + NEARLY_ONE) / rmax);
>> }
No, this is not what DFS intended either. In many ways it's worse than
you last version. This one sometimes has undefined behaviour at the
cast to int. In practice, with gcc on Linux, I see
rangeRand(0, RAND_MAX, rand, RAND_MAX) == -2147483648
Undefined behaviour permits this, of course.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | DFS <nospam@dfs.com> |
|---|---|
| Date | 2019-11-10 22:07 -0500 |
| Message-ID | <kf4yF.107827$FF4.41759@fx40.iad> |
| In reply to | #147932 |
On 11/10/2019 9:14 PM, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> Am 10.11.2019 um 19:10 schrieb Bonita Montero:
>>> If you don't want it the way DFS intended
>
> The point is that /you/ wanted it the way DFS intended, but you
> "corrected" DFS's code by making it wrong.
Everyone wants the same thing: uniform distribution of random ints in
[lo,hi].
My version came from, probably, a stranger on stack overflow.
I tested it on Linux:
$ ./testdist 100000000 (100M)
Linux rand()
01|8337199
02|8335084
03|8324217
04|8334279
05|8334330
06|8333440
07|8332581
08|8337881
09|8333939
10|8334184
11|8334697
12|8328169
The distribution /looked/ fine so I went with it.
======================================================
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int randInt(int low, int high) {
return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
}
int main(int argc, char *argv[]) {
int i=0,n=0;
int loops=atoi(argv[1]);
int countarr[12]={0};
srand(time(NULL));
for(i = 0; i < loops; ++i) {
n=getrandom(1,12);
countarr[n-1]++;
}
printf("\nLinux rand()\n");
for(i = 0; i < 12; ++i) {
printf("%02d|%d\n",i+1,countarr[i]);
}
return 0;
}
======================================================
>>> take this:
>>>
>>> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
>>> {
>>> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
> (as per your correction)
>>> return low + (int)(randFn() * ((double)high - (double)low + NEARLY_ONE) / rmax);
>>> }
>
> No, this is not what DFS intended either. In many ways it's worse than
> you last version. This one sometimes has undefined behaviour at the
> cast to int. In practice, with gcc on Linux, I see
>
> rangeRand(0, RAND_MAX, rand, RAND_MAX) == -2147483648
>
> Undefined behaviour permits this, of course.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-11 22:16 +0000 |
| Message-ID | <871rue12kn.fsf@bsb.me.uk> |
| In reply to | #147934 |
DFS <nospam@dfs.com> writes:
> On 11/10/2019 9:14 PM, Ben Bacarisse wrote:
>> Bonita Montero <Bonita.Montero@gmail.com> writes:
>>
>>> Am 10.11.2019 um 19:10 schrieb Bonita Montero:
>>>> If you don't want it the way DFS intended
>>
>> The point is that /you/ wanted it the way DFS intended, but you
>> "corrected" DFS's code by making it wrong.
>
> Everyone wants the same thing: uniform distribution of random ints in
> [lo,hi].
Yes, though BM /claims/ you wanted what the "corrected" code does, but
you don't.
> My version came from, probably, a stranger on stack overflow.
>
> I tested it on Linux:
>
> $ ./testdist 100000000 (100M)
>
> Linux rand()
> 01|8337199
> 02|8335084
> 03|8324217
> 04|8334279
> 05|8334330
> 06|8333440
> 07|8332581
> 08|8337881
> 09|8333939
> 10|8334184
> 11|8334697
> 12|8328169
>
> The distribution /looked/ fine so I went with it.
>
> ======================================================
> #include <stdio.h>
> #include <stdlib.h>
> #include <time.h>
>
> int randInt(int low, int high) {
> return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> }
This is a perfectly good way to do it provided you understand the
problems and trade-offs that go with it.
Functions of this sort will always have a bias when the range does not
divide RAND_MAX+1. When the range is very much less than RAND_MAX+1 (as
in your test case where RAND_MAX == INT_MAX), that bias will be all but
invisible.
If you don't mind that bias (and for a lot of programs it's immaterial)
the simplest way to get a number in range is probably to do this:
return low + rand() % (1u + high - low);
I say "probably" because code like this fell out of fashion due to there
being a large number of bad rand() implementations out there. Using %
will expose and pattern present in the low-order bits returned by
rand(), but with a good rand() function, the % method is as good as the
divide method.
There is a second, more extreme, form of bias that happens when the
range requested is greater than RAND_MAX+1. In this case, you would
either have to report an error or call rand() more than once to
construct the result. If you don't, any simple function will not return
some numbers in the range at all, whilst returning others too often.
A final problem is that, in your function, the arithmetic can overflow.
Whether you think this is a problem is up to you. Lots of C programs
have code that /can/ overflow, but the way that code is used ensures
that it never does, or it's not considered a problem because the
implementation can be relied on to "do the right thing".
Tim's posted code deals with all of these issues at the expense of some
more work.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-11 06:52 +0100 |
| Message-ID | <qqasum$vua$1@news.albasani.net> |
| In reply to | #147932 |
> No, this is not what DFS intended either. ... Nonsense, this is want DFS intenderd. > No, this is not what DFS intended either. In many ways it's worse than > you last version. This one sometimes has undefined behaviour at the > cast to int. In practice, with gcc on Linux, I see > rangeRand(0, RAND_MAX, rand, RAND_MAX) == -2147483648 > Undefined behaviour permits this, of course. Of coursse you must set high and low appropriately, i.e. high must be >= low.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-11 10:33 -0800 |
| Message-ID | <9f02cf3d-088c-40e7-baf1-d3296d14aac9@googlegroups.com> |
| In reply to | #147935 |
On Monday, November 11, 2019 at 12:52:31 AM UTC-5, Bonita Montero wrote: > > No, this is not what DFS intended either. ... > > Nonsense, this is want DFS intenderd. DFS intended to for the function to return a value of 'high' only one time out of (RAND_MAX+1) calls, on average, a much lower probability than any number in the range [low, high)? That seems a very odd thing to want. Do you have any idea why he would want it? > > No, this is not what DFS intended either. In many ways it's worse than > > you last version. This one sometimes has undefined behaviour at the > > cast to int. In practice, with gcc on Linux, I see > > rangeRand(0, RAND_MAX, rand, RAND_MAX) == -2147483648 > > Undefined behaviour permits this, of course. > > Of coursse you must set high and low appropriately, > i.e. high must be >= low. That call sets low to 0, and high to RAND_MAX. The minimum permitted value for RAND_MAX is 32767, so it would appear that high >= low is satisfied. What are you talking about?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-11 23:28 +0000 |
| Message-ID | <87v9rqyout.fsf@bsb.me.uk> |
| In reply to | #147935 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >> No, this is not what DFS intended either. ... > > Nonsense, this is want DFS intenderd. Unsurprisingly, DFS disagrees. I quote: "Everyone wants the same thing: uniform distribution of random ints in [lo,hi]." Obviously you have backed yourself into a corner and can't now admit you wrote some junk code, but no one else thinks your original "correction" returns "a uniform distribution of random ints in [lo,hi]". And the code I was commenting on doesn't either. >> No, this is not what DFS intended either. In many ways it's worse than >> you last version. This one sometimes has undefined behaviour at the >> cast to int. In practice, with gcc on Linux, I see >> rangeRand(0, RAND_MAX, rand, RAND_MAX) == -2147483648 >> Undefined behaviour permits this, of course. > > Of coursse you must set high and low appropriately, > i.e. high must be >= low. Despite having written is, you don't see to know what the code I was commenting on does. And of course high was >= low in the call I showed. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web