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


Groups > comp.theory > #58398 > unrolled thread

Michael Sipser of MIT validates the notion of a simulating halt decider

Started byolcott <polcott2@gmail.com>
First post2022-10-12 10:08 -0500
Last post2022-10-30 11:43 -0500
Articles 20 on this page of 244 — 18 participants

Back to article view | Back to comp.theory


Contents

  Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 10:08 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-10-12 17:54 +0200
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-12 17:46 +0100
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 12:04 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 16:07 -0700
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-16 23:58 -0500
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 06:51 -0400
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-17 09:43 -0500
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 18:33 -0400
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-17 17:47 -0500
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 19:04 -0400
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-17 19:06 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 20:52 -0400
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [Ben agrees] olcott <none-ya@beez-waxes.com> - 2022-10-17 20:03 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 19:04 -0500
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Python <python@invalid.org> - 2022-10-18 02:36 +0200
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <none-ya@beez-waxes.com> - 2022-10-17 19:56 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Python <python@invalid.org> - 2022-10-18 03:01 +0200
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 20:10 -0500
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Python <python@invalid.org> - 2022-10-18 03:24 +0200
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 20:27 -0500
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 21:33 -0400
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 20:54 -0400
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <none-ya@beez-waxes.com> - 2022-10-17 20:06 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 21:26 -0400
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 20:35 -0500
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 21:46 -0400
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 20:57 -0500
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Dennis Bush <dbush.mobile@gmail.com> - 2022-10-17 19:03 -0700
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 21:14 -0500
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Dennis Bush <dbush.mobile@gmail.com> - 2022-10-17 19:23 -0700
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <NoOne@NoWhere.com> - 2022-10-17 21:34 -0500
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Dennis Bush <dbush.mobile@gmail.com> - 2022-10-17 19:41 -0700
                                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 21:48 -0500
                                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Dennis Bush <dbush.mobile@gmail.com> - 2022-10-17 19:56 -0700
                                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 22:09 -0500
                                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 22:27 -0500
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 22:05 -0400
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-17 21:19 -0500
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Richard Damon <Richard@Damon-Family.org> - 2022-10-17 22:32 -0400
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <NoOne@NoWhere.com> - 2022-10-17 21:36 -0500
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] Paul N <gw7rib@aol.com> - 2022-10-18 05:55 -0700
                                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ] olcott <polcott2@gmail.com> - 2022-10-18 09:58 -0500
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Paul N <gw7rib@aol.com> - 2022-10-17 04:59 -0700
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-17 09:20 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-17 09:31 -0500
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 11:48 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 18:24 +0100
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 12:38 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 18:52 +0100
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 13:04 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 19:07 +0100
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 13:25 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 19:30 +0100
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 14:17 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 20:26 +0100
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 14:32 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-12 20:50 +0100
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 15:07 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-10-12 12:32 -0700
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 15:03 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider "dklei...@gmail.com" <dkleinecke@gmail.com> - 2022-10-12 15:23 -0700
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 17:39 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 17:17 +0100
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 11:46 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 17:47 +0100
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 12:26 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider "B.H." <xlt.pjw@gmail.com> - 2022-10-13 13:13 -0700
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:06 -0400
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 18:22 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 20:59 -0400
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 20:13 -0500
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 21:56 -0400
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 20:19 -0500
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 03:44 +0200
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo !!! olcott <polcott2@gmail.com> - 2022-10-13 21:07 -0500
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo !!! Richard Damon <Richard@Damon-Family.org> - 2022-10-13 22:21 -0400
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 22:01 -0400
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 21:11 -0500
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 22:27 -0400
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <none-ya@beez-waxes.com> - 2022-10-13 21:37 -0500
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-13 23:00 -0400
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <polcott2@gmail.com> - 2022-10-13 22:28 -0500
                                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-13 23:51 -0400
                                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <polcott2@gmail.com> - 2022-10-13 23:00 -0500
                                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-14 07:56 -0400
                                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <none-ya@beez-waxes.com> - 2022-10-14 09:13 -0500
                                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-14 13:34 -0400
                                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <none-ya@beez-waxes.com> - 2022-10-13 23:01 -0500
                                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-14 08:05 -0400
                                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 olcott <none-ya@beez-waxes.com> - 2022-10-14 09:14 -0500
                                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-14 15:32 +0100
                                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Bingo^2 Richard Damon <Richard@Damon-Family.org> - 2022-10-14 13:01 -0400
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:01 -0400
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 18:42 -0400
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 17:59 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 20:04 -0400
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 20:00 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 21:52 -0400
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 21:03 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 22:13 -0400
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 21:33 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 22:51 -0400
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 18:37 -0400
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 17:46 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 16:49 -0700
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 19:27 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) olcott <polcott2@gmail.com> - 2022-10-12 19:35 -0500
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) Richard Damon <Richard@Damon-Family.org> - 2022-10-12 20:45 -0400
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) olcott <polcott2@gmail.com> - 2022-10-12 20:03 -0500
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) Richard Damon <Richard@Damon-Family.org> - 2022-10-12 21:59 -0400
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) olcott <polcott2@gmail.com> - 2022-10-12 21:07 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider (correct a typo) Richard Damon <Richard@Damon-Family.org> - 2022-10-12 22:17 -0400
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 20:42 -0400
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-12 18:23 -0700
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 20:31 -0500
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 03:50 +0100
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 23:15 -0400
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 22:51 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 07:50 -0400
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 09:35 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 17:54 +0200
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 11:28 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:12 -0400
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:11 -0400
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 12:29 +0100
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 22:29 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Jeff Barnett <jbb@notatt.com> - 2022-10-13 11:28 -0600
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 12:40 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 18:43 +0100
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 12:52 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 20:09 +0200
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 13:32 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 20:34 +0200
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 13:45 -0500
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 20:51 +0200
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 13:55 -0500
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 20:58 +0200
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 14:03 -0500
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-13 21:06 +0200
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 14:14 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Jeff Barnett <jbb@notatt.com> - 2022-10-13 23:06 -0600
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-14 00:28 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 08:09 -0400
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 09:20 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 16:38 +0200
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 10:37 -0500
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 17:45 +0200
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 11:00 -0500
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 18:07 +0200
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-14 11:36 -0500
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 18:53 +0200
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 18:59 +0200
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 12:06 -0500
                                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 19:12 +0200
                                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 12:24 -0500
                                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 19:29 +0200
                                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 12:57 -0500
                                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 14:17 -0400
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 13:29 -0400
                          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 13:26 -0500
                            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 14:40 -0400
                              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 14:06 -0500
                                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 15:52 -0400
                                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 15:09 -0500
                                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 16:28 -0400
                                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 15:49 -0500
                                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-14 17:00 -0400
                          Re: Trickery Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-15 01:21 +0100
                            Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <polcott2@gmail.com> - 2022-10-14 19:29 -0500
                              Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Richard Damon <Richard@Damon-Family.org> - 2022-10-14 20:39 -0400
                                Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 09:40 +0100
                                  Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <polcott2@gmail.com> - 2022-10-15 08:17 -0500
                                    Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 14:20 +0100
                                      Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <polcott2@gmail.com> - 2022-10-15 08:28 -0500
                                        Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 14:31 +0100
                                          Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <none-ya@beez-waxes.com> - 2022-10-15 09:09 -0500
                                            Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 15:13 +0100
                                              Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <none-ya@beez-waxes.com> - 2022-10-15 09:26 -0500
                                                Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 15:30 +0100
                                                  Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] olcott <none-ya@beez-waxes.com> - 2022-10-15 09:39 -0500
                                                    Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 15:42 +0100
                                    Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed wij <wyniijj2@gmail.com> - 2022-10-15 06:51 -0700
                                      Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <none-ya@beez-waxes.com> - 2022-10-15 09:16 -0500
                                        Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 15:25 +0100
                                          Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] olcott <none-ya@beez-waxes.com> - 2022-10-15 09:36 -0500
                                            Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 15:40 +0100
                                              Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] olcott <polcott2@gmail.com> - 2022-10-15 09:56 -0500
                                                Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:02 +0100
                                                  Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] olcott <none-ya@beez-waxes.com> - 2022-10-15 10:24 -0500
                                                    Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed [academic theft] Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-15 16:27 +0100
                                        Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed wij <wyniijj2@gmail.com> - 2022-10-15 07:38 -0700
                                          Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <polcott2@gmail.com> - 2022-10-15 09:46 -0500
                                          Re: Trickery of Ben refusing to accept a SHD even after it has been affirmed olcott <polcott2@gmail.com> - 2022-10-15 09:52 -0500
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 19:53 +0100
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 13:56 -0500
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:17 -0400
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mikko <mikko.levanto@iki.fi> - 2022-10-14 13:07 +0300
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-14 09:08 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-17 00:11 -0500
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 06:54 -0400
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-17 16:23 +0100
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-17 10:40 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-17 18:36 -0400
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [--Ben agrees--] olcott <none-ya@beez-waxes.com> - 2022-10-17 19:41 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider [--Ben agrees--] olcott <none-ya@beez-waxes.com> - 2022-10-17 19:53 -0500
                        Re: Michael Sipser of MIT validates the notion of a simulating halt decider [--Ben agrees--] olcott <polcott2@gmail.com> - 2022-10-17 19:54 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-19 16:59 -0500
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider (Ben's support) olcott <none-ya@beez-waxes.com> - 2022-10-20 22:17 -0500
                      Re: Ben agrees that Sipser_H is correct according to its halt status criteria olcott <polcott2@gmail.com> - 2022-10-20 22:41 -0500
                      Ben agrees that Sipser_H is correct according to its halt status criteria olcott <polcott2@gmail.com> - 2022-10-21 15:03 -0500
                        Re: Ben agrees that Sipser_H is correct according to its halt status criteria [Paul N Lies] olcott <polcott2@gmail.com> - 2022-10-22 14:20 -0500
                        Paul N is a liar or does not bother to pay attention olcott <polcott2@gmail.com> - 2022-10-22 17:10 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Philip White <philipwhite363@gmail.com> - 2022-10-12 18:51 -0700
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-12 20:58 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Philip White <philipwhite363@gmail.com> - 2022-10-12 19:09 -0700
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 21:32 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider "B.H." <xlt.pjw@gmail.com> - 2022-10-12 20:07 -0700
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-12 22:36 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Philip White <philipwhite363@gmail.com> - 2022-10-13 09:18 -0700
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider wij <wyniijj2@gmail.com> - 2022-10-13 14:35 -0700
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Python <python@invalid.org> - 2022-10-14 02:50 +0200
                      Re: Michael Sipser of MIT validates the notion of a simulating halt decider wij <wyniijj2@gmail.com> - 2022-10-13 19:09 -0700
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 22:19 -0400
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-12 22:05 -0400
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider om@iki.fi (Otto J. Makela) - 2022-10-13 10:47 +0300
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 09:33 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-13 10:42 -0700
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <none-ya@beez-waxes.com> - 2022-10-13 12:48 -0500
            Re: Michael Sipser of MIT validates the notion of a simulating halt decider Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-13 11:20 -0700
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 13:37 -0500
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 19:40 +0100
                  Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 13:49 -0500
                    Re: Michael Sipser of MIT validates the notion of a simulating halt decider Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-10-13 19:52 +0100
                Re: Michael Sipser of MIT validates the notion of a simulating halt decider Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-10-13 12:52 -0700
              Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 15:12 -0500
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-10-13 21:07 +0200
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 14:19 -0500
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-10-13 21:28 +0200
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 15:11 -0500
      Re: Michael Sipser of MIT validates the notion of a simulating halt decider Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-10-13 20:24 +0100
        Re: Michael Sipser of MIT validates the notion of a simulating halt decider olcott <polcott2@gmail.com> - 2022-10-13 14:32 -0500
          Re: Michael Sipser of MIT validates the notion of a simulating halt decider Richard Damon <Richard@Damon-Family.org> - 2022-10-13 19:19 -0400
    Re: Michael Sipser of MIT validates the notion of a simulating halt decider [-Update-] olcott <polcott2@gmail.com> - 2022-10-30 11:43 -0500

Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13  Next page →


#58964 — Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]

Fromolcott <NoOne@NoWhere.com>
Date2022-10-17 21:36 -0500
SubjectRe: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]
Message-ID<fdednXZiZp7VjNP-nZ2dnZfqlJz9fwAA@giganews.com>
In reply to#58962
On 10/17/2022 9:32 PM, Richard Damon wrote:
> On 10/17/22 10:19 PM, olcott wrote:
>> On 10/17/2022 9:05 PM, Richard Damon wrote:
>>> On 10/17/22 9:57 PM, olcott wrote:
>>>> On 10/17/2022 8:46 PM, Richard Damon wrote:
>>>>> On 10/17/22 9:35 PM, olcott wrote:
>>>>>> On 10/17/2022 8:26 PM, Richard Damon wrote:
>>>>>>> On 10/17/22 9:06 PM, olcott wrote:
>>>>>>>> On 10/17/2022 7:54 PM, Richard Damon wrote:
>>>>>>>>> On 10/17/22 8:04 PM, olcott wrote:
>>>>>>>>>> On 10/17/2022 5:33 PM, Richard Damon wrote:
>>>>>>>>>>> On 10/17/22 10:43 AM, olcott wrote:
>>>>>>>>>>>> On 10/17/2022 5:51 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 10/17/22 12:58 AM, olcott wrote:
>>>>>>>>>>>>>> On 10/12/2022 11:46 AM, Ben Bacarisse wrote:
>>>>>>>>>>>>>>> "Fred. Zwarts" <F.Zwarts@KVI.nl> writes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Op 12.okt..2022 om 17:08 schreef olcott:
>>>>>>>>>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim 
>>>>>>>>>>>>>>>>> paragraph looks correct:
>>>>>>>>>>>>>>>>>      If H does correctly determine that its correct 
>>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>>      of D would never stop running unless aborted, 
>>>>>>>>>>>>>>>>> would it be
>>>>>>>>>>>>>>>>>      correct for H to abort this simulation and report 
>>>>>>>>>>>>>>>>> that D
>>>>>>>>>>>>>>>>>      specifies a non-halting sequence of configurations?
>>>>>>>>>>>>>>>>> This validates the idea of a simulating halt decider 
>>>>>>>>>>>>>>>>> referenced in this
>>>>>>>>>>>>>>>>> paper.
>>>>>>>>>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>>>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>>>>>>>>>> Professor Sipser has not had the time to carefully 
>>>>>>>>>>>>>>>>> review this paper
>>>>>>>>>>>>>>>>> presented to him.
>>>>>>>>>>>>>>>>> *The exact words posted above have been approved by 
>>>>>>>>>>>>>>>>> Michael Sipser*
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> And what does he say about:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Oh please don't draw the good professor into this any 
>>>>>>>>>>>>>>> further!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>       If H does incorrectly determine that its incorrect 
>>>>>>>>>>>>>>>> simulation
>>>>>>>>>>>>>>>>       of D would never stop running unless aborted, 
>>>>>>>>>>>>>>>> would it be
>>>>>>>>>>>>>>>>       correct for H to abort this simulation and report 
>>>>>>>>>>>>>>>> that D
>>>>>>>>>>>>>>>>       specifies a non-halting sequence of configurations?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You need to remove the deceptive subjunctive "would ... 
>>>>>>>>>>>>>>> unless" to get
>>>>>>>>>>>>>>> something not open to PO's dishonest re-interpretation. 
>>>>>>>>>>>>>>> Whatever H
>>>>>>>>>>>>>>> "would" do "unless" it does what it actually does is 
>>>>>>>>>>>>>>> irrelevant. H(P,P)
>>>>>>>>>>>>>>> returns 0 and P(P) halts.  0 is the wrong answer for a 
>>>>>>>>>>>>>>> halting
>>>>>>>>>>>>>>> computation.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Would the correctly simulated input ever stop running if 
>>>>>>>>>>>>>> not aborted?
>>>>>>>>>>>>>> This is another legitimate way of asking: Does this input 
>>>>>>>>>>>>>> halt?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right, and the CORRECTLY SIMULATED input to H(D) will reach 
>>>>>>>>>>>>> a final state if it were not a fact that H aborted its 
>>>>>>>>>>>>> simulation, given that H(D) Does abort and return and answer.
>>>>>>>>>>>>
>>>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and 
>>>>>>>>>>>> no more)
>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D 
>>>>>>>>>>>> until H
>>>>>>>>>>>> correctly determines that its simulated D would never stop 
>>>>>>>>>>>> running
>>>>>>>>>>>> unless aborted then H can abort its simulation of D and 
>>>>>>>>>>>> correctly report
>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
>>>>>>>>>>>
>>>>>>>>>>> Right, so unless THIS H can correct simulate the input and 
>>>>>>>>>>> CORRECTLY predict that it will not halt, it doesn't apply.
>>>>>>>>>>>
>>>>>>>>>> On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
>>>>>>>>>>  > ...D(D) would not halt unless H stops the simulation.
>>>>>>>>>>  > H /can/ correctly determine this silly criterion
>>>>>>>>>>  > (in this one case)...
>>>>>>>>>>
>>>>>>>>>> Ben agrees that H can compute the Sipser approved non-halting 
>>>>>>>>>> criteria.
>>>>>>>>>> I always knew that every technically competent person would 
>>>>>>>>>> affirm this.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> No, he seems to be agreeing that H can copute your 
>>>>>>>>> misinterpreation of the criteria, not the actual one.
>>>>>>>>>
>>>>>>>>> Since he is still pointing out your errors, you claiming the 
>>>>>>>>> endorcement is just another of your lies.
>>>>>>>>
>>>>>>>> Ben does not actually point out any actual errors. Ben has 
>>>>>>>> resorted to rhetoric instead of reasoning as he always does when 
>>>>>>>> the fact that I am correct has no correct rebuttal.
>>>>>>>
>>>>>>> No, Ben points out many error.
>>>>>>>
>>>>>>> You are just showing your self to be too stupid to understand them.
>>>>>>>>
>>>>>>>> H /can/ correctly determine this silly criterion (in this one 
>>>>>>>> case)...
>>>>>>>
>>>>>>> Nope, you claim it can, but the answer is wrong.
>>>>>>>
>>>>>>>>
>>>>>>>> Meaning that Sipser_H can correctly determine that Sipser_D does 
>>>>>>>> specify a non-halting sequence of configurations when Sipser_H 
>>>>>>>> applies the Sipser approved criterion.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> Nope, it INCORRECTLY determines that results, 
>>>>>>
>>>>>> The results are correct when measured against the Sipser approved 
>>>>>> criteria.
>>>>>
>>>>>
>>>>> Nope.
>>>>>
>>>>>>
>>>>>> Ben agrees that Sipser_H can correctly determine that Sipser_D 
>>>>>> does meet the Sipser approved non-halting criteria.
>>>>>>
>>>>>>
>>>>> Nope.
>>>>>
>>>>> You are just too dumb to understand.
>>>>>
>>>>> Sipser requreis that H CORRECTLY determines what a CORRECT 
>>>>> simulation would do,
>>>>>
>>>>
>>>> *As always you lie about this*  *Troll head games*
>>>> It has never been about a correct simulation of D.
>>>> It has always been about a correct simulation of D by H.
>>>
>>> And if H doesn't do a correct simulation, then your definition has no 
>>> answer. PERIOD.
>>
>> On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
>>  > ...D(D) would not halt unless H stops the simulation.
>>  > H /can/ correctly determine this silly criterion (in this one case)...
>>
>> Maybe when I tell you this a few hundred more times you will actually 
>> notice all of the words.
>>
>>
> 
> Which isn't the question that H is supposed to ask, so you are admitting 
> that you aren't doing the right problem.
> 

