Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #147715 > unrolled thread

mergesort code segfaulting on smallish arrays

Back to article view | Back to comp.lang.c

Contents

  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 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11  Next page →

#148244

> Suppose you were designing a language and needed to choose between 
> generating either C or C++ source code; which would you go for?

You have to be much more skilled to develop in C++, but if you can
handle the language you're much more productive and the code is cleaner.

> Just a note: your 270-line C++ program took 3.4 seconds to compile on
> my machine (fastest time; slowest was 7 seconds. O0/O3 were about the 
> same).

Without linking and cached headers I get 850ms time on my Ryzen 7
1800X. On Windows it takes 677ms.

> Which is 80 lines per second. I'm more used to C compilers which  are several thousand times faster (eg. 'tcc' and 'bcc').

Template-classes have a lot of source. But they save a lot of work;
that's worth larger compile-times. And C++20 will have modules, where
the classes will be pre-compile.

>> It's obviously a better language.

> That's not so obvious. What is obvious is that it is considerably were 
> complex, more arcane, much slower to compile and generally more cumbersome.

But you get a more cleaner and more robust code.

> There are issues with C's lack of standard libraries for some of the 
> things you listed, but that is just how it works. The regulars here like 
> to call that 'flexibility' As target language for another, you want it 
> as lightweight as possible.

C should be replaced. C has the lowest level of language-capabilites
which results in much work when programming in C.

[toc] | [prev] | [next] | [standalone]

#148248

On 11/13/2019 7:01 AM, Bonita Montero wrote:
> Take this; it's the same code but it gathers all the exceptions the
> threads could make in parallel and throws them in a merge_sort<...>
> ::par_exception if more than one exception ocurs or the exception
> that occured natively if there was only one exception.
> The vector for the exception_ptr-objects is pre-allocated to the
> maximum number of threads that could issue an exception so that
> there can't be an exception while catching an exception.
> 
> #include <iostream>
> #include <random>
> #include <limits>
> #include <algorithm>
> #include <cassert>
> #include <iterator>
> #include <cstdlib>
> #include <chrono>
> #include <cstdint>
> #include <thread>
> #include <functional>
> #include <exception>
> #include <mutex>
> 
> template<typename T>
> struct invoke_on_destruct
> {
> private:
>      T    &m_t;
>      bool  m_enabled;
> 
> public:
>      invoke_on_destruct( T &t ) :
>          m_t( t ), m_enabled( true )
>      {
>      }
> 
>      ~invoke_on_destruct()
>      {
>          if( m_enabled )
>              m_t();
>      }
> 
>      void invoke_and_disable()
>      {
>          m_t();
>          m_enabled = false;
>      }
> };
[...]

Basically, ScopeGuard. Very useful for rollbacks.

[toc] | [prev] | [next] | [standalone]

#148249

On 11/13/2019 7:01 AM, Bonita Montero wrote:
> Take this; it's the same code but it gathers all the exceptions the
> threads could make in parallel and throws them in a merge_sort<...>
> ::par_exception if more than one exception ocurs or the exception
> that occured natively if there was only one exception.
> The vector for the exception_ptr-objects is pre-allocated to the
> maximum number of threads that could issue an exception so that
> there can't be an exception while catching an exception.
[...]
Why so many threads! Wow:

assert(nThreads >= 1);
     if (nThreads == 0)
         nThreads = 99999;


wow.

[toc] | [prev] | [next] | [standalone]

#148251

> Why so many threads! Wow:
> 
> assert(nThreads >= 1);
>      if (nThreads == 0)
>          nThreads = 99999;

