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

Started byDFS <nospam@dfs.com>
First post2019-11-07 10:39 -0500
Last post2019-11-11 00:56 +0000
Articles 20 on this page of 220 — 19 participants

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


#147967

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-12 18:07 +0100
Message-ID<qqeosc$ovs$1@news.albasani.net>
In reply to#147782
> 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():

I think it's for compatibility with older Win16-versions.

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


#147802

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2019-11-08 23:50 +0000
Message-ID<87mud63p3b.fsf@bsb.me.uk>
In reply to#147765
Bonita Montero <Bonita.Montero@gmail.com> writes:

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

This function has numerous problems.  Two signed operations can
overflow, and you will get entirely unexpected results if RAND_MAX is
INT_MAX on a machine with 64-bit int.

But perhaps the most dangerous is that it can return high.  It will only
do so very, very rarely (when rand() returns RAND_MAX), but unless you
do very thorough testing this will only happen once, years after the
code is deployed, when the missile in is already in flight!

> Your implementation is shit.

-- 
Ben.

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


#147807

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2019-11-08 19:55 -0800
Message-ID<86o8xlem9f.fsf@linuxsc.com>
In reply to#147802
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>> int randIt( int low, int high )
>> {
>>     return low + (int)((uint64_t)rand() * (unsigned)(high - low) / RAND_MAX);
>> }
>
> This function has numerous problems.  [...]  perhaps the most
> dangerous is that it can return high.  [...]

Isn't it the case that the routine being discussed is supposed to
be able to return the value high?  More specifically, that the
interval of possible values is meant to include both endpoints?
I thought it was.

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


#147828

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-09 17:27 +0100
Message-ID<qq6pdj$d0r$1@news.albasani.net>
In reply to#147807
> Isn't it the case that the routine being discussed is supposed to
> be able to return the value high? ...

Yes, it should. But DFS' implementation is absolutely confused.

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


#147844

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2019-11-09 19:33 +0000
Message-ID<875zjs4zgk.fsf@bsb.me.uk>
In reply to#147828
Bonita Montero <Bonita.Montero@gmail.com> writes:

>> Isn't it the case that the routine being discussed is supposed to
>> be able to return the value high? ...
>
> Yes, it should.

Then the function you posted was wrong because it returns high with the
wrong frequency.

-- 
Ben.

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


#147863

From"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Date2019-11-09 18:05 -0800
Message-ID<qq7r9t$e3u$1@gioia.aioe.org>
In reply to#147844
On 11/9/2019 11:33 AM, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>>> Isn't it the case that the routine being discussed is supposed to
>>> be able to return the value high? ...
>>
>> Yes, it should.
> 
> Then the function you posted was wrong because it returns high with the
> wrong frequency.
> 

Not exactly 100% sure why, but Bonita Montero is reminding me more and 
more of JG from sci.math.

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


#147869

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 05:58 +0100
Message-ID<qq85df$5c7$2@news.albasani.net>
In reply to#147844
>>> Isn't it the case that the routine being discussed is supposed to
>>> be able to return the value high? ...

>> Yes, it should.

> Then the function you posted was wrong because it returns high with the
> wrong frequency.

The distrubution of the numbers isn't absolutely equal because of the
rounding.

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


#147873

FromBart <bc@freeuk.com>
Date2019-11-10 12:39 +0000
Message-ID<SxTxF.243464$NI41.115260@fx12.am4>
In reply to#147869
On 10/11/2019 04:58, Bonita Montero wrote:
>>>> Isn't it the case that the routine being discussed is supposed to
>>>> be able to return the value high? ...
> 
>>> Yes, it should.
> 
>> Then the function you posted was wrong because it returns high with the
>> wrong frequency.
> 
> The distrubution of the numbers isn't absolutely equal because of the
> rounding.
> 
> 

This is your function:

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

If I try an adaption of it with this test where a special mrand() 
function only returns 0..31 in sequence, and I want low=0, high=3:

-----------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

#define M 31

int mrand(void) {
     static int next=0;
     ++next;
     if (next>M) next=0;
     return next;
}

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

int mrand4(void) { return mrand() % 4;}

int main(void) {
     int hist[4]={0,0,0,0};
     int sum=0;

     for (int i=0; i<3200000; ++i) {
         ++hist[randIt(0,3)];
//        ++hist[mrand4()];
     }
     for (int i=0; i<4; ++i) {
         printf("Hist[%d] = %d\n",i,hist[i]);
         sum+=hist[i];
     }

     printf("Total:    %d\n",sum);


}
-----------------------------------------