*Ben seems to agree with this*
It is a verified fact that Sipser_H does correctly determine the halt 
status of Sipser_D according to the Sipser approved criteria.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#58985 — Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]

FromPaul N <gw7rib@aol.com>
Date2022-10-18 05:55 -0700
SubjectRe: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]
Message-ID<2776f1e6-788e-42a0-bf3e-127d9771a396n@googlegroups.com>
In reply to#58964
On Tuesday, October 18, 2022 at 3:37:02 AM UTC+1, olcott wrote:
> >>>>>>>>>>> On 10/17/22 10:43 AM, olcott wrote: 
> >>>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and 
> >>>>>>>>>>>> no more) 
> >>>>>>>>>>>> If simulating halt decider H correctly simulates its input D 
> >>>>>>>>>>>> until H 
> >>>>>>>>>>>> correctly determines that its simulated D would never stop 
> >>>>>>>>>>>> running 
> >>>>>>>>>>>> unless aborted then H can abort its simulation of D and 
> >>>>>>>>>>>> correctly report 
> >>>>>>>>>>>> that D specifies a non-halting sequence of configurations. 

> It is a verified fact that Sipser_H does correctly determine the halt 
> status of Sipser_D according to the Sipser approved criteria.

Professor Sipser has said that *if* the simulator *correctly* determines that the input would not halt, it would be correct to report that. He has *not* said that looking at the simulation is the *only* way to assess the question, nor has he said it is the *best* way to assess it. He certainly has not said that, in the situation of a discrepancy between the simulator and actual life, that the actual results should be junked in favour of those from the simulator. I would guess he would consider, as everyone else here seems to, that if the results produced by the simulator are different from what actually happens then the simulator is *incorrect*.