I've already removed the assert, but I didn't repost ist.
I'd like to see if someone tests the code with and without
BUILTN_PAR. My code takes about 35% less time to sort a
100.000.000 elements int-array than with  ...
    stable_sort( execution::parallel_policy(), ...
My Gnu C++ library version unfortunately hasn't <execution>
so that I can't do the parallel benchmark with BUILTIN_PAR.

Here's the code with some comments.

//#define BUILTIN_PAR
#include <iostream>
#include <random>
#include <limits>
#include <algorithm>
#include <cassert>
#include <iterator>
#include <cstdlib>
#include <chrono>
#include <cstdint>
#include <thread>
#include <functional>
#include <exception>
#include <mutex>
#if defined(BUILTIN_PAR)
     #include <execution>
#endif

template<typename T>
struct invoke_on_destruct
{
private:
     T    &m_t;
     bool  m_enabled;

public:
     invoke_on_destruct( T &t ) :
         m_t( t ), m_enabled( true )
     {
     }

     ~invoke_on_destruct()
     {
         if( m_enabled )
             m_t();
     }

     void invoke_and_disable()
     {
         m_t();
         m_enabled = false;
     }
};

template<typename It, typename Cmp = std::less<typename 
std::iterator_traits<It>::value_type>>
class merge_sort
{
public:
     merge_sort( It start, It end, Cmp const &cmp = Cmp(), unsigned 
nThreads = 1, std::size_t threadThreshold = 1'000'000 );

     struct par_exception : public std::exception
     {
         using iterator = std::vector<std::exception_ptr>::iterator;
         // there's no copy-constructor because of internal vector
         // so catch par_exception only via reference
                  ~par_exception();
         iterator begin();
         iterator end();
     private:
         friend class merge_sort;
         par_exception( std::vector<std::exception_ptr> &&exceptions );
         std::vector<std::exception_ptr> m_exceptions;
     };

private:
     using exceptions_vector = std::vector<std::exception_ptr>;
     Cmp               m_cmp;
     // threshold where sorts are partitioned in threads
     std::size_t       m_threadThreshold;
     // mutex that protects the exception-array
     std::mutex        m_excMtx;
     exceptions_vector m_exceptions;
     template<typename UpIt, typename BufIt>
     void recursion( UpIt start, UpIt end, BufIt buf );
     template<typename UpIt, typename BufIt>
     void merge( UpIt start, BufIt leftBuf, BufIt rightBuf, BufIt bufEnd );
     template<typename UpIt>
     void parRecursion( UpIt start, UpIt end, unsigned nThreads );
};

template<typename It, typename Cmp>
inline
merge_sort<It, Cmp>::merge_sort( It start, It end, Cmp const &cmp, 
unsigned nThreads, std::size_t threadThreshold ) :
     m_cmp( cmp )
{
     m_threadThreshold = threadThreshold;
     using namespace std;
     // threads == 0 -> number of threads = hardware-threads
     if( nThreads == 0 )
         nThreads = 99999;
     unsigned hwThreads = thread::hardware_concurrency();
     hwThreads += hwThreads == 0;
     nThreads   = nThreads <= hwThreads ? nThreads : hwThreads;
     // reserve number of threads elements in the exception_ptr-vector
     // so that there will be no exception when we do emplace_back
     m_exceptions.reserve( nThreads );
     try
     {
         parRecursion( start, end, nThreads );
         if( m_exceptions.size() )
             if( m_exceptions.size() > 1 )
                 // multiple exceptions from threads: throw par_exception
                 throw par_exception( move( m_exceptions ) );
             else
                 // only one exception from threads: rethrow it
                 rethrow_exception( m_exceptions[0] );
     }
     catch( ... )
     {
         if( m_exceptions.size() )
         {
             // additional exception catched: throw par_exception
             m_exceptions.emplace_back( current_exception() );
             throw par_exception( move( m_exceptions ) );
         }
         else
             // single exception: rethrow it
             throw;
     }
}

template<typename It, typename Cmp>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp>::recursion( UpIt start, UpIt end, BufIt buf )
{
     using namespace std;
     if( end - start <= 1 )
         return;
     copy( start, end, buf );
     size_t n          = end - start;
     BufIt  leftBuf    = buf,
            leftBufEnd = buf + n / 2,
            rightBuf   = leftBufEnd,
            bufEnd     = buf + n;
     recursion( leftBuf,  leftBufEnd, bufEnd );
     recursion( rightBuf, bufEnd,     bufEnd );
     merge( start, leftBuf, rightBuf, bufEnd );
}

template<typename It, typename Cmp>
template<typename UpIt, typename BufIt>
void merge_sort<It, Cmp>::merge( UpIt start, BufIt leftBuf, BufIt 
rightBuf, BufIt bufEnd )
{
     BufIt leftBufEnd = rightBuf;
     for( UpIt wrtBack = start; ; )
         if( m_cmp( *leftBuf, *rightBuf ) )
         {
             *wrtBack++ = *leftBuf;
             if( ++leftBuf == leftBufEnd )
             {
                 // faster for small number of elements than std::copy
                 do
                     *wrtBack++ = *rightBuf;
                 while( ++rightBuf != bufEnd );
                 break;
             }
         }
         else
         {
             *wrtBack++ = *rightBuf;
             if( ++rightBuf == bufEnd )
             {
                 do
                     *wrtBack++ = *leftBuf;
                 while( ++leftBuf != leftBufEnd );
                 break;
             }
         }
}

template<typename It, typename Cmp>
template<typename UpIt>
void merge_sort<It, Cmp>::parRecursion( UpIt start, UpIt end, unsigned 
nThreads )
{
     using namespace std;
     using T = typename iterator_traits<It>::value_type;
     size_t n = end - start;
     if( nThreads <= 1 || n < m_threadThreshold )
     {
         vector<T> buf;
         size_t bs = 0;
         // calculate buffer-/stack-size
         for( size_t split = end - start; split > 1; bs += split, split 
-= split / 2 );
         buf.resize( bs );
         recursion( start, end, buf.begin() );
     }
     else
     {
         // split-buffer
         vector<T> buf;
         buf.resize( n );
         copy( start, end, buf.begin() );
         vector<thread> threads;
         // reserve threads-vector to not reallocate twice
         threads.reserve( 2 );
         // automatically join threads when an exception is thrown
         auto joinThreads = [&threads]()
         {
             for( thread &thr : threads )
                 // try to join infinitely because the thread will
                 // continue to access our buffer and a thread-object
                 // might not be left unjoined at destruction
                 for( ; ; )
                     try
                     {
                         thr.join();
                         break;
                     }
                     catch( ... )
                     {
                     }
         };
         invoke_on_destruct<decltype(joinThreads)> iodJoin( joinThreads );
         // iterator-type for our split-buffer
         using BufIt = typename vector<T>::iterator;
         // proxy thread-lambda for our new threads
         auto prProxy = [this]( BufIt start, BufIt end, unsigned nThreads )
         {
             try
             {
                 parRecursion( start, end, nThreads );
             }
             catch( ... )
             {
                 // remember exception in our exception-array
                 unique_lock<mutex> excLock( m_excMtx );
                 m_exceptions.emplace_back( current_exception() );
             }
         };
         unsigned rightThreads = nThreads / 2,
                  leftThreads  = nThreads - rightThreads;
         // if the left number of threads is uneven give the threads 
more input
         size_t   left         = (size_t)(n * ((double)leftThreads / 
nThreads)),
                  right        = n - left;
         BufIt    leftBuf      = buf.begin(),
                  leftBufEnd   = buf.begin() + left,
                  rightBuf     = leftBufEnd,
                  bufEnd       = buf.begin() + n;
         // start left thread
         threads.emplace_back( prProxy, leftBuf, leftBufEnd, leftThreads );
         if( rightThreads > 1 )
             // start right thread
             threads.emplace_back( prProxy, rightBuf, bufEnd, 
rightThreads );
         else
             // there's only one thread right, so we do it on our own
             parRecursion( rightBuf, bufEnd, 1 );
         // join threads
         iodJoin.invoke_and_disable();
         // if there are any exceptions from the thread: stop
         unique_lock<mutex> excLock( m_excMtx );
         if( m_exceptions.size() )
             return;
         excLock.unlock();
         // merge split-buffer back into input-buffer
         merge( start, leftBuf, rightBuf, bufEnd );
     }
}

template<typename It, typename Cmp>
inline
merge_sort<It, Cmp>::par_exception::~par_exception()
{
}

template<typename It, typename Cmp>
inline
merge_sort<It, Cmp>::par_exception::par_exception( 
std::vector<std::exception_ptr> &&exceptions ) :
     m_exceptions( std::move( exceptions ) )
{
}

template<typename It, typename Cmp>
inline
typename merge_sort<It, Cmp>::par_exception::iterator merge_sort<It, 
Cmp>::par_exception::begin()
{
     return m_exceptions.begin();
}

template<typename It, typename Cmp>
inline
typename merge_sort<It, Cmp>::par_exception::iterator merge_sort<It, 
Cmp>::par_exception::end()
{
     return m_exceptions.begin();
}

#if defined(_MSC_VER)
     #pragma warning(disable: 26444)
#endif

using namespace std;
using namespace chrono;

int main( int argc, char **argv )
{
     if( argc < 2 )
         return EXIT_FAILURE;
     size_t                        n = (size_t)(unsigned)atoi( argv[1]) 
* 1'000'000;
     random_device                 rd;
     uniform_int_distribution<int> uid( numeric_limits<int>::min(), 
numeric_limits<int>::max() );
     vector<int>                   rv;
     rv.resize( n );
     cout << "randomizing ..." << endl;
     for( int &r : rv )
         r = uid( rd );
     cout << "sorting ..." << endl;
     time_point<high_resolution_clock> start = high_resolution_clock::now();
#if defined(BUILTIN_PAR)
     stable_sort( execution::parallel_policy(), rv.begin(), rv.end(), 
less<int>() );
#else
     using msInt = merge_sort<vector<int>::iterator>;
     msInt( rv.begin(), rv.end(), less<int>(), 0 );
#endif
     double seconds = (double)duration_cast<nanoseconds>( 
high_resolution_clock::now() - start ).count() / 1.0E9;
     cout << "... sorted!" << endl;
     cout << "sorting-time: " << seconds << " seconds" << endl;
     for( vector<int>::iterator scn = rv.begin(); scn < rv.end() - 1; 
++scn )
         assert(scn[0] <= scn[1]);
     return EXIT_SUCCESS;
}

[toc] | [prev] | [next] | [standalone]

#148255

> template<typename It, typename Cmp>
> inline
> typename merge_sort<It, Cmp>::par_exception::iterator merge_sort<It, 
> Cmp>::par_exception::end()
> {
>      return m_exceptions.begin();

Copy-mistake; should be ...
        return m_exceptions.end();
But the code isn't used anyway.
> }

[toc] | [prev] | [next] | [standalone]

#148257

On 11/14/2019 12:16 AM, Bonita Montero wrote:
>> Why so many threads! Wow:
>>
>> assert(nThreads >= 1);
>>      if (nThreads == 0)
>>          nThreads = 99999;
> 
> I've already removed the assert, but I didn't repost ist.
> I'd like to see if someone tests the code with and without
> BUILTN_PAR. My code takes about 35% less time to sort a
> 100.000.000 elements int-array than with  ...
>     stable_sort( execution::parallel_policy(), ...
> My Gnu C++ library version unfortunately hasn't <execution>
> so that I can't do the parallel benchmark with BUILTIN_PAR.



$ g++ -Wall -o BMPAR.exe Bonita_Montero_mergesort_BUILTINPAR.cpp
Bonita_Montero_mergesort_BUILTINPAR.cpp: In constructor ‘merge_sort<It, 
Cmp>::merge_sort(It, It, const Cmp&, unsigned int, std::size_t)’:
Bonita_Montero_mergesort_BUILTINPAR.cpp:100:11: warning: suggest 
explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
   100 |         if( m_exceptions.size() )
       |           ^
Bonita_Montero_mergesort_BUILTINPAR.cpp: In function ‘int main(int, 
char**)’:
Bonita_Montero_mergesort_BUILTINPAR.cpp:308:18: error: ‘execution’ has 
not been declared
   308 |     stable_sort( execution::parallel_policy(), rv.begin(), 
rv.end(), less<int>() );
       |                  ^~~~~~~~~

[toc] | [prev] | [next] | [standalone]

#148263

> $ g++ -Wall -o BMPAR.exe Bonita_Montero_mergesort_BUILTINPAR.cpp
> Bonita_Montero_mergesort_BUILTINPAR.cpp: In constructor ‘merge_sort<It, 
> Cmp>::merge_sort(It, It, const Cmp&, unsigned int, std::size_t)’:
> Bonita_Montero_mergesort_BUILTINPAR.cpp:100:11: warning: suggest 
> explicit braces to avoid ambiguous ‘else’ [-Wdangling-else]
>    100 |         if( m_exceptions.size() )
>        |           ^

The else is placed correctly. Forget -Wall, it's stupid.

> Bonita_Montero_mergesort_BUILTINPAR.cpp: In function ‘int main(int, 
> char**)’:
> Bonita_Montero_mergesort_BUILTINPAR.cpp:308:18: error: ‘execution’ has 
> not been declared
>    308 |     stable_sort( execution::parallel_policy(), rv.begin(), 
> rv.end(), less<int>() );
>        |                  ^~~~~~~~~

You don't have a / C++-library that supports C++17.

[toc] | [prev] | [next] | [standalone]

#148254

> Why so many threads! Wow:
> ...
>      if (nThreads == 0)
>          nThreads = 99999;

Guess why!

[toc] | [prev] | [next] | [standalone]

#148256

On 11/13/2019 9:42 PM, Bonita Montero wrote:
>> Why so many threads! Wow:
>> ...
>>      if (nThreads == 0)
>>          nThreads = 99999;
> 
> Guess why!

Not sure. To floor things? ;^)

[toc] | [prev] | [next] | [standalone]

#148262

>>> Why so many threads! Wow:
>>> ...
>>>      if (nThreads == 0)
>>>          nThreads = 99999;

>> Guess why!

> Not sure. To floor things? ;^)

