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 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 10:56 +0100 |
| Message-ID | <qqdvk5$nka$2@news.albasani.net> |
| In reply to | #147946 |
I was only talking about the "overflow"-issue. Actually there's overflow with (unsigned)(high - low) on any machine today.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-11-12 02:35 -0800 |
| Message-ID | <qqe1te$knj$1@gioia.aioe.org> |
| In reply to | #147950 |
On 11/12/2019 1:56 AM, Bonita Montero wrote: > I was only talking about the "overflow"-issue. Actually there's > overflow with (unsigned)(high - low) on any machine today. Are you JG?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-12 15:01 +0000 |
| Message-ID | <87pnhxyw8g.fsf@bsb.me.uk> |
| In reply to | #147950 |
Bonita Montero <Bonita.Montero@gmail.com> writes: > I was only talking about the "overflow"-issue. No you were talking about lots of other things too. Do you want me to remind you of some of the other things you said? And it's not the "overflow" issue, it's the overflow issue. > Actually there's > overflow with (unsigned)(high - low) on any machine today. I'm glad you accept that now, but it's not about the machine, it's about the language. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 16:08 +0100 |
| Message-ID | <qqehu3$b8c$1@news.albasani.net> |
| In reply to | #147953 |
>> Actually there's >> overflow with (unsigned)(high - low) on any machine today. > I'm glad you accept that now, but it's not about the machine, > it's about the language. No, we're talking about reality and not theory.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-11-12 15:53 +0000 |
| Message-ID | <87ftityttj.fsf@bsb.me.uk> |
| In reply to | #147954 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Actually there's >>> overflow with (unsigned)(high - low) on any machine today. > >> I'm glad you accept that now, but it's not about the machine, >> it's about the language. > > No, we're talking about reality and not theory. But you've just said there is overflow on any machine. As you say it' universal. The simplest way to explain that is to say that it's about the language: the overflow occurs in C's "virtual machine". Most real hardware take the undefined behaviour specified by C as permission to what is simplest (wrap). Compilers can also take advantage of the specified undefined behaviour, which is why it can be so dangerous, even when you know what the hardware will do. (I have a feeling you said exactly the opposite of what your meant to say, but since what you said was largely correct it seemed odd to assume you were wrong.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 16:56 +0100 |
| Message-ID | <qqeko5$3cc$1@news.albasani.net> |
| In reply to | #147955 |
>>>> Actually there's >>>> overflow with (unsigned)(high - low) on any machine today. >>> I'm glad you accept that now, but it's not about the machine, >>> it's about the language. >> No, we're talking about reality and not theory. > But you've just said there is overflow on any machine. As you say it' > universal. The simplest way to explain that is to say that it's about > the language: the overflow occurs in C's "virtual machine". Most real > hardware take the undefined behaviour specified by C as permission to > what is simplest (wrap). It works on any modern machine. > Compilers can also take advantage of the specified undefined behaviour, > which is why it can be so dangerous, even when you know what the hardware > will do. What should a compiler do when doing "(unsigned)(high - low)" that helps him to optimize the code and to ruin the expected semantics?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-11 13:45 +0100 |
| Message-ID | <qqbl61$7v7$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.
Just found that most C/C++-implementatins will round on the last bit.
So if you want to have it absolutely correctly, you have to set the
rounding-mode (thereby slowing down the code a bit):
int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
{
double const NEARLY_ONE = 1.0 - DBL_EPSILON;
int rm = fegetround();
fesetround( FE_TOWARDZERO );
int ret = low + (int)(randFn() * ((double)high - low + NEARLY_ONE)
/ rmax);
fesetround( rm );
return ret;
}
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 08:00 -0800 |
| Message-ID | <a8d5226a-836f-47e4-9f48-3308662d840f@googlegroups.com> |
| In reply to | #147938 |
On Monday, November 11, 2019 at 7:46:03 AM UTC-5, Bonita Montero wrote:
> 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.
>
> Just found that most C/C++-implementatins will round on the last bit.
> So if you want to have it absolutely correctly, you have to set the
> rounding-mode (thereby slowing down the code a bit):
>
> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> {
> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
I suspect that the value you actually wanted here was
1.0 - DBL_EPSILON/FLT_RADIX
> int rm = fegetround();
> fesetround( FE_TOWARDZERO );
> int ret = low + (int)(randFn() * ((double)high - low + NEARLY_ONE)
> / rmax);
> fesetround( rm );
> return ret;
> }
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 17:03 +0100 |
| Message-ID | <qqel40$1p6$1@news.albasani.net> |
| In reply to | #147958 |
>> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
>> {
>> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
> I suspect that the value you actually wanted here was
> 1.0 - DBL_EPSILON/FLT_RADIX
No, FLT_EPSILON has the appropriate value.
>> int rm = fegetround();
>> fesetround( FE_TOWARDZERO );
>> int ret = low + (int)(randFn() * ((double)high - low + NEARLY_ONE)
>> / rmax);
>> fesetround( rm );
>> return ret;
>> }
>
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 08:27 -0800 |
| Message-ID | <fd464183-c58c-4710-9105-493ecc6dfbe5@googlegroups.com> |
| In reply to | #147959 |
On Tuesday, November 12, 2019 at 11:03:21 AM UTC-5, Bonita Montero wrote:
> >> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> >> {
> >> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
>
> > I suspect that the value you actually wanted here was
> > 1.0 - DBL_EPSILON/FLT_RADIX
>
> No, FLT_EPSILON has the appropriate value.
Sorry - I'm having some problems with my keyboard, and hit something
that accidentally posted that message when it was almost entirely
incomplete. However, I find your response mystifying. You originally
used FLT_EPSILON, and then later corrected it to DBL_EPSILON; now you're
going back to FLT_EPSILON? FLT_EPSILON is for values of type "float", of
which there are none in your code.
Also, I made an assumption, and I forgot to ask you to confirm or deny
that assumption. Are you trying to compute the largest value that is
representable as a double that is smaller than 1.0? 1.0-FLT_EPSILON is
too small to qualify, and even 1.0-DBL_EPSILON is too small.
nextafter(1.0, 0.0) is larger than either of those values, while still
being smaller than 1.0.
If there's some other way to describe what you were trying to
calculate, could you provide that description?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 17:29 +0100 |
| Message-ID | <qqeml0$unv$2@news.albasani.net> |
| In reply to | #147961 |
>> No, FLT_EPSILON has the appropriate value. > Sorry - I'm having some problems with my keyboard, and hit something > that accidentally posted that message when it was almost entirely > incomplete. However, I find your response mystifying. You originally > used FLT_EPSILON, and then later corrected it to DBL_EPSILON; now you're > going back to FLT_EPSILON? FLT_EPSILON is for values of type "float", of > which there are none in your code. I was just thiking too "fluent". But I was talking about the genral principle and FLT_EPSILON is only quantitatively different.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 08:18 -0800 |
| Message-ID | <cd8bab30-aecf-46da-aba8-fc3c71c437c8@googlegroups.com> |
| In reply to | #147938 |
On Monday, November 11, 2019 at 7:46:03 AM UTC-5, Bonita Montero wrote:
> 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.
>
> Just found that most C/C++-implementatins will round on the last bit.
> So if you want to have it absolutely correctly, you have to set the
> rounding-mode (thereby slowing down the code a bit):
>
> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> {
> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
I suspect that what you actually wanted here was
1.0 - DBL_EPSILON/FLT_RADIX
Representable values are spaced more closely, by a factor of FLT_RADIX,
for values slightly smaller than a power of FLT_RADIX, than they are for
values slightly larger than that power of FLT_RADIX. DBL_EPSILON is the
spacing for values between 1.0 and (double)FLT_RADIX.
In C99 and later, a more direct way to express what you want here is
nextafter(1.0, 0.0).
> int rm = fegetround();
> fesetround( FE_TOWARDZERO );
> int ret = low + (int)(randFn() * ((double)high - low + NEARLY_ONE)
> / rmax);
Note that the cast to double can be avoided by putting NEARLY_ONE at the
beginning of that expression, which would cause the conversion to ocurr
implicitly.
The difference between 1.0 and NEARLY_ONE becomes negligible once you
add (high - low) to it, even if high and low differ by as little as 1.
You end up getting results that depend upon the rounding direction, as
you found out. You'd be better off using
nextafter(1.0+high-low, -DBL_MAX)
Then you wouldn't have to fiddle with the rounding direction.
> fesetround( rm );
> return ret;
> }
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 17:27 +0100 |
| Message-ID | <qqemi7$unv$1@news.albasani.net> |
| In reply to | #147960 |
>> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
>> {
>> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
> I suspect that what you actually wanted here was
> 1.0 - DBL_EPSILON/FLT_RADIX
No, that would be a bug; this would result in 1.0 with any radix.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 08:43 -0800 |
| Message-ID | <c91a7f4d-ee36-4734-9596-619c18f5593b@googlegroups.com> |
| In reply to | #147962 |
On Tuesday, November 12, 2019 at 11:28:01 AM UTC-5, Bonita Montero wrote:
> >> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> >> {
> >> double const NEARLY_ONE = 1.0 - DBL_EPSILON;
> > I suspect that what you actually wanted here was
> > 1.0 - DBL_EPSILON/FLT_RADIX
>
> No, that would be a bug; this would result in 1.0 with any radix.
You should check things out before posting. The following code:
#include <float.h>
#include <math.h>
#include <stdio.h>
int main(void)
{
printf("%g %g %g\n", 1.0-(1.0-DBL_EPSILON),
1.0-(1.0-DBL_EPSILON/FLT_RADIX), 1.0-nextafter(1.0,0.0));
return 0;
}
Gives the following output on my machine:
2.22045e-16 1.11022e-16 1.11022e-16
What results do you get? If you can't figure out why this is not only
permitted, but expected, you might need to adjust your understanding of
floating point formats.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 18:01 +0100 |
| Message-ID | <qqeoh4$qjj$1@news.albasani.net> |
| In reply to | #147964 |
DBL_EPSILON is the smallest number you can add to one. When you subtract it you might be able to divide it by FLT_RADIX, because the exponent will be one lower, but that's not safe. Better leave it as it is.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 09:41 -0800 |
| Message-ID | <87401a06-4e50-4bca-b491-321922887f19@googlegroups.com> |
| In reply to | #147965 |
On Tuesday, November 12, 2019 at 12:01:35 PM UTC-5, Bonita Montero wrote: > DBL_EPSILON is the smallest number you can add to one. When you > subtract it you might be able to divide it by FLT_RADIX, because > the exponent will be one lower, but that's not safe. Better leave > it as it is. Any implementation of C that uses a floating point representation for which the model described in 5.2.4.2.2 p1-2 is reasonably accurate, must provide a <float.h> which #defines DBL_EPSILON and FLT_RADIX to have values for which 1.0-DBL_EPSILON/FLT_RADIX would have the value of the largest representable value that is smaller than 1.0. Now, the C standard gives implementations permission to implement the floating point +, -, *, and / operators so inaccuratly that DBL_MAX - DBL_EPSILON < DBL_EPSILON - DBL_MAX may evaluate to true - but that's a problem with all floating point operations, it's nothing specific to the expression 1.0 - DBL_EPSILON/FLT_RADIX.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 18:44 +0100 |
| Message-ID | <qqer15$iqv$1@news.albasani.net> |
| In reply to | #147968 |
> Any implementation of C that uses a floating point representation for which the model described in 5.2.4.2.2 p1-2 is reasonably accurate, must provide a <float.h> which #defines DBL_EPSILON and FLT_RADIX to have values for which 1.0-DBL_EPSILON/FLT_RADIX would have the value of the largest representable value that is smaller than 1.0. Now, the C standard gives implementations permission to implement the floating point +, -, *, and / operators so inaccuratly that DBL_MAX - DBL_EPSILON < DBL_EPSILON - DBL_MAX may evaluate to true - but that's a problem with all floating point operations, it's nothing specific to the expression 1.0 - DBL_EPSILON/FLT_RADIX. You assume IEEE-754-typical behaviour of floats.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 11:00 -0800 |
| Message-ID | <0ad5ae0b-ea00-494b-987a-7641835a9114@googlegroups.com> |
| In reply to | #147969 |
On Tuesday, November 12, 2019 at 12:44:16 PM UTC-5, Bonita Montero wrote:
> > Any implementation of C that uses a floating point representation for which the model described in 5.2.4.2.2 p1-2 is reasonably accurate, must provide a <float.h> which #defines DBL_EPSILON and FLT_RADIX to have values for which 1.0-DBL_EPSILON/FLT_RADIX would have the value of the largest representable value that is smaller than 1.0. Now, the C standard gives implementations permission to implement the floating point +, -, *, and / operators so inaccuratly that DBL_MAX - DBL_EPSILON < DBL_EPSILON - DBL_MAX may evaluate to true - but that's a problem with all floating point operations, it's nothing specific to the expression 1.0 - DBL_EPSILON/FLT_RADIX.
>
> You assume IEEE-754-typical behaviour of floats.
No, I did not. I was quite explicit about what assumptions I was making:
"the model described in 5.2.4.2.2 p1-2 is reasonably accurate". I'm also
assuming that what the standard mandates about FLT_RADIX and DBL_EPSILON
in 5.2.4.2.2p11 applies. That model does not require IEEE-754, nor is it
identical to IEEE-754. IEEE-754 fits that model, but so do many other
floating point formats.
Let me be specific in terms of that model. In that model, the largest
value that can be represented which is less than 1.0 is the one for
which s = +1, e=0, and f_k is b-1 for all values of k. That value is
+1*b^0*sum(k=1, k=p, f_k * b^-k).
Since b>=1, b^0 is 1. That value differs from 1.0 by b^-p.
5.2.4.2.2p11 requires that FLT_RADIX == b, and that
DBL_EPSILON == b^(1-p). Therefore, DBL_EPSILON/FLT_RADIX == b^-p,
exactly the difference between 1.0 and the largest representable value
that is less than 1.0.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-11-12 20:03 +0100 |
| Message-ID | <qqevm8$7h1$1@news.albasani.net> |
| In reply to | #147971 |
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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-11-12 11:22 -0800 |
| Message-ID | <c23b8423-a270-4abd-b072-fa108d266989@googlegroups.com> |
| In reply to | #147972 |
On Tuesday, November 12, 2019 at 2:03:48 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. It doesn't even guarantee that you can add it to 1.0. It specifies that DBL_EPSILON is "the difference between 1 and the least value greater than 1 that is representable in the given floating point type", but: "The accuracy of the floating-point operations (+, -, *, /) and of the library functions in <math.h> and <complex.h> that return floating-point results is implementation- defined, as is the accuracy of the conversion between floating-point internal representations and string representations performed by the library functions in <stdio.h>, <stdlib.h>, and <wchar.h>. The implementation may state that the accuracy is unknown." (5.2.4.2.2p6). As a result, there's no guarantee that 1.0 + DBL_EPSILON will produce "the least value greater than 1", even though that's what the mathematical value of that expression should be. This is what I was referring to when I said that a fully conforming implementation of C could implement subtraction so inaccurately that DBL_MAX - DBL_EPSILON < DBL_EPSILON - DBL_MAX. If you can only rely upon the C standard, floating point is essentially useless. Only if __STDC_IEC_559__ is pre#defined by the implementation is it guaranteed to be useful (6.10.8.3p1). However, given the rest of what the standard says, it's possible to derive that 1.0 - DBL_EPSILON/FLT_RADIX is guaranteed to have a mathematical value that is "the greatest value less than 1". There's no guarantee, however, that that C expression will have a value that matches the mathematical value.
[toc] | [prev] | [next] | [standalone]
Page 9 of 11 — ← Prev page 1 … 7 8 [9] 10 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web