When challenged on this point before, many times, you have often posted a pile of traces and said that they are identical and so the simulator must be correct. Richard has pointed out many times where you are going wrong and you have never listened to him, so it seems a bit pointless pointing it out yet again, but I will try. The simulator doesn't have the intelligence to "know" for itself whether the code it is simulating will run forever, it looks for certain patterns which you believe indicate that the program will not end and reports if it sees one of these patterns. The program is incorrect in doing this, as can be clearly seen by the fact it says P(P) will not halt when you also claim that P(P) does. The problem is that the H being simulated will itself abort and so the program can end without the outermost H having to abort it. The reason why your simulator is wrong may be a bit tricky to follow (certainly you have never showed any signs of following it) but it is blatantly obvious that it must be wrong because it gives clearly the wrong results.

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


#58990 — Re: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]

Fromolcott <polcott2@gmail.com>
Date2022-10-18 09:58 -0500
SubjectRe: Michael Sipser of MIT validates the notion of a simulating halt decider [ Ben agrees ]
Message-ID<timevk$3ojta$2@dont-email.me>
In reply to#58985
On 10/18/2022 7:55 AM, Paul N wrote:
> On Tuesday, October 18, 2022 at 3:37:02 AM UTC+1, olcott wrote:
>>>>>>>>>>>>> On 10/17/22 10:43 AM, olcott wrote:
>>>>>>>>>>>>>> *Professor Sipser has agreed to these verbatim words* (and
>>>>>>>>>>>>>> no more)
>>>>>>>>>>>>>> If simulating halt decider H correctly simulates its input D
>>>>>>>>>>>>>> until H
>>>>>>>>>>>>>> correctly determines that its simulated D would never stop
>>>>>>>>>>>>>> running
>>>>>>>>>>>>>> unless aborted then H can abort its simulation of D and
>>>>>>>>>>>>>> correctly report
>>>>>>>>>>>>>> that D specifies a non-halting sequence of configurations.
> 
>> It is a verified fact that Sipser_H does correctly determine the halt
>> status of Sipser_D according to the Sipser approved criteria.
> 
> Professor Sipser has said that *if* the simulator *correctly* determines that the input would not halt, it would be correct to report that. 

On 10/17/2022 10:23 AM, Ben Bacarisse wrote:
 > ...D(D) would not halt unless H stops the simulation.
 > H /can/ correctly determine this silly criterion
 > (in this one case)...

H /can/ correctly determine this silly criterion (in this one case)...

> He has *not* said that looking at the simulation is the *only* way to assess the question, nor has he said it is the *best* way to assess it. He certainly has not said that, in the situation of a discrepancy between the simulator and actual life, that the actual results should be junked in favour of those from the simulator. I would guess he would consider, as everyone else here seems to, that if the results produced by the simulator are different from what actually happens then the simulator is *incorrect*.

The actual code proves that the simulator is correct in that every line 
of code of D that was simulated by H was specified by D.

> 
> When challenged on this point before, many times, you have often posted a pile of traces and said that they are identical and so the simulator must be correct. 


Richard has pointed out many times where you are going wrong and you 
have never listened to him,

I say that the D simulated by H never stop unless aborted and Richard 
deceptively twists these words by saying that some other different D 
does stop if not aborted.

> so it seems a bit pointless pointing it out yet again, but I will try. The simulator doesn't have the intelligence to "know" for itself whether the code it is simulating will run forever, it looks for certain patterns which you believe indicate that the program will not end and reports if it sees one of these patterns. 

Sipser_H: Begin Simulation   Execution Trace Stored at:111fa8
  machine   stack     stack     machine    assembly
  address   address   data      code       language
  ========  ========  ========  =========  =============
[000012ae][00111f94][00111f98] 55         push ebp      // Begin Sipser_D
[000012af][00111f94][00111f98] 8bec       mov ebp,esp
[000012b1][00111f94][00111f98] 8b4508     mov eax,[ebp+08]
[000012b4][00111f90][000012ae] 50         push eax      // push Sipser_D
[000012b5][00111f90][000012ae] 8b4d08     mov ecx,[ebp+08]
[000012b8][00111f8c][000012ae] 51         push ecx      // push Sipser_D
[000012b9][00111f88][000012be] e880fdffff call 0000103e // call Sipser_H
Sipser_H: Infinitely Recursive Simulation Detected Simulation Stopped

Every competent software engineer will agree that the simulation of D by 
H will not stop unless H aborts this simulation exactly meeting the 
Sipser approved criterion.

> The program is incorrect in doing this, as can be clearly seen by the fact it says P(P) will not halt when you also claim that P(P) does. 

None-the-less professor Sipser
author of the best selling book on the theory of computation
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295

agrees that H is correct to do this.

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider *H correctly simulates its input D until H*
*correctly determines that its simulated D would never stop running*
*unless aborted* then H can abort its simulation of D and correctly
report that D specifies a non-halting sequence of configurations.

> The problem is that the H being simulated will itself abort and so the program can end without the outermost H having to abort it. 

No this is factually incorrect
This is exactly the same as saying the a function called in infinite 
recursion will eventually return to its caller.

> The reason why your simulator is wrong may be a bit tricky to follow (certainly you have never showed any signs of following it) but it is blatantly obvious that it must be wrong because it gives clearly the wrong results.



-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58870

FromPaul N <gw7rib@aol.com>
Date2022-10-17 04:59 -0700
Message-ID<b344e9ec-ccfc-4bd0-ad53-4dfb3aee193bn@googlegroups.com>
In reply to#58856
On Monday, October 17, 2022 at 5:58:35 AM UTC+1, olcott wrote:
> On 10/12/2022 11:46 AM, Ben Bacarisse wrote: 
> > "Fred. Zwarts" <F.Zw...@KVI.nl> writes: 
> > 
> >> Op 12.okt..2022 om 17:08 schreef olcott: 
> >>> Professor Michael Sipser of MIT said that this verbatim paragraph looks correct: 
> >>>    If H does correctly determine that its correct simulation 
> >>>    of D would never stop running unless aborted, would it be 
> >>>    correct for H to abort this simulation and report that D 
> >>>    specifies a non-halting sequence of configurations? 
> >>> This validates the idea of a simulating halt decider referenced in this 
> >>> paper. 
> >>> *Rebutting the Sipser Halting Problem Proof* 
> >>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof 
> >>> Professor Sipser has not had the time to carefully review this paper 
> >>> presented to him. 
> >>> *The exact words posted above have been approved by Michael Sipser* 
> >>> 
> >> 
> >> And what does he say about: 
> > 
> > Oh please don't draw the good professor into this any further! 
> > 
> >> If H does incorrectly determine that its incorrect simulation 
> >> of D would never stop running unless aborted, would it be 
> >> correct for H to abort this simulation and report that D 
> >> specifies a non-halting sequence of configurations? 
> > 
> > You need to remove the deceptive subjunctive "would ... unless" to get 
> > something not open to PO's dishonest re-interpretation. Whatever H 
> > "would" do "unless" it does what it actually does is irrelevant. H(P,P) 
> > returns 0 and P(P) halts. 0 is the wrong answer for a halting 
> > computation. 
> > 
> 
> Would the correctly simulated input ever stop running if not aborted? 
> This is another legitimate way of asking: Does this input halt?

Exactly. Since you are claiming that the answer to "Would the correctly simulated input ever stop running if not aborted?" is "No" and the answer to "Does this input halt?" is "Yes", it's clear you are making a mistake somewhere.

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


#58873

Fromolcott <none-ya@beez-waxes.com>
Date2022-10-17 09:20 -0500
Message-ID<tijoaj$7l0$1@gioia.aioe.org>
In reply to#58870
On 10/17/2022 6:59 AM, Paul N wrote:
> On Monday, October 17, 2022 at 5:58:35 AM UTC+1, olcott wrote:
>> On 10/12/2022 11:46 AM, Ben Bacarisse wrote:
>>> "Fred. Zwarts" <F.Zw...@KVI.nl> writes:
>>>
>>>> Op 12.okt..2022 om 17:08 schreef olcott:
>>>>> Professor Michael Sipser of MIT said that this verbatim paragraph looks correct:
>>>>>     If H does correctly determine that its correct simulation
>>>>>     of D would never stop running unless aborted, would it be
>>>>>     correct for H to abort this simulation and report that D
>>>>>     specifies a non-halting sequence of configurations?
>>>>> This validates the idea of a simulating halt decider referenced in this
>>>>> paper.
>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>> Professor Sipser has not had the time to carefully review this paper
>>>>> presented to him.
>>>>> *The exact words posted above have been approved by Michael Sipser*
>>>>>
>>>>
>>>> And what does he say about:
>>>
>>> Oh please don't draw the good professor into this any further!
>>>
>>>> If H does incorrectly determine that its incorrect simulation
>>>> of D would never stop running unless aborted, would it be
>>>> correct for H to abort this simulation and report that D
>>>> specifies a non-halting sequence of configurations?
>>>
>>> You need to remove the deceptive subjunctive "would ... unless" to get
>>> something not open to PO's dishonest re-interpretation. Whatever H
>>> "would" do "unless" it does what it actually does is irrelevant. H(P,P)
>>> returns 0 and P(P) halts. 0 is the wrong answer for a halting
>>> computation.
>>>
>>
>> Would the correctly simulated input ever stop running if not aborted?
>> This is another legitimate way of asking: Does this input halt?
> 
> Exactly. Since you are claiming that the answer to "Would the correctly simulated input ever stop running if not aborted?" is "No" and the answer to "Does this input halt?" is "Yes", it's clear you are making a mistake somewhere.

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the 
Sipser approved criteria shown below.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof

Would D directly executed by main ever stop running?
is proven to be a different question as the execution trace of the code 
below shown in Halt7_Sipser.txt linked below proves.

int Sipser_D(int (*M)())
{
   if ( Sipser_H(M, M) )
     return 0;
   return 1;
}

int main()
{
   Output((char*)"Input_Halts = ", Sipser_D(Sipser_D));
}