Check the code.
nThreads will be limited to the number of threads in the system.

[toc] | [prev] | [next] | [standalone]

#148252

>> Take this; it's the same code but it gathers all the exceptions the
>> threads could make in parallel and throws them in a merge_sort<...>
>> ::par_exception if more than one exception ocurs or the exception
>> that occured natively if there was only one exception.
>> The vector for the exception_ptr-objects is pre-allocated to the
>> maximum number of threads that could issue an exception so that
>> there can't be an exception while catching an exception.
> [...]

> The following assert always trips:
> assert(nThreads >= 1);

The whole assert doesn't make sense anymore. I changed the
code to accept 0 for the value of maximum number of threads.

[toc] | [prev] | [next] | [standalone]

#148253

On 11/13/2019 7:01 AM, Bonita Montero wrote:
> Take this; it's the same code but it gathers all the exceptions the
> threads could make in parallel and throws them in a merge_sort<...>
> ::par_exception if more than one exception ocurs or the exception
> that occured natively if there was only one exception.
> The vector for the exception_ptr-objects is pre-allocated to the
> maximum number of threads that could issue an exception so that
> there can't be an exception while catching an exception.
[...]
The following assert always trips:

assert(nThreads >= 1);

[toc] | [prev] | [next] | [standalone]

#147765