Then I get these results:

   Hist[0] = 1100000
   Hist[1] = 1000000
   Hist[2] = 1000000
   Hist[3] = 100000
   Total:    3200000

Clearly there's something wrong. If high should never be returned, then 
Hist[3] should be 0. If it is, then it is being returned 1/10th as often 
as it should (and those missing values are offloaded to Hist[0], but 
actually the results are more skewed than it appears).

And this is a simpler requirement where the span requested divides 
evenly into (0..RAND_MAX).

If I instead use the simpler function mrand4 which is hard-coded for 
0..3, it returns:

   Hist[0] = 800000
   Hist[1] = 800000
   Hist[2] = 800000
   Hist[3] = 800000
   Total:    3200000

Now, this bit I haven't yet tested, so not sure how well it will do, but 
if I substitute a function I posted a few days ago that is supposed to 
do the same job:

int randNbr(int low, int high) {
     int span=high-low+1;
     return (rand()) % span+low;   // changed rand() to mrand()
}

then the results of using randNbr(0,3) are:

   Hist[0] = 800000
   Hist[1] = 800000
   Hist[2] = 800000
   Hist[3] = 800000
   Total:    3200000

How about that? (And yes I would have posted any screwed results too).

Now that it's tested with that special mrand, let's try the real one 
(ie. switch to rand() and RAND_MAX). Your function produces:

   Hist[0] = 1065455
   Hist[1] = 1067559
   Hist[2] = 1066889
   Hist[3] = 97
   Total:    3200000