*Complete halt deciding system (Visual Studio Project)* Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
(d) The execution trace of Sipser_H applied to Sipser_D is shown in 
Halt7_Sipser.txt
https://liarparadox.org/2022_10_08.zip

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#58875

Fromolcott <none-ya@beez-waxes.com>
Date2022-10-17 09:31 -0500
Message-ID<tijp08$gq2$1@gioia.aioe.org>
In reply to#58870
On 10/17/2022 6:59 AM, Paul N wrote:
> On Monday, October 17, 2022 at 5:58:35 AM UTC+1, olcott wrote:
>> On 10/12/2022 11:46 AM, Ben Bacarisse wrote:
>>> "Fred. Zwarts" <F.Zw...@KVI.nl> writes:
>>>
>>>> Op 12.okt..2022 om 17:08 schreef olcott:
>>>>> Professor Michael Sipser of MIT said that this verbatim paragraph looks correct:
>>>>>     If H does correctly determine that its correct simulation
>>>>>     of D would never stop running unless aborted, would it be
>>>>>     correct for H to abort this simulation and report that D
>>>>>     specifies a non-halting sequence of configurations?
>>>>> This validates the idea of a simulating halt decider referenced in this
>>>>> paper.
>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>> Professor Sipser has not had the time to carefully review this paper
>>>>> presented to him.
>>>>> *The exact words posted above have been approved by Michael Sipser*
>>>>>
>>>>
>>>> And what does he say about:
>>>
>>> Oh please don't draw the good professor into this any further!
>>>
>>>> If H does incorrectly determine that its incorrect simulation
>>>> of D would never stop running unless aborted, would it be
>>>> correct for H to abort this simulation and report that D
>>>> specifies a non-halting sequence of configurations?
>>>
>>> You need to remove the deceptive subjunctive "would ... unless" to get
>>> something not open to PO's dishonest re-interpretation. Whatever H
>>> "would" do "unless" it does what it actually does is irrelevant. H(P,P)
>>> returns 0 and P(P) halts. 0 is the wrong answer for a halting
>>> computation.
>>>
>>
>> Would the correctly simulated input ever stop running if not aborted?
>> This is another legitimate way of asking: Does this input halt?
> 
> Exactly. Since you are claiming that the answer to "Would the correctly simulated input ever stop running if not aborted?" is "No" and the answer to "Does this input halt?" is "Yes", it's clear you are making a mistake somewhere.

*Professor Sipser has agreed to these verbatim words* (and no more)
If simulating halt decider H correctly simulates its input D until H
correctly determines that its simulated D would never stop running
unless aborted then H can abort its simulation of D and correctly report
that D specifies a non-halting sequence of configurations.

An alternative definition for a halt decider approved by MIT Professor 
Michael Sipser (author of the best selling book on the theory of 
computation) 
https://www.amazon.com/Introduction-Theory-Computation-Sipser/dp/8131525295 
is shown above and paraphrased below:

Would D correctly simulated by H ever stop running if not aborted?
Is proven on page 3 of this paper to be "no" thus perfectly meeting the 
Sipser approved criteria shown above.

*Rebutting the Sipser Halting Problem Proof*
https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof


-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#58401

Fromolcott <polcott2@gmail.com>
Date2022-10-12 11:48 -0500
Message-ID<ti6r4c$1hpc2$2@dont-email.me>
In reply to#58399
On 10/12/2022 10:54 AM, Fred. Zwarts wrote:
> Op 12.okt..2022 om 17:08 schreef olcott:
>> Professor Michael Sipser of MIT said that this verbatim paragraph 
>> looks correct:
>>
>>     If H does correctly determine that its correct simulation
>>     of D would never stop running unless aborted, would it be
>>     correct for H to abort this simulation and report that D
>>     specifies a non-halting sequence of configurations?
>>
>> This validates the idea of a simulating halt decider referenced in 
>> this paper.
>>
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>
>> Professor Sipser has not had the time to carefully review this paper 
>> presented to him.
>>
>> *The exact words posted above have been approved by Michael Sipser*
>>
>>
> 
> And what does he say about:
> 
>       If H does incorrectly determine that its incorrect simulation
>       of D would never stop running unless aborted, would it be
>       correct for H to abort this simulation and report that D
>       specifies a non-halting sequence of configurations?
> 

Professor Michael Sipser of MIT said that this verbatim paragraph looks 
correct:

    If H does correctly determine that its correct simulation
    of D would never stop running unless aborted, would it be
    correct for H to abort this simulation and report that D
    specifies a non-halting sequence of configurations?

This validates that the behavior of D correctly simulated by H is the 
correct behavior that H must report on, thus affirming that the notion 
of a simulating halt decider is correct.

Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip

Ordinary software engineering verifies the simulation of Sipser_D by 
Sipser_H is correct. Ordinary software engineering also verifies that 
Sipser_H does correctly determine that Sipser_D is stuck in what would 
otherwise be infinitely recursive simulation unless H aborts its 
simulation of Sipser_D.

As can be seen from the above quote Professor Sipser has agreed that 
this would be the correct basis for Sipser_H to report that Sipser_D 
specifies a non-halting sequence of configurations.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58403

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 18:24 +0100
Message-ID<20221012182459.00000cb9@reddwarf.jmc.corp>
In reply to#58398
On Wed, 12 Oct 2022 10:08:20 -0500
olcott <polcott2@gmail.com> wrote:

> Professor Michael Sipser of MIT said that this verbatim paragraph
> looks correct:
> 
>     If H does correctly determine that its correct simulation
>     of D would never stop running unless aborted, would it be
>     correct for H to abort this simulation and report that D
>     specifies a non-halting sequence of configurations?
> 
> This validates the idea of a simulating halt decider referenced in
> this paper.
> 
> *Rebutting the Sipser Halting Problem Proof*
> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof 
> 
> 
> Professor Sipser has not had the time to carefully review this paper 
> presented to him.
> 
> *The exact words posted above have been approved by Michael Sipser*

Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:

void Px(void (*x)())
{
	(void) H(x, x);
	return;
}

The correct simulation of Px above is to simulate Px halting.

Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.

/Flibble

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


#58404

Fromolcott <none-ya@beez-waxes.com>
Date2022-10-12 12:38 -0500
Message-ID<ti6u2o$gu5$1@gioia.aioe.org>
In reply to#58403
On 10/12/2022 12:24 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 10:08:20 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> Professor Michael Sipser of MIT said that this verbatim paragraph
>> looks correct:
>>
>>      If H does correctly determine that its correct simulation
>>      of D would never stop running unless aborted, would it be
>>      correct for H to abort this simulation and report that D
>>      specifies a non-halting sequence of configurations?
>>
>> This validates the idea of a simulating halt decider referenced in
>> this paper.
>>
>> *Rebutting the Sipser Halting Problem Proof*
>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>
>>
>> Professor Sipser has not had the time to carefully review this paper
>> presented to him.
>>
>> *The exact words posted above have been approved by Michael Sipser*
> 
> Whilst the paragraph you sent to Sipser is correct the crucial detail
> that you are glossing over is that you do NOT perform a correct
> simulation for all inputs:
> 

Complete halt deciding system (Visual Studio Project) Sipser version.
(a) x86utm operating system
(b) x86 emulator adapted from libx86emu to compile under Windows
(c) Several halt deciders and their sample inputs contained within Halt7.c
https://liarparadox.org/2022_10_08.zip

Anyone with sufficient software engineering skill can easily verify that 
Sipser_D is correctly simulated by Sipser_H and that Sipser_D remains 
stuck in infinitely recursive simulation unless and until Sipser_H 
aborts its correct simulation of Sipser_D.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#58405

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 18:52 +0100
Message-ID<20221012185239.0000114c@reddwarf.jmc.corp>
In reply to#58404
On Wed, 12 Oct 2022 12:38:31 -0500
olcott <none-ya@beez-waxes.com> wrote:

> On 10/12/2022 12:24 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 10:08:20 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> Professor Michael Sipser of MIT said that this verbatim paragraph
> >> looks correct:
> >>
> >>      If H does correctly determine that its correct simulation
> >>      of D would never stop running unless aborted, would it be
> >>      correct for H to abort this simulation and report that D
> >>      specifies a non-halting sequence of configurations?
> >>
> >> This validates the idea of a simulating halt decider referenced in
> >> this paper.
> >>
> >> *Rebutting the Sipser Halting Problem Proof*
> >> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>
> >>
> >> Professor Sipser has not had the time to carefully review this
> >> paper presented to him.
> >>
> >> *The exact words posted above have been approved by Michael
> >> Sipser*  
> > 
> > Whilst the paragraph you sent to Sipser is correct the crucial
> > detail that you are glossing over is that you do NOT perform a
> > correct simulation for all inputs:
> >   
> 
> Complete halt deciding system (Visual Studio Project) Sipser version.
> (a) x86utm operating system
> (b) x86 emulator adapted from libx86emu to compile under Windows
> (c) Several halt deciders and their sample inputs contained within
> Halt7.c https://liarparadox.org/2022_10_08.zip
> 
> Anyone with sufficient software engineering skill can easily verify
> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
> remains stuck in infinitely recursive simulation unless and until
> Sipser_H aborts its correct simulation of Sipser_D.

You chose to not fully address my reply by snipping the important part
so I will give you another chance:

Whilst the paragraph you sent to Sipser is correct the crucial detail
that you are glossing over is that you do NOT perform a correct
simulation for all inputs:

void Px(void (*x)())
{
	(void) H(x, x);
	return;
}

The correct simulation of Px above is to simulate Px halting.

Sipser confirms that the Flibble Signaling Halt Decider (TM) is a
solution however it does not confirm that the Olcott Simulation
Detector is a valid halt decider.

/Flibble

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


#58406