> //get random number from within range
> int randInt(int low, int high) {
>      return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> }

Better use this:

int randIt( int low, int high )
{
     return low + (int)((uint64_t)rand() * (unsigned)(high - low) / 
RAND_MAX);
}

Your implementation is shit.

[toc] | [prev] | [next] | [standalone]

#147766

On Friday, 8 November 2019 13:34:12 UTC, Bonita Montero  wrote:
> > //get random number from within range
> > int randInt(int low, int high) {
> >      return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> > }
> 
> Better use this:
> 
> int randIt( int low, int high )
> {
>      return low + (int)((uint64_t)rand() * (unsigned)(high - low) / 
> RAND_MAX);
> }
> 
> Your implementation is shit.
>
I think you're missing a bracket there.

But if raw random numbers are evenly distributed over 0-RAND_MAX,
you can't get a uniform distribution that is not a multiple of RAND_MAX +1
with guaranteed only one call. To avoid making an excessive number
of calls, take the limit as (RAND_MAX + 1)/N * N, where N is your
interval size, then call again if the result is over the limit. 
Otherwise take the modulus N to get it within the interval.

If the low value isn't 0, add it at the last step, as you've done.

[toc] | [prev] | [next] | [standalone]

#147767

>>> //get random number from within range
>>> int randInt(int low, int high) {
>>>       return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
>>> }
>> Better use this:
>>
>> int randIt( int low, int high )
>> {
>>       return low + (int)((uint64_t)rand() * (unsigned)(high - low) /
>> RAND_MAX);
>> }
>> Your implementation is shit.