Mine (it doesn't need RAND_MAX) produces:

   Hist[0] = 800017
   Hist[1] = 800271
   Hist[2] = 799794
   Hist[3] = 799918
   Total:    3200000

I'm happier with that than with yours.

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


#147874

FromBart <bc@freeuk.com>
Date2019-11-10 12:48 +0000
Message-ID<zGTxF.23246$3T6.8507@fx05.am4>
In reply to#147873
On 10/11/2019 12:39, Bart wrote:

> Now that it's tested with that special mrand, let's try the real one 
> (ie. switch to rand() and RAND_MAX). Your function produces:
> 
>    Hist[0] = 1065455
>    Hist[1] = 1067559
>    Hist[2] = 1066889
>    Hist[3] = 97
>    Total:    3200000
> 
> Mine (it doesn't need RAND_MAX) produces:
> 
>    Hist[0] = 800017
>    Hist[1] = 800271
>    Hist[2] = 799794
>    Hist[3] = 799918
>    Total:    3200000
> 
> I'm happier with that than with yours.

BTW, if test it with this function from DFS, the one you (BM) described 
as 'shit', it shows:

   Hist[0] = 798312
   Hist[1] = 801048
   Hist[2] = 800295
   Hist[3] = 800345
   Total:    3200000

If I now try instead the odd span 0..5, then your randIt function generates:

   Hist[0] = 798312
   Hist[1] = 801048
   Hist[2] = 800295
   Hist[3] = 800248
   Hist[4] = 97
   Total:    3200000

but DFS's gives:

   Hist[0] = 638467
   Hist[1] = 641144
   Hist[2] = 640064
   Hist[3] = 640551
   Hist[4] = 639774
   Total:    3200000

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


#147879

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 14:38 +0100
Message-ID<qq93ss$hnr$1@news.albasani.net>
In reply to#147873
No, my code is ok:

#include <iostream>
#include <vector>
#include <cstdlib>
#include <cmath>

using namespace std;

void test( int low, int high, int (*randFn)(), unsigned rmax );

int dumbRnd()
{
     int const  WRAP_AROUND = 32;
     static int c           = WRAP_AROUND - 1;
     if( ++c == WRAP_AROUND )
         c = 0;
     return c % 4;
}

int main()
{
     test( 0, 255, ::rand, RAND_MAX );
     cout << endl;
     test( 0, 3, dumbRnd, 3 );
}

int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
{
     return low + (int)((uint64_t)randFn() * (unsigned)(high - low) / rmax);
}

void test( int low, int high, int (*randFn)(), unsigned rmax )
{
     vector<size_t> distrib;
     distrib.resize( high - low + 1, 0 );
     for( size_t i = 0; i != 1'000'000; ++i )
         ++distrib[rangeRand( low, high, randFn, rmax ) - low];
     double avg = 0.0;
     for( size_t &d : distrib )
         avg += d;
     avg /= distrib.size();
     cout << "average: " << avg << endl;
     double stdDev = 0.0;
     for( size_t &d : distrib )
         stdDev += (d - avg) * (d - avg);
     stdDev = sqrt( stdDev / distrib.size() );
     cout << "standard deviation: " << stdDev << endl;
}

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


#147880

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-11-10 13:42 +0000
Message-ID<ftUxF.149965$Yl3.66763@fx24.am4>
In reply to#147879
On 2019-11-10, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> No, my code is ok:
>
> #include <iostream>
> #include <vector>
> #include <cstdlib>
> #include <cmath>
>
> using namespace std;
>
> void test( int low, int high, int (*randFn)(), unsigned rmax );
>
> int dumbRnd()
> {
>      int const  WRAP_AROUND = 32;
>      static int c           = WRAP_AROUND - 1;
>      if( ++c == WRAP_AROUND )
>          c = 0;
>      return c % 4;
> }
>
> int main()
> {
>      test( 0, 255, ::rand, RAND_MAX );
>      cout << endl;
>      test( 0, 3, dumbRnd, 3 );
> }
>
> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> {
>      return low + (int)((uint64_t)randFn() * (unsigned)(high - low) / rmax);
> }
>
> void test( int low, int high, int (*randFn)(), unsigned rmax )
> {
>      vector<size_t> distrib;
>      distrib.resize( high - low + 1, 0 );
>      for( size_t i = 0; i != 1'000'000; ++i )
>          ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>      double avg = 0.0;
>      for( size_t &d : distrib )
>          avg += d;
>      avg /= distrib.size();
>      cout << "average: " << avg << endl;
>      double stdDev = 0.0;
>      for( size_t &d : distrib )

That is stupid. use size_t when variable fits in register.



-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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


#147881

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 14:46 +0100
Message-ID<qq94bo$g07$1@news.albasani.net>
In reply to#147880
>> void test( int low, int high, int (*randFn)(), unsigned rmax )
>> {
>>       vector<size_t> distrib;
>>       distrib.resize( high - low + 1, 0 );
>>       for( size_t i = 0; i != 1'000'000; ++i )
>>           ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>>       double avg = 0.0;
>>       for( size_t &d : distrib )
>>           avg += d;
>>       avg /= distrib.size();
>>       cout << "average: " << avg << endl;
>>       double stdDev = 0.0;
>>       for( size_t &d : distrib )

> That is stupid. use size_t when variable fits in register.

Which variable?
I wanted low, high to adhere to DFS' standards, and rmax should be of
the same width as RAND_MAX. And it's also ok to count rand-frequencies
in size_t variables. So you're again talking stupid things here.

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


#147883

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-11-10 14:04 +0000
Message-ID<qNUxF.27511$9h3.387@fx10.am4>
In reply to#147881
On 2019-11-10, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>> void test( int low, int high, int (*randFn)(), unsigned rmax )
>>> {
>>>       vector<size_t> distrib;
>>>       distrib.resize( high - low + 1, 0 );
>>>       for( size_t i = 0; i != 1'000'000; ++i )
>>>           ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>>>       double avg = 0.0;
>>>       for( size_t &d : distrib )
>>>           avg += d;
>>>       avg /= distrib.size();
>>>       cout << "average: " << avg << endl;
>>>       double stdDev = 0.0;
>>>       for( size_t &d : distrib )
>
>> That is stupid. use size_t when variable fits in register.
>
> Which variable?

d

should be size_t d, taking reference would require dereferencing
pointer in addition to copy value. I mean not that important for particular problem,but you should know.


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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


#147885

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 15:05 +0100
Message-ID<qq95fl$cs8$1@news.albasani.net>
In reply to#147883
>>>> void test( int low, int high, int (*randFn)(), unsigned rmax )
>>>> {
>>>>        vector<size_t> distrib;
>>>>        distrib.resize( high - low + 1, 0 );
>>>>        for( size_t i = 0; i != 1'000'000; ++i )
>>>>            ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>>>>        double avg = 0.0;
>>>>        for( size_t &d : distrib )
>>>>            avg += d;
>>>>        avg /= distrib.size();
>>>>        cout << "average: " << avg << endl;
>>>>        double stdDev = 0.0;
>>>>        for( size_t &d : distrib )

>>> That is stupid. use size_t when variable fits in register.

>> Which variable?

> d

A little mistake that the compiler would optimize away.

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


#147888

FromMelzzzzz <Melzzzzz@zzzzz.com>
Date2019-11-10 14:09 +0000
Message-ID<7SUxF.27512$9h3.19258@fx10.am4>
In reply to#147885
On 2019-11-10, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>>>> void test( int low, int high, int (*randFn)(), unsigned rmax )
>>>>> {
>>>>>        vector<size_t> distrib;
>>>>>        distrib.resize( high - low + 1, 0 );
>>>>>        for( size_t i = 0; i != 1'000'000; ++i )
>>>>>            ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>>>>>        double avg = 0.0;
>>>>>        for( size_t &d : distrib )
>>>>>            avg += d;
>>>>>        avg /= distrib.size();
>>>>>        cout << "average: " << avg << endl;
>>>>>        double stdDev = 0.0;
>>>>>        for( size_t &d : distrib )
>
>>>> That is stupid. use size_t when variable fits in register.
>
>>> Which variable?
>
>> d
>
> A little mistake that the compiler would optimize away.

I think that compiler can't do that in this case.


-- 
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi --  Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi 
bili naoruzani. -- Mladen Gogala

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


#147891

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 15:19 +0100
Message-ID<qq969p$bsr$1@news.albasani.net>
In reply to#147888
>>>>>>         vector<size_t> distrib;
>>>>>>         ...
>>>>>>         double avg = 0.0;
>>>>>>         for( size_t &d : distrib )
>>>>>>             avg += d;

>>>>> That is stupid. use size_t when variable fits in register.

>>>> Which variable?

>>> d

>> A little mistake that the compiler would optimize away.

> I think that compiler can't do that in this case.

LOL, it can:

$LL96@main:
; Line 22
     mov      rcx, QWORD PTR [rdx]
     xorps    xmm0, xmm0
     test     rcx, rcx
     js       SHORT $LN111@main
     cvtsi2sd xmm0, rcx
     jmp      SHORT $LN112@main
$LN111@main:
     mov      rax, rcx
     shr      rax, 1
     and      ecx, 1
     or       rax, rcx
     cvtsi2sd xmm0, rax
     addsd    xmm0, xmm0
$LN112@main:
     addsd    xmm6, xmm0
; Line 21
     add      rdx, 8
     cmp      rdx, r8
     jne      SHORT $LL96@main

The sign-chech is done because there is no load-instruction in the SSE
-FPU that takes a 64 bit unsigned. So the code is a bit elaborate. But
as you can see from the first instruction, d is taken from the pointer
in rdx at the top. This is just an easy job for a compiler.

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


#147886

FromBart <bc@freeuk.com>
Date2019-11-10 14:06 +0000
Message-ID<BPUxF.27733$7z4.27196@fx09.am4>
In reply to#147879
On 10/11/2019 13:38, Bonita Montero wrote:
> No, my code is ok:
> 

> int dumbRnd()
> {
>      int const  WRAP_AROUND = 32;
>      static int c           = WRAP_AROUND - 1;
>      if( ++c == WRAP_AROUND )
>          c = 0;
>      return c % 4;
> }

> int rangeRand( int low, int high, int (*randFn)(), unsigned rmax )
> {
>      return low + (int)((uint64_t)randFn() * (unsigned)(high - low) / 
> rmax);
> }
> 
> void test( int low, int high, int (*randFn)(), unsigned rmax )
> {
>      vector<size_t> distrib;
>      distrib.resize( high - low + 1, 0 );
>      for( size_t i = 0; i != 1'000'000; ++i )
>          ++distrib[rangeRand( low, high, randFn, rmax ) - low];
>      double avg = 0.0;
>      for( size_t &d : distrib )
>          avg += d;
>      avg /= distrib.size();
>      cout << "average: " << avg << endl;
>      double stdDev = 0.0;
>      for( size_t &d : distrib )
>          stdDev += (d - avg) * (d - avg);
>      stdDev = sqrt( stdDev / distrib.size() );
>      cout << "standard deviation: " << stdDev << endl;
> }

I've no idea what this distrib stuff does, what the numbers it produces 
mean, or what the ideal values are. If these are just averaged over the 
whole span, then any localised deviations are not going to show up.

How about you show a histogram as I did? And your dumbRnd() is flawed, 
as it's made to return 0..3 anyway, exactly the range requested by 
randeRand!

Try this test:

   for (int i=0; i<60; ++i) printf("%d\n",rangeRand(0,1,rand,RAND_MAX));

You will notice a distinct lack of 1's in the output. Remember, the 
range is supposed to be inclusive. And if you intended it to be 
exclusive, then try this test:

   int x;
   for (int i=0; i<1000000; ++i) {
       x=rangeRand(0,1,rand,RAND_MAX);
       if (x==1) printf("%d\n",x);
   }

(On Windows, RAND_MAX is 32767, and this shows shows 30-odd 1s per 
million calls to rand(), which is approximately 1/32768. If your rand() 
returns a wider range, then emulate this 15-bit rand and try that.)

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


#147892

FromBonita Montero <Bonita.Montero@gmail.com>
Date2019-11-10 15:22 +0100
Message-ID<qq96ek$bsr$2@news.albasani.net>
In reply to#147886
> I've no idea what this distrib stuff does, what the numbers it produces 
> mean, or what the ideal values are. If these are just averaged over the 
> whole span, then any localised deviations are not going to show up.

The code outputs the average frequence of each value as well as the
standard-deviation. And with your "random"-generator the standard
-deviation is zero, i.e. all numbers have an equal frequency; so
there is nothing wrong with my algorithm
But I'm asking myself why there's something to check here because
it is obvious that my range-random is o.k..

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


#147894

FromBart <bc@freeuk.com>
Date2019-11-10 14:30 +0000
Message-ID<M9VxF.27513$9h3.9733@fx10.am4>
In reply to#147892
On 10/11/2019 14:22, Bonita Montero wrote:
>> I've no idea what this distrib stuff does, what the numbers it 
>> produces mean, or what the ideal values are. If these are just 
>> averaged over the whole span, then any localised deviations are not 
>> going to show up.
> 
> The code outputs the average frequence of each value as well as the
> standard-deviation. And with your "random"-generator the standard
> -deviation is zero, i.e. all numbers have an equal frequency; so
> there is nothing wrong with my algorithm
> But I'm asking myself why there's something to check here because
> it is obvious that my range-random is o.k..

You're completely missing the point. Deliberately? Why not just admit 
that your randIt function is wrong?

The errors in it are not going to picked up by distribution analysis. 
Take this set of expected results for the closed range 0 to 4:

   Hist[0] = 638467
   Hist[1] = 641144
   Hist[2] = 640064
   Hist[3] = 640551
   Hist[4] = 639774

All evenly distributed. Your function returns:

   Hist[0] = 798312
   Hist[1] = 801048
   Hist[2] = 800295
   Hist[3] = 800248
   Hist[4] = 97

Obviously wrong. But N-1 of the values will be around 800,000, and 1 
will be completely out. Will your analysis pick up that the values 
really need to be around 640,000 rather than 800,000? Will it detect one 
rogue value?

In any case I've given plenty of tests that you can try that show your 
function is buggy, which you've decided to ignore, and instead a set of 
misleading analyses to try and make out there's nothing wrong with your 
routine!

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


#147897

FromBart <bc@freeuk.com>
Date2019-11-10 14:36 +0000
Message-ID<OfVxF.50511$xi6.28557@fx40.am4>
In reply to#147894
On 10/11/2019 14:30, Bart wrote:
> On 10/11/2019 14:22, Bonita Montero wrote:
>>> I've no idea what this distrib stuff does, what the numbers it 
>>> produces mean, or what the ideal values are. If these are just 
>>> averaged over the whole span, then any localised deviations are not 
>>> going to show up.
>>
>> The code outputs the average frequence of each value as well as the
>> standard-deviation. And with your "random"-generator the standard
>> -deviation is zero, i.e. all numbers have an equal frequency; so
>> there is nothing wrong with my algorithm
>> But I'm asking myself why there's something to check here because
>> it is obvious that my range-random is o.k..
> 
> You're completely missing the point. Deliberately? Why not just admit 
> that your randIt function is wrong?
> 
> The errors in it are not going to picked up by distribution analysis. 
> Take this set of expected results for the closed range 0 to 4:
> 
>    Hist[0] = 638467
>    Hist[1] = 641144
>    Hist[2] = 640064
>    Hist[3] = 640551
>    Hist[4] = 639774
> 
> All evenly distributed. Your function returns:
> 
>    Hist[0] = 798312
>    Hist[1] = 801048
>    Hist[2] = 800295
>    Hist[3] = 800248
>    Hist[4] = 97
> 
> Obviously wrong. But N-1 of the values will be around 800,000, and 1 
> will be completely out. Will your analysis pick up that the values 
> really need to be around 640,000 rather than 800,000? Will it detect one 
> rogue value?
> 
> In any case I've given plenty of tests that you can try that show your 
> function is buggy, which you've decided to ignore, and instead a set of 
> misleading analyses to try and make out there's nothing wrong with your 
> routine!
> 

BTW, to fix this routine of yours:

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

Try adding +1 here to get the correct span:

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

Wasn't hard was it?

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


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

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


csiph-web