Fromolcott <polcott2@gmail.com>
Date2022-10-12 13:04 -0500
Message-ID<ti6vj2$1hpc2$4@dont-email.me>
In reply to#58405
On 10/12/2022 12:52 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 12:38:31 -0500
> olcott <none-ya@beez-waxes.com> wrote:
> 
>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> Professor Michael Sipser of MIT said that this verbatim paragraph
>>>> looks correct:
>>>>
>>>>       If H does correctly determine that its correct simulation
>>>>       of D would never stop running unless aborted, would it be
>>>>       correct for H to abort this simulation and report that D
>>>>       specifies a non-halting sequence of configurations?
>>>>
>>>> This validates the idea of a simulating halt decider referenced in
>>>> this paper.
>>>>
>>>> *Rebutting the Sipser Halting Problem Proof*
>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>
>>>>
>>>> Professor Sipser has not had the time to carefully review this
>>>> paper presented to him.
>>>>
>>>> *The exact words posted above have been approved by Michael
>>>> Sipser*
>>>
>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>> detail that you are glossing over is that you do NOT perform a
>>> correct simulation for all inputs:
>>>    
>>
>> Complete halt deciding system (Visual Studio Project) Sipser version.
>> (a) x86utm operating system
>> (b) x86 emulator adapted from libx86emu to compile under Windows
>> (c) Several halt deciders and their sample inputs contained within
>> Halt7.c https://liarparadox.org/2022_10_08.zip
>>
>> Anyone with sufficient software engineering skill can easily verify
>> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
>> remains stuck in infinitely recursive simulation unless and until
>> Sipser_H aborts its correct simulation of Sipser_D.
> 
> You chose to not fully address my reply by snipping the important part
> so I will give you another chance:
> 
> Whilst the paragraph you sent to Sipser is correct the crucial detail
> that you are glossing over is that you do NOT perform a correct
> simulation for all inputs:
> 
> void Px(void (*x)())
> {
> 	(void) H(x, x);
> 	return;
> }
> 
> The correct simulation of Px above is to simulate Px halting.
> 

Not at all. It must be a correct simulation of the actual input by the 
simulating halt decider.

int main() { H(Px,Px); }
(a) The executed H simulates Px that calls a simulated H
(b) that simulates Px that calls a simulated H
(c) that simulates Px that calls a simulated H ...



-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58407

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 19:07 +0100
Message-ID<20221012190744.00002a61@reddwarf.jmc.corp>
In reply to#58406
On Wed, 12 Oct 2022 13:04:17 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 12:52 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 12:38:31 -0500
> > olcott <none-ya@beez-waxes.com> wrote:
> >   
> >> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> Professor Michael Sipser of MIT said that this verbatim paragraph
> >>>> looks correct:
> >>>>
> >>>>       If H does correctly determine that its correct simulation
> >>>>       of D would never stop running unless aborted, would it be
> >>>>       correct for H to abort this simulation and report that D
> >>>>       specifies a non-halting sequence of configurations?
> >>>>
> >>>> This validates the idea of a simulating halt decider referenced
> >>>> in this paper.
> >>>>
> >>>> *Rebutting the Sipser Halting Problem Proof*
> >>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>
> >>>>
> >>>> Professor Sipser has not had the time to carefully review this
> >>>> paper presented to him.
> >>>>
> >>>> *The exact words posted above have been approved by Michael
> >>>> Sipser*  
> >>>
> >>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>> detail that you are glossing over is that you do NOT perform a
> >>> correct simulation for all inputs:
> >>>      
> >>
> >> Complete halt deciding system (Visual Studio Project) Sipser
> >> version. (a) x86utm operating system
> >> (b) x86 emulator adapted from libx86emu to compile under Windows
> >> (c) Several halt deciders and their sample inputs contained within
> >> Halt7.c https://liarparadox.org/2022_10_08.zip
> >>
> >> Anyone with sufficient software engineering skill can easily verify
> >> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
> >> remains stuck in infinitely recursive simulation unless and until
> >> Sipser_H aborts its correct simulation of Sipser_D.  
> > 
> > You chose to not fully address my reply by snipping the important
> > part so I will give you another chance:
> > 
> > Whilst the paragraph you sent to Sipser is correct the crucial
> > detail that you are glossing over is that you do NOT perform a
> > correct simulation for all inputs:
> > 
> > void Px(void (*x)())
> > {
> > 	(void) H(x, x);
> > 	return;
> > }
> > 
> > The correct simulation of Px above is to simulate Px halting.
> >   
> 
> Not at all. It must be a correct simulation of the actual input by
> the simulating halt decider.
> 
> int main() { H(Px,Px); }
> (a) The executed H simulates Px that calls a simulated H
> (b) that simulates Px that calls a simulated H
> (c) that simulates Px that calls a simulated H ...

Yes indeed it must be a correct simulation and a correct simulation of
Px is to simulate Px halting.

/Flibble

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


#58408

Fromolcott <polcott2@gmail.com>
Date2022-10-12 13:25 -0500
Message-ID<ti70qu$1hpc2$5@dont-email.me>
In reply to#58407
On 10/12/2022 1:07 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 13:04:17 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>> olcott <none-ya@beez-waxes.com> wrote:
>>>    
>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>       
>>>>>> Professor Michael Sipser of MIT said that this verbatim paragraph
>>>>>> looks correct:
>>>>>>
>>>>>>        If H does correctly determine that its correct simulation
>>>>>>        of D would never stop running unless aborted, would it be
>>>>>>        correct for H to abort this simulation and report that D
>>>>>>        specifies a non-halting sequence of configurations?
>>>>>>
>>>>>> This validates the idea of a simulating halt decider referenced
>>>>>> in this paper.
>>>>>>
>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>
>>>>>>
>>>>>> Professor Sipser has not had the time to carefully review this
>>>>>> paper presented to him.
>>>>>>
>>>>>> *The exact words posted above have been approved by Michael
>>>>>> Sipser*
>>>>>
>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>> detail that you are glossing over is that you do NOT perform a
>>>>> correct simulation for all inputs:
>>>>>       
>>>>
>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>> version. (a) x86utm operating system
>>>> (b) x86 emulator adapted from libx86emu to compile under Windows
>>>> (c) Several halt deciders and their sample inputs contained within
>>>> Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>
>>>> Anyone with sufficient software engineering skill can easily verify
>>>> that Sipser_D is correctly simulated by Sipser_H and that Sipser_D
>>>> remains stuck in infinitely recursive simulation unless and until
>>>> Sipser_H aborts its correct simulation of Sipser_D.
>>>
>>> You chose to not fully address my reply by snipping the important
>>> part so I will give you another chance:
>>>
>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>> detail that you are glossing over is that you do NOT perform a
>>> correct simulation for all inputs:
>>>
>>> void Px(void (*x)())
>>> {
>>> 	(void) H(x, x);
>>> 	return;
>>> }
>>>
>>> The correct simulation of Px above is to simulate Px halting.
>>>    
>>
>> Not at all. It must be a correct simulation of the actual input by
>> the simulating halt decider.
>>
>> int main() { H(Px,Px); }
>> (a) The executed H simulates Px that calls a simulated H
>> (b) that simulates Px that calls a simulated H
>> (c) that simulates Px that calls a simulated H ...
> 
> Yes indeed it must be a correct simulation and a correct simulation of
> Px is to simulate Px halting.
> 
> /Flibble
> 

Sipser agreed that the correct simulation of Px by H is the correct 
measure of the behavior of Px.

When we look at the above execution trace of: int main() { H(Px,Px); }
We see that Px remains stuck in recursive simulation until H aborts this 
simulation.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58409

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 19:30 +0100
Message-ID<20221012193059.00002dfa@reddwarf.jmc.corp>
In reply to#58408
On Wed, 12 Oct 2022 13:25:34 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 1:07 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 13:04:17 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>> olcott <none-ya@beez-waxes.com> wrote:
> >>>      
> >>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>         
> >>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>> paragraph looks correct:
> >>>>>>
> >>>>>>        If H does correctly determine that its correct
> >>>>>> simulation of D would never stop running unless aborted, would
> >>>>>> it be correct for H to abort this simulation and report that D
> >>>>>>        specifies a non-halting sequence of configurations?
> >>>>>>
> >>>>>> This validates the idea of a simulating halt decider referenced
> >>>>>> in this paper.
> >>>>>>
> >>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>
> >>>>>>
> >>>>>> Professor Sipser has not had the time to carefully review this
> >>>>>> paper presented to him.
> >>>>>>
> >>>>>> *The exact words posted above have been approved by Michael
> >>>>>> Sipser*  
> >>>>>
> >>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>> detail that you are glossing over is that you do NOT perform a
> >>>>> correct simulation for all inputs:
> >>>>>         
> >>>>
> >>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>> version. (a) x86utm operating system
> >>>> (b) x86 emulator adapted from libx86emu to compile under Windows
> >>>> (c) Several halt deciders and their sample inputs contained
> >>>> within Halt7.c https://liarparadox.org/2022_10_08.zip
> >>>>
> >>>> Anyone with sufficient software engineering skill can easily
> >>>> verify that Sipser_D is correctly simulated by Sipser_H and that
> >>>> Sipser_D remains stuck in infinitely recursive simulation unless
> >>>> and until Sipser_H aborts its correct simulation of Sipser_D.  
> >>>
> >>> You chose to not fully address my reply by snipping the important
> >>> part so I will give you another chance:
> >>>
> >>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>> detail that you are glossing over is that you do NOT perform a
> >>> correct simulation for all inputs:
> >>>
> >>> void Px(void (*x)())
> >>> {
> >>> 	(void) H(x, x);
> >>> 	return;
> >>> }
> >>>
> >>> The correct simulation of Px above is to simulate Px halting.
> >>>      
> >>
> >> Not at all. It must be a correct simulation of the actual input by
> >> the simulating halt decider.
> >>
> >> int main() { H(Px,Px); }
> >> (a) The executed H simulates Px that calls a simulated H
> >> (b) that simulates Px that calls a simulated H
> >> (c) that simulates Px that calls a simulated H ...  
> > 
> > Yes indeed it must be a correct simulation and a correct simulation
> > of Px is to simulate Px halting.
> > 
> > /Flibble
> >   
> 
> Sipser agreed that the correct simulation of Px by H is the correct 
> measure of the behavior of Px.

Of course he did but you don't do a correct simulation of Px: a
correct simulation of Px is to simulate Px halting as that is how Px
behaves. 

/Flibble

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


#58410