> I think you're missing a bracket there.

> But if raw random numbers are evenly distributed over 0-RAND_MAX,
> you can't get a uniform distribution that is not a multiple of RAND_MAX +1

I get values in the range low ... high from the above code. Exactly what
it shoul do. Although the code is somewhat stupid because if high - low
is > RAND_MAX, there mighe be gaps. And the distribution wouldn't be
uniform when high - low is < RAND_MAX. C++'s random-number-faciltiy is
simply much more sophisticated.

[toc] | [prev] | [next] | [standalone]

#147769

>>>> //get random number from within range
>>>> int randInt(int low, int high) {
>>>>       return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
>>>> }
>>> Better use this:
>>>
>>> int randIt( int low, int high )
>>> {
>>>       return low + (int)((uint64_t)rand() * (unsigned)(high - low) /
>>> RAND_MAX);
>>> }
>>> Your implementation is shit.

>> I think you're missing a bracket there.

>> But if raw random numbers are evenly distributed over 0-RAND_MAX,
>> you can't get a uniform distribution that is not a multiple of 
>> RAND_MAX +1

> I get values in the range low ... high from the above code. Exactly what
> it shoul do. Although the code is somewhat stupid because if high - low
> is > RAND_MAX, there mighe be gaps. And the distribution wouldn't be
> uniform when high - low is < RAND_MAX. C++'s random-number-faciltiy is
> simply much more sophisticated.

This would be the C++-code:

int randIt( int low, int high )
{
     static thread_local random_device rd;
     uniform_int_distribution<int>     uid( low, high );
     return uid( rd );
}

[toc] | [prev] | [next] | [standalone]

#147778

On Friday, 8 November 2019 14:01:14 UTC, Bonita Montero  wrote:
> >>>> //get random number from within range
> >>>> int randInt(int low, int high) {
> >>>>       return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
> >>>> }
> >>> Better use this:
> >>>
> >>> int randIt( int low, int high )
> >>> {
> >>>       return low + (int)((uint64_t)rand() * (unsigned)(high - low) /
> >>> RAND_MAX);
> >>> }
> >>> Your implementation is shit.
> 
> >> I think you're missing a bracket there.
> 
> >> But if raw random numbers are evenly distributed over 0-RAND_MAX,
> >> you can't get a uniform distribution that is not a multiple of 
> >> RAND_MAX +1
> 
> > I get values in the range low ... high from the above code. Exactly what
> > it shoul do. Although the code is somewhat stupid because if high - low
> > is > RAND_MAX, there mighe be gaps. And the distribution wouldn't be
> > uniform when high - low is < RAND_MAX. C++'s random-number-faciltiy is
> > simply much more sophisticated.
> 
> This would be the C++-code:
> 
> int randIt( int low, int high )
> {
>      static thread_local random_device rd;
>      uniform_int_distribution<int>     uid( low, high );
>      return uid( rd );
> }
>
Hardly intuitive, is it?

But C++ does have a richer library of random number generators than C,
as standard.

[toc] | [prev] | [next] | [standalone]

#147780

> Hardly intuitive, is it?

I think both the C and the C++-solution are easy to understand.

[toc] | [prev] | [next] | [standalone]

#147782

On 08/11/2019 16:00, Malcolm McLean wrote:
> On Friday, 8 November 2019 14:01:14 UTC, Bonita Montero  wrote:
>>>>>> //get random number from within range
>>>>>> int randInt(int low, int high) {
>>>>>>        return (low + rand() / (RAND_MAX / (high - low + 1) + 1));
>>>>>> }
>>>>> Better use this:
>>>>>
>>>>> int randIt( int low, int high )
>>>>> {
>>>>>        return low + (int)((uint64_t)rand() * (unsigned)(high - low) /
>>>>> RAND_MAX);
>>>>> }
>>>>> Your implementation is shit.
>>
>>>> I think you're missing a bracket there.
>>
>>>> But if raw random numbers are evenly distributed over 0-RAND_MAX,
>>>> you can't get a uniform distribution that is not a multiple of
>>>> RAND_MAX +1
>>
>>> I get values in the range low ... high from the above code. Exactly what
>>> it shoul do. Although the code is somewhat stupid because if high - low
>>> is > RAND_MAX, there mighe be gaps. And the distribution wouldn't be
>>> uniform when high - low is < RAND_MAX. C++'s random-number-faciltiy is
>>> simply much more sophisticated.
>>
>> This would be the C++-code:
>>
>> int randIt( int low, int high )
>> {
>>       static thread_local random_device rd;
>>       uniform_int_distribution<int>     uid( low, high );
>>       return uid( rd );
>> }
>>
> Hardly intuitive, is it?
> 
> But C++ does have a richer library of random number generators than C,
> as standard.
> 