Fromolcott <polcott2@gmail.com>
Date2022-10-12 14:17 -0500
Message-ID<ti73sf$1igap$2@dont-email.me>
In reply to#58409
On 10/12/2022 1:30 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 13:25:34 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 1:07 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 13:04:17 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>       
>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>          
>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
>>>>>>>> paragraph looks correct:
>>>>>>>>
>>>>>>>>         If H does correctly determine that its correct
>>>>>>>> simulation of D would never stop running unless aborted, would
>>>>>>>> it be correct for H to abort this simulation and report that D
>>>>>>>>         specifies a non-halting sequence of configurations?
>>>>>>>>
>>>>>>>> This validates the idea of a simulating halt decider referenced
>>>>>>>> in this paper.
>>>>>>>>
>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>
>>>>>>>>
>>>>>>>> Professor Sipser has not had the time to carefully review this
>>>>>>>> paper presented to him.
>>>>>>>>
>>>>>>>> *The exact words posted above have been approved by Michael
>>>>>>>> Sipser*
>>>>>>>
>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>> correct simulation for all inputs:
>>>>>>>          
>>>>>>
>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>>>> version. (a) x86utm operating system
>>>>>> (b) x86 emulator adapted from libx86emu to compile under Windows
>>>>>> (c) Several halt deciders and their sample inputs contained
>>>>>> within Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>>>
>>>>>> Anyone with sufficient software engineering skill can easily
>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and that
>>>>>> Sipser_D remains stuck in infinitely recursive simulation unless
>>>>>> and until Sipser_H aborts its correct simulation of Sipser_D.
>>>>>
>>>>> You chose to not fully address my reply by snipping the important
>>>>> part so I will give you another chance:
>>>>>
>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>> detail that you are glossing over is that you do NOT perform a
>>>>> correct simulation for all inputs:
>>>>>
>>>>> void Px(void (*x)())
>>>>> {
>>>>> 	(void) H(x, x);
>>>>> 	return;
>>>>> }
>>>>>
>>>>> The correct simulation of Px above is to simulate Px halting.
>>>>>       
>>>>
>>>> Not at all. It must be a correct simulation of the actual input by
>>>> the simulating halt decider.
>>>>
>>>> int main() { H(Px,Px); }
>>>> (a) The executed H simulates Px that calls a simulated H
>>>> (b) that simulates Px that calls a simulated H
>>>> (c) that simulates Px that calls a simulated H ...
>>>
>>> Yes indeed it must be a correct simulation and a correct simulation
>>> of Px is to simulate Px halting.
>>>
>>> /Flibble
>>>    
>>
>> Sipser agreed that the correct simulation of Px by H is the correct
>> measure of the behavior of Px.
> 
> Of course he did but you don't do a correct simulation of Px: a
> correct simulation of Px is to simulate Px halting as that is how Px
> behaves.
> 
> /Flibble
> 

A correct simulation of Px by H derives the execution trace that I 
specified. Every line of the execution trace of the x86 emulation of Px 
by H precisely corresponds to exactly what the x86 source code of Px 
specifies.

void Px(void (*x)())
{
   (void) H(x, x);
   return;
}

int main()
{
   Output("Input_Halts = ", H(Px, Px));
}

_Px()
[00001256] 55             push ebp
[00001257] 8bec           mov ebp,esp
[00001259] 8b4508         mov eax,[ebp+08]
[0000125c] 50             push eax      // push 2nd arg to H
[0000125d] 8b4d08         mov ecx,[ebp+08]
[00001260] 51             push ecx      // push 1st arg to H
[00001261] e8b0fcffff     call 00000f16 // call H
[00001266] 83c408         add esp,+08
[00001269] 5d             pop ebp
[0000126a] c3             ret
Size in bytes:(0021) [0000126a]

H: Begin Simulation   Execution Trace Stored at:111fcb
Address_of_H:f16
[00001256][00111fb7][00111fbb] 55             push ebp
[00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
[00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
[0000125c][00111fb3][00001256] 50             push eax      // push Px
[0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
[00001260][00111faf][00001256] 51             push ecx      // push Px
[00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped

We can see that the execution trace of the first six instructions of Px 
exactly matches the x86 source-code of Px. We can also see that Px was 
about to call H(Px,Px) again and this would repeat the cycle of the 
first six instructions of Px.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58411

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 20:26 +0100
Message-ID<20221012202602.00006a05@reddwarf.jmc.corp>
In reply to#58410
On Wed, 12 Oct 2022 14:17:35 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 1:30 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 13:25:34 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 1:07 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 13:04:17 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>         
> >>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>>>            
> >>>>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>>>> paragraph looks correct:
> >>>>>>>>
> >>>>>>>>         If H does correctly determine that its correct
> >>>>>>>> simulation of D would never stop running unless aborted,
> >>>>>>>> would it be correct for H to abort this simulation and
> >>>>>>>> report that D specifies a non-halting sequence of
> >>>>>>>> configurations?
> >>>>>>>>
> >>>>>>>> This validates the idea of a simulating halt decider
> >>>>>>>> referenced in this paper.
> >>>>>>>>
> >>>>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Professor Sipser has not had the time to carefully review
> >>>>>>>> this paper presented to him.
> >>>>>>>>
> >>>>>>>> *The exact words posted above have been approved by Michael
> >>>>>>>> Sipser*  
> >>>>>>>
> >>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>>>> detail that you are glossing over is that you do NOT perform a
> >>>>>>> correct simulation for all inputs:
> >>>>>>>            
> >>>>>>
> >>>>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>>>> version. (a) x86utm operating system
> >>>>>> (b) x86 emulator adapted from libx86emu to compile under
> >>>>>> Windows (c) Several halt deciders and their sample inputs
> >>>>>> contained within Halt7.c https://liarparadox.org/2022_10_08.zip
> >>>>>>
> >>>>>> Anyone with sufficient software engineering skill can easily
> >>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
> >>>>>> that Sipser_D remains stuck in infinitely recursive simulation
> >>>>>> unless and until Sipser_H aborts its correct simulation of
> >>>>>> Sipser_D.  
> >>>>>
> >>>>> You chose to not fully address my reply by snipping the
> >>>>> important part so I will give you another chance:
> >>>>>
> >>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>> detail that you are glossing over is that you do NOT perform a
> >>>>> correct simulation for all inputs:
> >>>>>
> >>>>> void Px(void (*x)())
> >>>>> {
> >>>>> 	(void) H(x, x);
> >>>>> 	return;
> >>>>> }
> >>>>>
> >>>>> The correct simulation of Px above is to simulate Px halting.
> >>>>>         
> >>>>
> >>>> Not at all. It must be a correct simulation of the actual input
> >>>> by the simulating halt decider.
> >>>>
> >>>> int main() { H(Px,Px); }
> >>>> (a) The executed H simulates Px that calls a simulated H
> >>>> (b) that simulates Px that calls a simulated H
> >>>> (c) that simulates Px that calls a simulated H ...  
> >>>
> >>> Yes indeed it must be a correct simulation and a correct
> >>> simulation of Px is to simulate Px halting.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> Sipser agreed that the correct simulation of Px by H is the correct
> >> measure of the behavior of Px.  
> > 
> > Of course he did but you don't do a correct simulation of Px: a
> > correct simulation of Px is to simulate Px halting as that is how Px
> > behaves.
> > 
> > /Flibble
> >   
> 
> A correct simulation of Px by H derives the execution trace that I 
> specified. Every line of the execution trace of the x86 emulation of
> Px by H precisely corresponds to exactly what the x86 source code of
> Px specifies.
> 
> void Px(void (*x)())
> {
>    (void) H(x, x);
>    return;
> }
> 
> int main()
> {
>    Output("Input_Halts = ", H(Px, Px));
> }
> 
> _Px()
> [00001256] 55             push ebp
> [00001257] 8bec           mov ebp,esp
> [00001259] 8b4508         mov eax,[ebp+08]
> [0000125c] 50             push eax      // push 2nd arg to H
> [0000125d] 8b4d08         mov ecx,[ebp+08]
> [00001260] 51             push ecx      // push 1st arg to H
> [00001261] e8b0fcffff     call 00000f16 // call H
> [00001266] 83c408         add esp,+08
> [00001269] 5d             pop ebp
> [0000126a] c3             ret
> Size in bytes:(0021) [0000126a]
> 
> H: Begin Simulation   Execution Trace Stored at:111fcb
> Address_of_H:f16
> [00001256][00111fb7][00111fbb] 55             push ebp
> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
> [0000125c][00111fb3][00001256] 50             push eax      // push Px
> [0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
> [00001260][00111faf][00001256] 51             push ecx      // push Px
> [00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
> 
> We can see that the execution trace of the first six instructions of
> Px exactly matches the x86 source-code of Px. We can also see that Px
> was about to call H(Px,Px) again and this would repeat the cycle of
> the first six instructions of Px.

There are various methods of simulating an input: you have chosen an
incorrect method of simulation; if we substitute your H for another H
which uses a correct method of simulation, Px will correctly halt.

An SHD which uses a correct method of simulation would be the Flibble
Signaling Halt Decider (TM).

/Flibble

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


#58412

Fromolcott <polcott2@gmail.com>
Date2022-10-12 14:32 -0500
Message-ID<ti74oq$1igap$3@dont-email.me>
In reply to#58411
On 10/12/2022 2:26 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 14:17:35 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 1:30 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 13:25:34 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> On 10/12/2022 1:07 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 13:04:17 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>       
>>>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>          
>>>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>             
>>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
>>>>>>>>>> paragraph looks correct:
>>>>>>>>>>
>>>>>>>>>>          If H does correctly determine that its correct
>>>>>>>>>> simulation of D would never stop running unless aborted,
>>>>>>>>>> would it be correct for H to abort this simulation and
>>>>>>>>>> report that D specifies a non-halting sequence of
>>>>>>>>>> configurations?
>>>>>>>>>>
>>>>>>>>>> This validates the idea of a simulating halt decider
>>>>>>>>>> referenced in this paper.
>>>>>>>>>>
>>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Professor Sipser has not had the time to carefully review
>>>>>>>>>> this paper presented to him.
>>>>>>>>>>
>>>>>>>>>> *The exact words posted above have been approved by Michael
>>>>>>>>>> Sipser*
>>>>>>>>>
>>>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>>>> correct simulation for all inputs:
>>>>>>>>>             
>>>>>>>>
>>>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>>>>>> version. (a) x86utm operating system
>>>>>>>> (b) x86 emulator adapted from libx86emu to compile under
>>>>>>>> Windows (c) Several halt deciders and their sample inputs
>>>>>>>> contained within Halt7.c https://liarparadox.org/2022_10_08.zip
>>>>>>>>
>>>>>>>> Anyone with sufficient software engineering skill can easily
>>>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
>>>>>>>> that Sipser_D remains stuck in infinitely recursive simulation
>>>>>>>> unless and until Sipser_H aborts its correct simulation of
>>>>>>>> Sipser_D.
>>>>>>>
>>>>>>> You chose to not fully address my reply by snipping the
>>>>>>> important part so I will give you another chance:
>>>>>>>
>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>> correct simulation for all inputs:
>>>>>>>
>>>>>>> void Px(void (*x)())
>>>>>>> {
>>>>>>> 	(void) H(x, x);
>>>>>>> 	return;
>>>>>>> }
>>>>>>>
>>>>>>> The correct simulation of Px above is to simulate Px halting.
>>>>>>>          
>>>>>>
>>>>>> Not at all. It must be a correct simulation of the actual input
>>>>>> by the simulating halt decider.
>>>>>>
>>>>>> int main() { H(Px,Px); }
>>>>>> (a) The executed H simulates Px that calls a simulated H
>>>>>> (b) that simulates Px that calls a simulated H
>>>>>> (c) that simulates Px that calls a simulated H ...
>>>>>
>>>>> Yes indeed it must be a correct simulation and a correct
>>>>> simulation of Px is to simulate Px halting.
>>>>>
>>>>> /Flibble
>>>>>       
>>>>
>>>> Sipser agreed that the correct simulation of Px by H is the correct
>>>> measure of the behavior of Px.
>>>
>>> Of course he did but you don't do a correct simulation of Px: a
>>> correct simulation of Px is to simulate Px halting as that is how Px
>>> behaves.
>>>
>>> /Flibble
>>>    
>>
>> A correct simulation of Px by H derives the execution trace that I
>> specified. Every line of the execution trace of the x86 emulation of
>> Px by H precisely corresponds to exactly what the x86 source code of
>> Px specifies.
>>
>> void Px(void (*x)())
>> {
>>     (void) H(x, x);
>>     return;
>> }
>>
>> int main()
>> {
>>     Output("Input_Halts = ", H(Px, Px));
>> }
>>
>> _Px()
>> [00001256] 55             push ebp
>> [00001257] 8bec           mov ebp,esp
>> [00001259] 8b4508         mov eax,[ebp+08]
>> [0000125c] 50             push eax      // push 2nd arg to H
>> [0000125d] 8b4d08         mov ecx,[ebp+08]
>> [00001260] 51             push ecx      // push 1st arg to H
>> [00001261] e8b0fcffff     call 00000f16 // call H
>> [00001266] 83c408         add esp,+08
>> [00001269] 5d             pop ebp
>> [0000126a] c3             ret
>> Size in bytes:(0021) [0000126a]
>>
>> H: Begin Simulation   Execution Trace Stored at:111fcb
>> Address_of_H:f16
>> [00001256][00111fb7][00111fbb] 55             push ebp
>> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
>> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
>> [0000125c][00111fb3][00001256] 50             push eax      // push Px
>> [0000125d][00111fb3][00001256] 8b4d08         mov ecx,[ebp+08]
>> [00001260][00111faf][00001256] 51             push ecx      // push Px
>> [00001261][00111fab][00001266] e8b0fcffff     call 00000f16 // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> We can see that the execution trace of the first six instructions of
>> Px exactly matches the x86 source-code of Px. We can also see that Px
>> was about to call H(Px,Px) again and this would repeat the cycle of
>> the first six instructions of Px.
> 
> There are various methods of simulating an input: you have chosen an
> incorrect method of simulation; if we substitute your H for another H
> which uses a correct method of simulation, Px will correctly halt.
> 
> An SHD which uses a correct method of simulation would be the Flibble
> Signaling Halt Decider (TM).
> 
> /Flibble
> 

Everyone that is sufficiently technically competent at software 
engineering can verify that H does correctly simulate Px on the basis 
that the line-by-line execution trace of the simulation of Px by H 
exactly matches the line-by-line x86 source-code of Px.

People that are not sufficiently technically competent might use 
double-talk, misdirection and vagueness to provide a baseless rebuttal.

-- 
Copyright 2022 Pete Olcott "Talent hits a target no one else can hit;
Genius hits a target no one else can see." Arthur Schopenhauer

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


#58414

FromMr Flibble <flibble@reddwarf.jmc.corp>
Date2022-10-12 20:50 +0100
Message-ID<20221012205004.000057f8@reddwarf.jmc.corp>
In reply to#58412
On Wed, 12 Oct 2022 14:32:41 -0500
olcott <polcott2@gmail.com> wrote:

> On 10/12/2022 2:26 PM, Mr Flibble wrote:
> > On Wed, 12 Oct 2022 14:17:35 -0500
> > olcott <polcott2@gmail.com> wrote:
> >   
> >> On 10/12/2022 1:30 PM, Mr Flibble wrote:  
> >>> On Wed, 12 Oct 2022 13:25:34 -0500
> >>> olcott <polcott2@gmail.com> wrote:
> >>>      
> >>>> On 10/12/2022 1:07 PM, Mr Flibble wrote:  
> >>>>> On Wed, 12 Oct 2022 13:04:17 -0500
> >>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>         
> >>>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:  
> >>>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
> >>>>>>> olcott <none-ya@beez-waxes.com> wrote:
> >>>>>>>            
> >>>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:  
> >>>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
> >>>>>>>>> olcott <polcott2@gmail.com> wrote:
> >>>>>>>>>               
> >>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
> >>>>>>>>>> paragraph looks correct:
> >>>>>>>>>>
> >>>>>>>>>>          If H does correctly determine that its correct
> >>>>>>>>>> simulation of D would never stop running unless aborted,
> >>>>>>>>>> would it be correct for H to abort this simulation and
> >>>>>>>>>> report that D specifies a non-halting sequence of
> >>>>>>>>>> configurations?
> >>>>>>>>>>
> >>>>>>>>>> This validates the idea of a simulating halt decider
> >>>>>>>>>> referenced in this paper.
> >>>>>>>>>>
> >>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
> >>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Professor Sipser has not had the time to carefully review
> >>>>>>>>>> this paper presented to him.
> >>>>>>>>>>
> >>>>>>>>>> *The exact words posted above have been approved by Michael
> >>>>>>>>>> Sipser*  
> >>>>>>>>>
> >>>>>>>>> Whilst the paragraph you sent to Sipser is correct the
> >>>>>>>>> crucial detail that you are glossing over is that you do
> >>>>>>>>> NOT perform a correct simulation for all inputs:
> >>>>>>>>>               
> >>>>>>>>
> >>>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
> >>>>>>>> version. (a) x86utm operating system
> >>>>>>>> (b) x86 emulator adapted from libx86emu to compile under
> >>>>>>>> Windows (c) Several halt deciders and their sample inputs
> >>>>>>>> contained within Halt7.c
> >>>>>>>> https://liarparadox.org/2022_10_08.zip
> >>>>>>>>
> >>>>>>>> Anyone with sufficient software engineering skill can easily
> >>>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
> >>>>>>>> that Sipser_D remains stuck in infinitely recursive
> >>>>>>>> simulation unless and until Sipser_H aborts its correct
> >>>>>>>> simulation of Sipser_D.  
> >>>>>>>
> >>>>>>> You chose to not fully address my reply by snipping the
> >>>>>>> important part so I will give you another chance:
> >>>>>>>
> >>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
> >>>>>>> detail that you are glossing over is that you do NOT perform a
> >>>>>>> correct simulation for all inputs:
> >>>>>>>
> >>>>>>> void Px(void (*x)())
> >>>>>>> {
> >>>>>>> 	(void) H(x, x);
> >>>>>>> 	return;
> >>>>>>> }
> >>>>>>>
> >>>>>>> The correct simulation of Px above is to simulate Px halting.
> >>>>>>>            
> >>>>>>
> >>>>>> Not at all. It must be a correct simulation of the actual input
> >>>>>> by the simulating halt decider.
> >>>>>>
> >>>>>> int main() { H(Px,Px); }
> >>>>>> (a) The executed H simulates Px that calls a simulated H
> >>>>>> (b) that simulates Px that calls a simulated H
> >>>>>> (c) that simulates Px that calls a simulated H ...  
> >>>>>
> >>>>> Yes indeed it must be a correct simulation and a correct
> >>>>> simulation of Px is to simulate Px halting.
> >>>>>
> >>>>> /Flibble
> >>>>>         
> >>>>
> >>>> Sipser agreed that the correct simulation of Px by H is the
> >>>> correct measure of the behavior of Px.  
> >>>
> >>> Of course he did but you don't do a correct simulation of Px: a
> >>> correct simulation of Px is to simulate Px halting as that is how
> >>> Px behaves.
> >>>
> >>> /Flibble
> >>>      
> >>
> >> A correct simulation of Px by H derives the execution trace that I
> >> specified. Every line of the execution trace of the x86 emulation
> >> of Px by H precisely corresponds to exactly what the x86 source
> >> code of Px specifies.
> >>
> >> void Px(void (*x)())
> >> {
> >>     (void) H(x, x);
> >>     return;
> >> }
> >>
> >> int main()
> >> {
> >>     Output("Input_Halts = ", H(Px, Px));
> >> }
> >>
> >> _Px()
> >> [00001256] 55             push ebp
> >> [00001257] 8bec           mov ebp,esp
> >> [00001259] 8b4508         mov eax,[ebp+08]
> >> [0000125c] 50             push eax      // push 2nd arg to H
> >> [0000125d] 8b4d08         mov ecx,[ebp+08]
> >> [00001260] 51             push ecx      // push 1st arg to H
> >> [00001261] e8b0fcffff     call 00000f16 // call H
> >> [00001266] 83c408         add esp,+08
> >> [00001269] 5d             pop ebp
> >> [0000126a] c3             ret
> >> Size in bytes:(0021) [0000126a]
> >>
> >> H: Begin Simulation   Execution Trace Stored at:111fcb
> >> Address_of_H:f16
> >> [00001256][00111fb7][00111fbb] 55             push ebp
> >> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
> >> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
> >> [0000125c][00111fb3][00001256] 50             push eax      //
> >> push Px [0000125d][00111fb3][00001256] 8b4d08         mov
> >> ecx,[ebp+08] [00001260][00111faf][00001256] 51             push
> >> ecx      // push Px [00001261][00111fab][00001266] e8b0fcffff
> >> call 00000f16 // call H H: Infinitely Recursive Simulation
> >> Detected Simulation Stopped
> >>
> >> We can see that the execution trace of the first six instructions
> >> of Px exactly matches the x86 source-code of Px. We can also see
> >> that Px was about to call H(Px,Px) again and this would repeat the
> >> cycle of the first six instructions of Px.  
> > 
> > There are various methods of simulating an input: you have chosen an
> > incorrect method of simulation; if we substitute your H for another
> > H which uses a correct method of simulation, Px will correctly halt.
> > 
> > An SHD which uses a correct method of simulation would be the
> > Flibble Signaling Halt Decider (TM).
> > 
> > /Flibble
> >   
> 
> Everyone that is sufficiently technically competent at software 
> engineering can verify that H does correctly simulate Px on the basis 
> that the line-by-line execution trace of the simulation of Px by H 
> exactly matches the line-by-line x86 source-code of Px.
> 
> People that are not sufficiently technically competent might use 
> double-talk, misdirection and vagueness to provide a baseless
> rebuttal.

A valid halt decider MUST return a decision to its caller, in this case
Px, in finite time; Px will then halt, correctly.  Your H does not do
this so is not a valid halt decider.

/Flibble

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


#58416

Fromolcott <none-ya@beez-waxes.com>
Date2022-10-12 15:07 -0500
Message-ID<ti76q1$l87$1@gioia.aioe.org>
In reply to#58414
On 10/12/2022 2:50 PM, Mr Flibble wrote:
> On Wed, 12 Oct 2022 14:32:41 -0500
> olcott <polcott2@gmail.com> wrote:
> 
>> On 10/12/2022 2:26 PM, Mr Flibble wrote:
>>> On Wed, 12 Oct 2022 14:17:35 -0500
>>> olcott <polcott2@gmail.com> wrote:
>>>    
>>>> On 10/12/2022 1:30 PM, Mr Flibble wrote:
>>>>> On Wed, 12 Oct 2022 13:25:34 -0500
>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>       
>>>>>> On 10/12/2022 1:07 PM, Mr Flibble wrote:
>>>>>>> On Wed, 12 Oct 2022 13:04:17 -0500
>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>          
>>>>>>>> On 10/12/2022 12:52 PM, Mr Flibble wrote:
>>>>>>>>> On Wed, 12 Oct 2022 12:38:31 -0500
>>>>>>>>> olcott <none-ya@beez-waxes.com> wrote:
>>>>>>>>>             
>>>>>>>>>> On 10/12/2022 12:24 PM, Mr Flibble wrote:
>>>>>>>>>>> On Wed, 12 Oct 2022 10:08:20 -0500
>>>>>>>>>>> olcott <polcott2@gmail.com> wrote:
>>>>>>>>>>>                
>>>>>>>>>>>> Professor Michael Sipser of MIT said that this verbatim
>>>>>>>>>>>> paragraph looks correct:
>>>>>>>>>>>>
>>>>>>>>>>>>           If H does correctly determine that its correct
>>>>>>>>>>>> simulation of D would never stop running unless aborted,
>>>>>>>>>>>> would it be correct for H to abort this simulation and
>>>>>>>>>>>> report that D specifies a non-halting sequence of
>>>>>>>>>>>> configurations?
>>>>>>>>>>>>
>>>>>>>>>>>> This validates the idea of a simulating halt decider
>>>>>>>>>>>> referenced in this paper.
>>>>>>>>>>>>
>>>>>>>>>>>> *Rebutting the Sipser Halting Problem Proof*
>>>>>>>>>>>> https://www.researchgate.net/publication/364302709_Rebutting_the_Sipser_Halting_Problem_Proof
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Professor Sipser has not had the time to carefully review
>>>>>>>>>>>> this paper presented to him.
>>>>>>>>>>>>
>>>>>>>>>>>> *The exact words posted above have been approved by Michael
>>>>>>>>>>>> Sipser*
>>>>>>>>>>>
>>>>>>>>>>> Whilst the paragraph you sent to Sipser is correct the
>>>>>>>>>>> crucial detail that you are glossing over is that you do
>>>>>>>>>>> NOT perform a correct simulation for all inputs:
>>>>>>>>>>>                
>>>>>>>>>>
>>>>>>>>>> Complete halt deciding system (Visual Studio Project) Sipser
>>>>>>>>>> version. (a) x86utm operating system
>>>>>>>>>> (b) x86 emulator adapted from libx86emu to compile under
>>>>>>>>>> Windows (c) Several halt deciders and their sample inputs
>>>>>>>>>> contained within Halt7.c
>>>>>>>>>> https://liarparadox.org/2022_10_08.zip
>>>>>>>>>>
>>>>>>>>>> Anyone with sufficient software engineering skill can easily
>>>>>>>>>> verify that Sipser_D is correctly simulated by Sipser_H and
>>>>>>>>>> that Sipser_D remains stuck in infinitely recursive
>>>>>>>>>> simulation unless and until Sipser_H aborts its correct
>>>>>>>>>> simulation of Sipser_D.
>>>>>>>>>
>>>>>>>>> You chose to not fully address my reply by snipping the
>>>>>>>>> important part so I will give you another chance:
>>>>>>>>>
>>>>>>>>> Whilst the paragraph you sent to Sipser is correct the crucial
>>>>>>>>> detail that you are glossing over is that you do NOT perform a
>>>>>>>>> correct simulation for all inputs:
>>>>>>>>>
>>>>>>>>> void Px(void (*x)())
>>>>>>>>> {
>>>>>>>>> 	(void) H(x, x);
>>>>>>>>> 	return;
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The correct simulation of Px above is to simulate Px halting.
>>>>>>>>>             
>>>>>>>>
>>>>>>>> Not at all. It must be a correct simulation of the actual input
>>>>>>>> by the simulating halt decider.
>>>>>>>>
>>>>>>>> int main() { H(Px,Px); }
>>>>>>>> (a) The executed H simulates Px that calls a simulated H
>>>>>>>> (b) that simulates Px that calls a simulated H
>>>>>>>> (c) that simulates Px that calls a simulated H ...
>>>>>>>
>>>>>>> Yes indeed it must be a correct simulation and a correct
>>>>>>> simulation of Px is to simulate Px halting.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>          
>>>>>>
>>>>>> Sipser agreed that the correct simulation of Px by H is the
>>>>>> correct measure of the behavior of Px.
>>>>>
>>>>> Of course he did but you don't do a correct simulation of Px: a
>>>>> correct simulation of Px is to simulate Px halting as that is how
>>>>> Px behaves.
>>>>>
>>>>> /Flibble
>>>>>       
>>>>
>>>> A correct simulation of Px by H derives the execution trace that I
>>>> specified. Every line of the execution trace of the x86 emulation
>>>> of Px by H precisely corresponds to exactly what the x86 source
>>>> code of Px specifies.
>>>>
>>>> void Px(void (*x)())
>>>> {
>>>>      (void) H(x, x);
>>>>      return;
>>>> }
>>>>
>>>> int main()
>>>> {
>>>>      Output("Input_Halts = ", H(Px, Px));
>>>> }
>>>>
>>>> _Px()
>>>> [00001256] 55             push ebp
>>>> [00001257] 8bec           mov ebp,esp
>>>> [00001259] 8b4508         mov eax,[ebp+08]
>>>> [0000125c] 50             push eax      // push 2nd arg to H
>>>> [0000125d] 8b4d08         mov ecx,[ebp+08]
>>>> [00001260] 51             push ecx      // push 1st arg to H
>>>> [00001261] e8b0fcffff     call 00000f16 // call H
>>>> [00001266] 83c408         add esp,+08
>>>> [00001269] 5d             pop ebp
>>>> [0000126a] c3             ret
>>>> Size in bytes:(0021) [0000126a]
>>>>
>>>> H: Begin Simulation   Execution Trace Stored at:111fcb
>>>> Address_of_H:f16
>>>> [00001256][00111fb7][00111fbb] 55             push ebp
>>>> [00001257][00111fb7][00111fbb] 8bec           mov ebp,esp
>>>> [00001259][00111fb7][00111fbb] 8b4508         mov eax,[ebp+08]
>>>> [0000125c][00111fb3][00001256] 50             push eax      //
>>>> push Px [0000125d][00111fb3][00001256] 8b4d08         mov
>>>> ecx,[ebp+08] [00001260][00111faf][00001256] 51             push
>>>> ecx      // push Px [00001261][00111fab][00001266] e8b0fcffff
>>>> call 00000f16 // call H H: Infinitely Recursive Simulation
>>>> Detected Simulation Stopped
>>>>
>>>> We can see that the execution trace of the first six instructions
>>>> of Px exactly matches the x86 source-code of Px. We can also see
>>>> that Px was about to call H(Px,Px) again and this would repeat the
>>>> cycle of the first six instructions of Px.
>>>
>>> There are various methods of simulating an input: you have chosen an
>>> incorrect method of simulation; if we substitute your H for another
>>> H which uses a correct method of simulation, Px will correctly halt.
>>>
>>> An SHD which uses a correct method of simulation would be the
>>> Flibble Signaling Halt Decider (TM).
>>>
>>> /Flibble
>>>    
>>
>> Everyone that is sufficiently technically competent at software
>> engineering can verify that H does correctly simulate Px on the basis
>> that the line-by-line execution trace of the simulation of Px by H
>> exactly matches the line-by-line x86 source-code of Px.
>>
>> People that are not sufficiently technically competent might use
>> double-talk, misdirection and vagueness to provide a baseless
>> rebuttal.
> 
> A valid halt decider MUST return a decision to its caller, in this case
> Px, in finite time; Px will then halt, correctly.  Your H does not do
> this so is not a valid halt decider.
> 
> /Flibble
> 

Subject matter experts would disagree on the basis of seeing that the 
call to H from Px is never executed and by examining the simulated 
execution trace of Px by H compared to the x86 source-code of Px.

-- 
Copyright 2022 Pete Olcott

"Talent hits a target no one else can hit;
  Genius hits a target no one else can see."
  Arthur Schopenhauer

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


#58413

From"dklei...@gmail.com" <dkleinecke@gmail.com>
Date2022-10-12 12:32 -0700
Message-ID<bffc5471-51c7-488d-aa6c-c42df024a8e0n@googlegroups.com>
In reply to#58398
On Wednesday, October 12, 2022 at 8:08:23 AM UTC-7, olcott wrote:
> Professor Michael Sipser of MIT said that this verbatim paragraph looks 
> correct: 
> 
> If H does correctly determine that its correct simulation 
> of D would never stop running unless aborted, would it be 
> correct for H to abort this simulation and report that D 
> specifies a non-halting sequence of configurations? 
> 
You are attempting to use the argument from authority. 
That's a loser. My opinion is just as good as Sipser's.
But
Cleaning up you statement:
"If H determines that its simulation of D would never 
stop running, might H abort the simulation and report 
that D specifies a non-halting machine? "

This is true. But H cannot determine in every case that
the simulation will not stop running and therefore does 
not itself alwaysstop running.

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


Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13  Next page →

Back to top | Article view | comp.theory


csiph-web