The 15-bit rand() you seem to get on Windows is poor. This what I use 
from my library, ported to C and adapted for positive ints to match rand():

--------------------------------------------
uint64_t seed[2] = {0x2989881111111272,0x1673267373358264};

#define MRAND_MAX 0x7FFFFFFF    // keep to 32 bits

void mseed(uint64_t a, uint64_t b) {
// Seed prng with value a; b can be 0, or can be another value

     seed[0] = a;
     if (b) {
         seed[1] = b;
     } else {
         seed[1] ^= a;
     }
}

uint64_t mrandom(void) {
//return pure 64-bit unsigned int value, 0 to +2**64-1
//(cast result for signed or narrower value)
     uint64_t x,y;
     x = seed[0];
     y = seed[1];
     seed[0] = y;
     x ^= (x<<23);
     seed[1] =  x ^ y ^ (x>>17) ^ (y>>26);
     return seed[1] + y;
}

int mrand(void) {
// return random number 0 to 0x7FFFFFFF
     return (int)(mrandom() & 0x7FFFFFFF);
}
--------------------------------------------

(Not my algorithm; I can't remember where it came from. It looks too 
simple to be one of Marsaglia's.)

Use like this:

    mseed(time(NULL),0);

to seed, like DFS's. (In the original, the 2nd parameter is optional, 
but in C you must provide it.)

And call it like this:

    mrand()

just like rand(). The maximum value is MRAND_MAX or 0x7FFFFFFF. (For an 
even wider range more suitable to converting to float, use mrandom() 
which has a maximum value of 0xFFFFFFFFFFFFFFFF.)

[toc] | [prev] | [next] | [standalone]

#147966

On 08/11/2019 16:34, Bart wrote:

> The 15-bit rand() you seem to get on Windows is poor. This what I use 
> from my library, ported to C and adapted for positive ints to match rand():
> 
> --------------------------------------------
> uint64_t seed[2] = {0x2989881111111272,0x1673267373358264};
> 
> #define MRAND_MAX 0x7FFFFFFF    // keep to 32 bits
> 
> void mseed(uint64_t a, uint64_t b) {
> // Seed prng with value a; b can be 0, or can be another value
> 
>      seed[0] = a;
>      if (b) {
>          seed[1] = b;
>      } else {
>          seed[1] ^= a;
>      }
> }
> 
> uint64_t mrandom(void) {
> //return pure 64-bit unsigned int value, 0 to +2**64-1
> //(cast result for signed or narrower value)
>      uint64_t x,y;
>      x = seed[0];
>      y = seed[1];
>      seed[0] = y;
>      x ^= (x<<23);
>      seed[1] =  x ^ y ^ (x>>17) ^ (y>>26);
>      return seed[1] + y;
> }
> 
> int mrand(void) {
> // return random number 0 to 0x7FFFFFFF
>      return (int)(mrandom() & 0x7FFFFFFF);
> }
> --------------------------------------------
> 
> (Not my algorithm; I can't remember where it came from. It looks too 
> simple to be one of Marsaglia's.)

It appears to be based on 'xorshift+', one of the variations described here:

    https://en.wikipedia.org/wiki/Xorshift

I use it with a small family of functions to extract positive signed, 
float and ranged random numbers as shown here:

   https://github.com/sal55/langs/blob/master/random.m

(Not translated to C but easy enough to follow.)

[toc] | [prev] | [next] | [standalone]

Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11  Next page →

Back to top | Article view | comp.lang.c

csiph-web