Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #59471 > unrolled thread
| Started by | olcott <polcott2@gmail.com> |
|---|---|
| First post | 2022-11-11 09:28 -0600 |
| Last post | 2022-11-12 11:14 -0500 |
| Articles | 20 on this page of 164 — 12 participants |
Back to article view | Back to comp.theory
Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 09:28 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 10:57 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-11 18:36 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 13:43 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 13:16 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 14:30 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 13:39 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 16:07 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 15:15 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 16:44 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-11 21:54 +0000
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 16:44 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 18:25 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-11 23:55 +0000
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 17:59 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 19:24 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 18:46 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 21:15 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 20:35 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 21:45 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 20:48 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 21:56 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 22:00 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:02 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 08:43 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:06 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 15:12 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:52 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 10:20 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 11:47 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 22:17 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:08 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 08:55 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:02 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 14:09 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:32 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 14:41 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:52 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 15:03 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:26 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 15:38 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:59 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 10:06 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 11:21 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 09:50 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 11:26 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 11:00 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 12:59 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 12:16 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 13:24 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 18:42 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 14:00 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 19:26 +0000
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-12 13:37 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 14:54 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-12 12:45 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 13:57 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-12 13:04 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 14:21 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 13:36 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 15:01 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-12 14:07 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 15:26 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-12 14:35 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 16:28 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 15:59 -0600
Olcottaholics anonymous Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-11-12 21:25 +0000
E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-12 16:04 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-12 17:26 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-12 16:33 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-12 17:55 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-12 17:38 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-12 19:02 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-12 19:31 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-12 21:30 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-12 22:00 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-12 23:38 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-12 23:04 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 08:00 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-13 09:39 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 14:34 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-13 13:49 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 15:38 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 14:51 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <news.x.richarddamon@xoxy.net> - 2022-11-13 16:02 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 15:16 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 16:59 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 16:08 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-13 22:25 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally Dennis Bush <dbush.mobile@gmail.com> - 2022-11-13 14:33 -0800
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 16:42 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 18:14 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 17:26 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-13 23:52 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-13 18:00 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 19:33 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 19:29 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-14 19:27 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-14 13:44 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-14 21:53 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-14 21:53 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-15 17:45 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-15 12:00 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-16 20:04 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-17 17:14 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-17 11:25 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 17:36 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 19:36 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 18:07 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-13 23:30 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 19:37 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2022-11-14 11:02 +0100
Re: E correctly simulated by H would never reach its last instruction and terminate normally wij <wyniijj5@gmail.com> - 2022-11-14 03:44 -0800
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mike Terry <news.dead.person.stones@darjeeling.plus.com> - 2022-11-14 16:17 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally André G. Isaak <agisaak@gm.invalid> - 2022-11-14 11:34 -0700
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-14 13:20 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-14 21:53 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <none-ya@beez-waxes.com> - 2022-11-14 20:00 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-14 21:52 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 18:04 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 17:20 -0600
Re: E correctly simulated by H would never reach its last instruction and terminate normally Richard Damon <Richard@Damon-Family.org> - 2022-11-13 19:43 -0500
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-13 05:40 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-13 04:17 +0000
Re: E correctly simulated by H would never reach its last instruction and terminate normally olcott <polcott2@gmail.com> - 2022-11-13 12:35 -0600
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 18:19 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 13:33 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 09:51 -0600
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 14:50 +0000
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 16:37 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 18:20 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 17:39 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 18:48 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 18:05 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 19:29 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 18:51 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 21:25 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 20:36 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 21:51 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 20:57 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-11 22:25 -0500
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 21:36 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:11 -0500
Re: Simulating halt decider applied to a simpler input Jeff Barnett <jbb@notatt.com> - 2022-11-11 12:56 -0700
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 14:19 -0600
Re: Simulating halt decider applied to a simpler input Jeff Barnett <jbb@notatt.com> - 2022-11-11 18:43 -0700
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 21:06 -0600
Re: Simulating halt decider applied to a simpler input olcott <none-ya@beez-waxes.com> - 2022-11-11 20:21 -0600
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-11 23:35 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:15 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 14:31 +0000
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 08:35 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 09:58 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 15:16 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:41 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 15:52 +0000
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 11:09 -0500
Re: Simulating halt decider applied to a simpler input Mr Flibble <flibble@reddwarf.jmc.corp> - 2022-11-12 16:42 +0000
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 11:04 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 12:07 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 09:27 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 10:46 -0500
Re: Simulating halt decider applied to a simpler input olcott <polcott2@gmail.com> - 2022-11-12 10:02 -0600
Re: Simulating halt decider applied to a simpler input Richard Damon <Richard@Damon-Family.org> - 2022-11-12 11:14 -0500
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-11-12 15:38 +0000 |
| Message-ID | <20221112153800.0000755b@reddwarf.jmc.corp> |
| In reply to | #59536 |
On Sat, 12 Nov 2022 10:26:30 -0500 Richard Damon <Richard@Damon-Family.org> wrote: > All you are showing is that a "Simulating Halting Decider" that is > based on unconditional simulation is a failed method of decision. The corollary being that a simulating halting decider proves that what I am saying is correct; the onus is on you to prove that a SHD is not a valid halt decider type. /Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 10:59 -0500 |
| Message-ID | <xpPbL.69251$Jjx8.4679@fx15.iad> |
| In reply to | #59538 |
On 11/12/22 10:38 AM, Mr Flibble wrote: > On Sat, 12 Nov 2022 10:26:30 -0500 > Richard Damon <Richard@Damon-Family.org> wrote: >> All you are showing is that a "Simulating Halting Decider" that is >> based on unconditional simulation is a failed method of decision. > > The corollary being that a simulating halting decider proves that what > I am saying is correct; the onus is on you to prove that a SHD is not a > valid halt decider type. > > /Flibble > Nope, the onus is on you to prove your claim, which you haven't done. Note, I am not saying that you can't build a PARTIAL Halt Decider based on simulation, just that they can't be a COMPLETE Halt Decider that is able to decide on ALL inputs, since there can't exist a Halt Decider, of ANY type, that can do that. Note, the proof that it doesn't can be the simple Linz proof, as presuming you are claiming that a Simulating Halt Decider IS actually also a Halt Decider, then its definition of correct is the behavior of the actual input, and H^ <H^> is shown to halt if H <H^ <H^ -> qn, so that answer is NOT correct, BY DEFINITION. If you aren't claiming that a Simulating Halt Decider is actually a Halt Decider but something else, then they aren't applicable to the Halting Problem, as that only deals with Halting Deciders.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-11-12 10:06 -0600 |
| Message-ID | <tkogb4$16k3v$5@dont-email.me> |
| In reply to | #59536 |
On 11/12/2022 9:26 AM, Richard Damon wrote:
> On 11/12/22 10:03 AM, Mr Flibble wrote:
>> On Sat, 12 Nov 2022 09:52:12 -0500
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>
>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>
>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>
>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Nope, no self reference.
>>>>>>>>>
>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>> directly express a reference.
>>>>>>>>
>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>> different way.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>> actually a decider.
>>>>>>>
>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>> description of itself, which is also simple to make.
>>>>>>>
>>>>>>> When run it makes a second copy of its description, and then
>>>>>>> calls the decider.
>>>>>>>
>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>
>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>> the requirements.
>>>>>>>
>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>> copy of something that just happens to be its own description.
>>>>>>>
>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>> out be be impossible, so no such program exists.
>>>>>>
>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>> not due to self reference or infinite copies but because the input
>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>> error that I have identified is different: it is an error of self
>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>> fact that the input references a decider rather than being related
>>>>>> to what the input does with the decision result of a decider.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> But the infinite copies is a error in the Decider, not in
>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>> infinite copies, then the decided just doesn't meet its
>>>>> requirements.
>>>>>
>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>> if H is actualy a Turing Machine.
>>>>>
>>>>> All your declaration of a "Category Error" here is doing is
>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>> be of a HIGHER order logic system, which means H fails the
>>>>> requirement to be the needed decider.
>>>>
>>>> In which case we get infinite turning machines all the way down: yet
>>>> another manifestation of the category error I have identified.
>>>>
>>>> /Flibble
>>>
>>> Where are infinite machines? There is ONE machine being run, either H
>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>> simulations we have just shown that H was defective because it failed
>>> to answer in finite time.
>>>
>>> This isn't a category error, but a design error in H.
>>>
>>> Note, when we start H, there is exactly two machines present in
>>> representation on the tape, and two is much smaller than infinity.
>>
>> Nope, if,
>>
>> a) H is a copy, and
>> b) H is a Turing Machine, and
>> c) D is an input into H, and
>> d) D references H, and
>> e) H references D,
>>
>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>> all the way down: a manifestation of the category error I have
>> identified.
>>
>> /Flibble
>>
>
> H doesn't reference D, in fact it CAN'T because D doesn't exist when H
> is created. You can't actually reference something that doesn't exist.
void D(void (*x)())
{
int Halt_Status = H(x, x);
if (Halt_Status)
HERE: goto HERE;
return;
}
So if I smash a Boston cream pie in your face you will say blub, blub
blub (speaking through pie dripping from your face) there is no pie.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 11:21 -0500 |
| Message-ID | <AKPbL.71109$Jjx8.70154@fx15.iad> |
| In reply to | #59547 |
On 11/12/22 11:06 AM, olcott wrote:
> On 11/12/2022 9:26 AM, Richard Damon wrote:
>> On 11/12/22 10:03 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>
>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>
>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>> directly express a reference.
>>>>>>>>>
>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>> different way.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>> actually a decider.
>>>>>>>>
>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>
>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>> calls the decider.
>>>>>>>>
>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>
>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>> the requirements.
>>>>>>>>
>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>
>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>
>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>> error that I have identified is different: it is an error of self
>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>> fact that the input references a decider rather than being related
>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>> requirements.
>>>>>>
>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>> if H is actualy a Turing Machine.
>>>>>>
>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>> requirement to be the needed decider.
>>>>>
>>>>> In which case we get infinite turning machines all the way down: yet
>>>>> another manifestation of the category error I have identified.
>>>>>
>>>>> /Flibble
>>>>
>>>> Where are infinite machines? There is ONE machine being run, either H
>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>> simulations we have just shown that H was defective because it failed
>>>> to answer in finite time.
>>>>
>>>> This isn't a category error, but a design error in H.
>>>>
>>>> Note, when we start H, there is exactly two machines present in
>>>> representation on the tape, and two is much smaller than infinity.
>>>
>>> Nope, if,
>>>
>>> a) H is a copy, and
>>> b) H is a Turing Machine, and
>>> c) D is an input into H, and
>>> d) D references H, and
>>> e) H references D,
>>>
>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>> all the way down: a manifestation of the category error I have
>>> identified.
>>>
>>> /Flibble
>>>
>>
>> H doesn't reference D, in fact it CAN'T because D doesn't exist when H
>> is created. You can't actually reference something that doesn't exist.
> void D(void (*x)())
> {
> int Halt_Status = H(x, x);
> if (Halt_Status)
> HERE: goto HERE;
> return;
> }
>
> So if I smash a Boston cream pie in your face you will say blub, blub
> blub (speaking through pie dripping from your face) there is no pie.
>
So, you admit that you don't understand what you are saying as you
respond with an irrelevant comment.
Juar shows the utter weakness of your position.
I guess this adds another word to your list of things you don't
understand, "Reference".
Sorry, you are just too stupid to be doing this.
If you want to prove otherwise, actually try to SHOW what you are saying
is true.
The liar resorts to just trying to put down his opponent, since he can't
deal with their words. I show your errors, you just rant that I must be
wrong since you don't understand how to even actually attempt to prove
your statement.
Maybe the issue is you know you can't do it, so you think you are being
deviously deceptive by pointing out irrelevant details, but it actually
just shows your stupidity, as most people are smarter than you think
they are (at least those you are trying to persuade).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-11-12 09:50 -0600 |
| Message-ID | <tkofba$16k3v$2@dont-email.me> |
| In reply to | #59532 |
On 11/12/2022 9:03 AM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 09:52:12 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>
>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>> {
>>>>>>>>>>> H(x, x);
>>>>>>>>>>> }
>>>>>>>>>>>
>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>
>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>> INVALID INPUT.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> Nope, no self reference.
>>>>>>>>
>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>> directly express a reference.
>>>>>>>
>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>> different way.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>> actually a decider.
>>>>>>
>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>> program is simple to make from it, and is given one copy of the
>>>>>> description of itself, which is also simple to make.
>>>>>>
>>>>>> When run it makes a second copy of its description, and then
>>>>>> calls the decider.
>>>>>>
>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>> infinite loop, the decider is just wrong.
>>>>>>
>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>> the requirements.
>>>>>>
>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>> copy of something that just happens to be its own description.
>>>>>>
>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>> out be be impossible, so no such program exists.
>>>>>
>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>> not due to self reference or infinite copies but because the input
>>>>> tries to do the opposite of what the decider decides; the category
>>>>> error that I have identified is different: it is an error of self
>>>>> reference and/or infinite copies; it is an error related to the
>>>>> fact that the input references a decider rather than being related
>>>>> to what the input does with the decision result of a decider.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> But the infinite copies is a error in the Decider, not in
>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>> ANY input and answer in finite time, If an input causes it to make
>>>> infinite copies, then the decided just doesn't meet its
>>>> requirements.
>>>>
>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>> if H is actualy a Turing Machine.
>>>>
>>>> All your declaration of a "Category Error" here is doing is
>>>> admitting that your H can't actually be a Turing Machine, but must
>>>> be of a HIGHER order logic system, which means H fails the
>>>> requirement to be the needed decider.
>>>
>>> In which case we get infinite turning machines all the way down: yet
>>> another manifestation of the category error I have identified.
>>>
>>> /Flibble
>>>
>>
>> Where are infinite machines? There is ONE machine being run, either H
>> or D, and it SIMULATING others, and if we get an infinite sequence of
>> simulations we have just shown that H was defective because it failed
>> to answer in finite time.
>>
>> This isn't a category error, but a design error in H.
>>
>> Note, when we start H, there is exactly two machines present in
>> representation on the tape, and two is much smaller than infinity.
>
> Nope, if,
>
> a) H is a copy, and
> b) H is a Turing Machine, and
> c) D is an input into H, and
> d) D references H, and
> e) H references D,
>
> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
> all the way down: a manifestation of the category error I have
> identified.
>
> /Flibble
>
void E(void (*x)())
{
H(x, x);
}
The point is
that D correctly simulated by H would never reach its own last
instruction and terminate normally after 1 to ∞ steps of correct simulation.
When H returns 0 to main() it is indicating
that D correctly simulated by H would never reach its own last
instruction and terminate normally after 1 to ∞ steps of correct 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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 11:26 -0500 |
| Message-ID | <6PPbL.71121$Jjx8.38057@fx15.iad> |
| In reply to | #59541 |
On 11/12/22 10:50 AM, olcott wrote:
> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>> On Sat, 12 Nov 2022 09:52:12 -0500
>> Richard Damon <Richard@Damon-Family.org> wrote:
>>
>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>
>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>> {
>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>> }
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>
>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>
>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Nope, no self reference.
>>>>>>>>>
>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>> directly express a reference.
>>>>>>>>
>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>> different way.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>> actually a decider.
>>>>>>>
>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>> description of itself, which is also simple to make.
>>>>>>>
>>>>>>> When run it makes a second copy of its description, and then
>>>>>>> calls the decider.
>>>>>>>
>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>
>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>> the requirements.
>>>>>>>
>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>> copy of something that just happens to be its own description.
>>>>>>>
>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>> out be be impossible, so no such program exists.
>>>>>>
>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>> not due to self reference or infinite copies but because the input
>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>> error that I have identified is different: it is an error of self
>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>> fact that the input references a decider rather than being related
>>>>>> to what the input does with the decision result of a decider.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> But the infinite copies is a error in the Decider, not in
>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>> infinite copies, then the decided just doesn't meet its
>>>>> requirements.
>>>>>
>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>> if H is actualy a Turing Machine.
>>>>>
>>>>> All your declaration of a "Category Error" here is doing is
>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>> be of a HIGHER order logic system, which means H fails the
>>>>> requirement to be the needed decider.
>>>>
>>>> In which case we get infinite turning machines all the way down: yet
>>>> another manifestation of the category error I have identified.
>>>>
>>>> /Flibble
>>>
>>> Where are infinite machines? There is ONE machine being run, either H
>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>> simulations we have just shown that H was defective because it failed
>>> to answer in finite time.
>>>
>>> This isn't a category error, but a design error in H.
>>>
>>> Note, when we start H, there is exactly two machines present in
>>> representation on the tape, and two is much smaller than infinity.
>>
>> Nope, if,
>>
>> a) H is a copy, and
>> b) H is a Turing Machine, and
>> c) D is an input into H, and
>> d) D references H, and
>> e) H references D,
>>
>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>> all the way down: a manifestation of the category error I have
>> identified.
>>
>> /Flibble
>>
>
> void E(void (*x)())
> {
> H(x, x);
> }
>
> The point is
> that D correctly simulated by H would never reach its own last
> instruction and terminate normally after 1 to ∞ steps of correct
> simulation.
>
> When H returns 0 to main() it is indicating
>
> that D correctly simulated by H would never reach its own last
> instruction and terminate normally after 1 to ∞ steps of correct
> simulation.
>
Except D is NOT correctly simulated by H, so that is a incorrect
statement. When it is correctly simulated by something other than H, it
will come to a final state, showing your statement is wrong.
Unless you admit that H isn't a Halt Decider, and just a POOP decider,
thn you statment is just FALSE.
You lie by trying to make H be multiple different programs at the same
time, which shows your ignorance of the rules of the system.
D (or E) is DEFINED to be calling the H that is claimed to be correctly
deciding it, which is the one with the abort in it,
Looking at a D that uses a different H is just showing you are a
deceptive liar who doesn't understand the rules of the game he claimes
to be playing.
You are just showing you utter lack of knowledge of the basic rules of
logic.
You are obviously too stupid to understand what you are talking about.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-11-12 11:00 -0600 |
| Message-ID | <tkojg4$172nl$2@dont-email.me> |
| In reply to | #59552 |
On 11/12/2022 10:26 AM, Richard Damon wrote:
> On 11/12/22 10:50 AM, olcott wrote:
>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>
>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>> {
>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>> }
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>
>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>
>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>
>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>> directly express a reference.
>>>>>>>>>
>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>> different way.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>> actually a decider.
>>>>>>>>
>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>
>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>> calls the decider.
>>>>>>>>
>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>
>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>> the requirements.
>>>>>>>>
>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>
>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>
>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>> error that I have identified is different: it is an error of self
>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>> fact that the input references a decider rather than being related
>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>> requirements.
>>>>>>
>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>> if H is actualy a Turing Machine.
>>>>>>
>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>> requirement to be the needed decider.
>>>>>
>>>>> In which case we get infinite turning machines all the way down: yet
>>>>> another manifestation of the category error I have identified.
>>>>>
>>>>> /Flibble
>>>>
>>>> Where are infinite machines? There is ONE machine being run, either H
>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>> simulations we have just shown that H was defective because it failed
>>>> to answer in finite time.
>>>>
>>>> This isn't a category error, but a design error in H.
>>>>
>>>> Note, when we start H, there is exactly two machines present in
>>>> representation on the tape, and two is much smaller than infinity.
>>>
>>> Nope, if,
>>>
>>> a) H is a copy, and
>>> b) H is a Turing Machine, and
>>> c) D is an input into H, and
>>> d) D references H, and
>>> e) H references D,
>>>
>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>> all the way down: a manifestation of the category error I have
>>> identified.
>>>
>>> /Flibble
>>>
>>
>> void E(void (*x)())
>> {
>> H(x, x);
>> }
>>
>> The point is
>> that D correctly simulated by H would never reach its own last
>> instruction and terminate normally after 1 to ∞ steps of correct
>> simulation.
>>
>> When H returns 0 to main() it is indicating
>>
>> that D correctly simulated by H would never reach its own last
>> instruction and terminate normally after 1 to ∞ steps of correct
>> simulation.
>>
>
> Except D is NOT correctly simulated by H, so that is a incorrect
> statement. When it is correctly simulated by something other than H, it
> will come to a final state, showing your statement is wrong.
In order for the simulation to actually be incorrect the execution trace
of the simulated E must diverge from the behavior that the line-by-line
x86 source-code of E specifies.
The first seven lines of the execution trace of the simulated E exactly
match the behavior specified by the first seven lines of the x86 source
code of E. This conclusively proves beyond all possible doubt that these
first seven lines have been simulated correctly.
*H correctly determines that E never halts*
void E(void (*x)())
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H(E, E));
}
_E()
[000019d2] 55 push ebp
[000019d3] 8bec mov ebp,esp
[000019d5] 8b4508 mov eax,[ebp+08]
[000019d8] 50 push eax
[000019d9] 8b4d08 mov ecx,[ebp+08]
[000019dc] 51 push ecx
[000019dd] e8b0f9ffff call 00001392
[000019e2] 83c408 add esp,+08
[000019e5] 5d pop ebp
[000019e6] c3 ret
Size in bytes:(0021) [000019e6]
_main()
[000019f2] 55 push ebp
[000019f3] 8bec mov ebp,esp
[000019f5] 68d2190000 push 000019d2
[000019fa] 68d2190000 push 000019d2
[000019ff] e88ef9ffff call 00001392
[00001a04] 83c408 add esp,+08
[00001a07] 50 push eax
[00001a08] 6893060000 push 00000693
[00001a0d] e8a0ecffff call 000006b2
[00001a12] 83c408 add esp,+08
[00001a15] 33c0 xor eax,eax
[00001a17] 5d pop ebp
[00001a18] c3 ret
Size in bytes:(0039) [00001a18]
machine stack stack machine assembly
address address data code language
======== ======== ======== ========= =============
[000019f2][00102a7c][00000000] 55 push ebp
[000019f3][00102a7c][00000000] 8bec mov ebp,esp
[000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
[000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
[000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
H: Begin Simulation Execution Trace Stored at:112b28
Address_of_H:1392
[000019d2][00112b14][00112b18] 55 push ebp
[000019d3][00112b14][00112b18] 8bec mov ebp,esp
[000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
[000019d8][00112b10][000019d2] 50 push eax // push E
[000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
[000019dc][00112b0c][000019d2] 51 push ecx // push E
[000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped
H correctly reports that E correctly simulated by H cannot possibly
reach its own final state at machine address [000019e6] and terminate
normally in 1 to ∞ steps of correct 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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 12:59 -0500 |
| Message-ID | <_9RbL.5611$gBW5.2085@fx06.iad> |
| In reply to | #59555 |
On 11/12/22 12:00 PM, olcott wrote:
> On 11/12/2022 10:26 AM, Richard Damon wrote:
>> On 11/12/22 10:50 AM, olcott wrote:
>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>
>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>> {
>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>
>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>
>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>> directly express a reference.
>>>>>>>>>>
>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>> different way.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>> actually a decider.
>>>>>>>>>
>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>
>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>> calls the decider.
>>>>>>>>>
>>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>
>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>> the requirements.
>>>>>>>>>
>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>
>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>
>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>> fact that the input references a decider rather than being related
>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>> requirements.
>>>>>>>
>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>> if H is actualy a Turing Machine.
>>>>>>>
>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>> requirement to be the needed decider.
>>>>>>
>>>>>> In which case we get infinite turning machines all the way down: yet
>>>>>> another manifestation of the category error I have identified.
>>>>>>
>>>>>> /Flibble
>>>>>
>>>>> Where are infinite machines? There is ONE machine being run, either H
>>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>>> simulations we have just shown that H was defective because it failed
>>>>> to answer in finite time.
>>>>>
>>>>> This isn't a category error, but a design error in H.
>>>>>
>>>>> Note, when we start H, there is exactly two machines present in
>>>>> representation on the tape, and two is much smaller than infinity.
>>>>
>>>> Nope, if,
>>>>
>>>> a) H is a copy, and
>>>> b) H is a Turing Machine, and
>>>> c) D is an input into H, and
>>>> d) D references H, and
>>>> e) H references D,
>>>>
>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing Machines
>>>> all the way down: a manifestation of the category error I have
>>>> identified.
>>>>
>>>> /Flibble
>>>>
>>>
>>> void E(void (*x)())
>>> {
>>> H(x, x);
>>> }
>>>
>>> The point is
>>> that D correctly simulated by H would never reach its own last
>>> instruction and terminate normally after 1 to ∞ steps of correct
>>> simulation.
>>>
>>> When H returns 0 to main() it is indicating
>>>
>>> that D correctly simulated by H would never reach its own last
>>> instruction and terminate normally after 1 to ∞ steps of correct
>>> simulation.
>>>
>>
>> Except D is NOT correctly simulated by H, so that is a incorrect
>> statement. When it is correctly simulated by something other than H,
>> it will come to a final state, showing your statement is wrong.
> In order for the simulation to actually be incorrect the execution trace
> of the simulated E must diverge from the behavior that the line-by-line
> x86 source-code of E specifies.
Right, and since you simulation does NOT continue past the call to H, it
is "incorrect" in the sense that the actual code does continue past that
point, so it does not actually match the behavior of that machine.
>
> The first seven lines of the execution trace of the simulated E exactly
> match the behavior specified by the first seven lines of the x86 source
> code of E. This conclusively proves beyond all possible doubt that these
> first seven lines have been simulated correctly.
Right, so H has correctly done a PARTIAL simulation of its input, which
does NOT prove the input is non-halting.
>
> *H correctly determines that E never halts*
>
> void E(void (*x)())
> {
> H(x, x);
> }
>
>
> int main()
> {
> Output("Input_Halts = ", H(E, E));
> }
>
> _E()
> [000019d2] 55 push ebp
> [000019d3] 8bec mov ebp,esp
> [000019d5] 8b4508 mov eax,[ebp+08]
> [000019d8] 50 push eax
> [000019d9] 8b4d08 mov ecx,[ebp+08]
> [000019dc] 51 push ecx
> [000019dd] e8b0f9ffff call 00001392
> [000019e2] 83c408 add esp,+08
> [000019e5] 5d pop ebp
> [000019e6] c3 ret
> Size in bytes:(0021) [000019e6]
>
> _main()
> [000019f2] 55 push ebp
> [000019f3] 8bec mov ebp,esp
> [000019f5] 68d2190000 push 000019d2
> [000019fa] 68d2190000 push 000019d2
> [000019ff] e88ef9ffff call 00001392
> [00001a04] 83c408 add esp,+08
> [00001a07] 50 push eax
> [00001a08] 6893060000 push 00000693
> [00001a0d] e8a0ecffff call 000006b2
> [00001a12] 83c408 add esp,+08
> [00001a15] 33c0 xor eax,eax
> [00001a17] 5d pop ebp
> [00001a18] c3 ret
> Size in bytes:(0039) [00001a18]
>
> machine stack stack machine assembly
> address address data code language
> ======== ======== ======== ========= =============
> [000019f2][00102a7c][00000000] 55 push ebp
> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>
> H: Begin Simulation Execution Trace Stored at:112b28
> Address_of_H:1392
> [000019d2][00112b14][00112b18] 55 push ebp
> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
> [000019d8][00112b10][000019d2] 50 push eax // push E
> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
> [000019dc][00112b0c][000019d2] 51 push ecx // push E
> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> H correctly reports that E correctly simulated by H cannot possibly
> reach its own final state at machine address [000019e6] and terminate
> normally in 1 to ∞ steps of correct simulation.
>
>
So you are just admitting you don't understand the Halting Criteria.
The fact that H stops its simulation before it gets to the end does NOT
prove that the machine being simulated, or a correct and complete
simultion of the input would be non-halting.
Or, do you claim that you have correctly climbed Mount Everest since
ever step of you climb of it were correct?
You are just proving you lack of understanding of the meaning of a
correct simulation.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-11-12 12:16 -0600 |
| Message-ID | <tkonum$17cpp$1@dont-email.me> |
| In reply to | #59558 |
On 11/12/2022 11:59 AM, Richard Damon wrote:
> On 11/12/22 12:00 PM, olcott wrote:
>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>> On 11/12/22 10:50 AM, olcott wrote:
>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>
>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the Truth.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the infinite
>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so any
>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be mapped to
>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>
>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>
>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>>> different way.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>> actually a decider.
>>>>>>>>>>
>>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>
>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>> calls the decider.
>>>>>>>>>>
>>>>>>>>>> After that, it is the deciders job to make the decision in finite
>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>
>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>> the requirements.
>>>>>>>>>>
>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>
>>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>> effect of the Self-Reference just lets us see that the task turns
>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>
>>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>>> not due to self reference or infinite copies but because the input
>>>>>>>>> tries to do the opposite of what the decider decides; the category
>>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>> fact that the input references a decider rather than being related
>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>> requirements.
>>>>>>>>
>>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>
>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>> requirement to be the needed decider.
>>>>>>>
>>>>>>> In which case we get infinite turning machines all the way down: yet
>>>>>>> another manifestation of the category error I have identified.
>>>>>>>
>>>>>>> /Flibble
>>>>>>
>>>>>> Where are infinite machines? There is ONE machine being run, either H
>>>>>> or D, and it SIMULATING others, and if we get an infinite sequence of
>>>>>> simulations we have just shown that H was defective because it failed
>>>>>> to answer in finite time.
>>>>>>
>>>>>> This isn't a category error, but a design error in H.
>>>>>>
>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>
>>>>> Nope, if,
>>>>>
>>>>> a) H is a copy, and
>>>>> b) H is a Turing Machine, and
>>>>> c) D is an input into H, and
>>>>> d) D references H, and
>>>>> e) H references D,
>>>>>
>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>> Machines
>>>>> all the way down: a manifestation of the category error I have
>>>>> identified.
>>>>>
>>>>> /Flibble
>>>>>
>>>>
>>>> void E(void (*x)())
>>>> {
>>>> H(x, x);
>>>> }
>>>>
>>>> The point is
>>>> that D correctly simulated by H would never reach its own last
>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>> simulation.
>>>>
>>>> When H returns 0 to main() it is indicating
>>>>
>>>> that D correctly simulated by H would never reach its own last
>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>> simulation.
>>>>
>>>
>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>> statement. When it is correctly simulated by something other than H,
>>> it will come to a final state, showing your statement is wrong.
>> In order for the simulation to actually be incorrect the execution
>> trace of the simulated E must diverge from the behavior that the
>> line-by-line x86 source-code of E specifies.
>
> Right, and since you simulation does NOT continue past the call to H, it
> is "incorrect" in the sense that the actual code does continue past that
> point, so it does not actually match the behavior of that machine.
>
>>
>> The first seven lines of the execution trace of the simulated E
>> exactly match the behavior specified by the first seven lines of the
>> x86 source code of E. This conclusively proves beyond all possible
>> doubt that these first seven lines have been simulated correctly.
>
> Right, so H has correctly done a PARTIAL simulation of its input, which
> does NOT prove the input is non-halting.
>
>>
>> *H correctly determines that E never halts*
>>
>> void E(void (*x)())
>> {
>> H(x, x);
>> }
>>
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(E, E));
>> }
>>
>> _E()
>> [000019d2] 55 push ebp
>> [000019d3] 8bec mov ebp,esp
>> [000019d5] 8b4508 mov eax,[ebp+08]
>> [000019d8] 50 push eax
>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>> [000019dc] 51 push ecx
>> [000019dd] e8b0f9ffff call 00001392
>> [000019e2] 83c408 add esp,+08
>> [000019e5] 5d pop ebp
>> [000019e6] c3 ret
>> Size in bytes:(0021) [000019e6]
>>
>> _main()
>> [000019f2] 55 push ebp
>> [000019f3] 8bec mov ebp,esp
>> [000019f5] 68d2190000 push 000019d2
>> [000019fa] 68d2190000 push 000019d2
>> [000019ff] e88ef9ffff call 00001392
>> [00001a04] 83c408 add esp,+08
>> [00001a07] 50 push eax
>> [00001a08] 6893060000 push 00000693
>> [00001a0d] e8a0ecffff call 000006b2
>> [00001a12] 83c408 add esp,+08
>> [00001a15] 33c0 xor eax,eax
>> [00001a17] 5d pop ebp
>> [00001a18] c3 ret
>> Size in bytes:(0039) [00001a18]
>>
>> machine stack stack machine assembly
>> address address data code language
>> ======== ======== ======== ========= =============
>> [000019f2][00102a7c][00000000] 55 push ebp
>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>
>> H: Begin Simulation Execution Trace Stored at:112b28
>> Address_of_H:1392
>> [000019d2][00112b14][00112b18] 55 push ebp
>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>> [000019d8][00112b10][000019d2] 50 push eax // push E
>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> H correctly reports that E correctly simulated by H cannot possibly
>> reach its own final state at machine address [000019e6] and terminate
>> normally in 1 to ∞ steps of correct simulation.
>>
>>
>
> So you are just admitting you don't understand the Halting Criteria.
>
> The fact that H stops its simulation before it gets to the end does NOT
> prove that the machine being simulated, or a correct and complete
> simultion of the input would be non-halting.
We must handle only one point at a time because you are easily
overwhelmed. You usually cannot even handle one point at a time until
this point is repeated 20 or more times.
The fact that the line-by-line execution trace of the first seven
instructions E simulated by H exactly match the behavior specified by
the first seven instructions of the x86 source-code of E conclusively
proves that these first seven instructions are simulated correctly.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 13:24 -0500 |
| Message-ID | <7xRbL.11594$o6Z5.1319@fx07.iad> |
| In reply to | #59559 |
On 11/12/22 1:16 PM, olcott wrote:
> On 11/12/2022 11:59 AM, Richard Damon wrote:
>> On 11/12/22 12:00 PM, olcott wrote:
>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>
>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to point
>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation, so
>>>>>>>>>>>>>>> any
>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The need to abort the simulation is due to the self reference
>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation to a
>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it, not a
>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>
>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>> all the way down so is the same category error manifesting in a
>>>>>>>>>>>> different way.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>>> actually a decider.
>>>>>>>>>>>
>>>>>>>>>>> If we assume a prospective decider exists, then the "Impossible"
>>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>
>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>> calls the decider.
>>>>>>>>>>>
>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>> finite
>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>
>>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>> the requirements.
>>>>>>>>>>>
>>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>
>>>>>>>>>>> The only place we get any form of "Reference", is when we try to
>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>> turns
>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>
>>>>>>>>>> You are fractally wrong on all fronts: in the traditional halting
>>>>>>>>>> problem proofs based on [Strachey 1965] the program is impossible
>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>> input
>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>> category
>>>>>>>>>> error that I have identified is different: it is an error of self
>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>> related
>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>> ANY input and answer in finite time, If an input causes it to make
>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>> requirements.
>>>>>>>>>
>>>>>>>>> Turing Machine can ALWAYS be legally built based on another Turing
>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>
>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>> admitting that your H can't actually be a Turing Machine, but must
>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>> requirement to be the needed decider.
>>>>>>>>
>>>>>>>> In which case we get infinite turning machines all the way down:
>>>>>>>> yet
>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>
>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>> either H
>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>> sequence of
>>>>>>> simulations we have just shown that H was defective because it
>>>>>>> failed
>>>>>>> to answer in finite time.
>>>>>>>
>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>
>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>
>>>>>> Nope, if,
>>>>>>
>>>>>> a) H is a copy, and
>>>>>> b) H is a Turing Machine, and
>>>>>> c) D is an input into H, and
>>>>>> d) D references H, and
>>>>>> e) H references D,
>>>>>>
>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>> Machines
>>>>>> all the way down: a manifestation of the category error I have
>>>>>> identified.
>>>>>>
>>>>>> /Flibble
>>>>>>
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>> H(x, x);
>>>>> }
>>>>>
>>>>> The point is
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>> When H returns 0 to main() it is indicating
>>>>>
>>>>> that D correctly simulated by H would never reach its own last
>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>> simulation.
>>>>>
>>>>
>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>> statement. When it is correctly simulated by something other than H,
>>>> it will come to a final state, showing your statement is wrong.
>>> In order for the simulation to actually be incorrect the execution
>>> trace of the simulated E must diverge from the behavior that the
>>> line-by-line x86 source-code of E specifies.
>>
>> Right, and since you simulation does NOT continue past the call to H,
>> it is "incorrect" in the sense that the actual code does continue past
>> that point, so it does not actually match the behavior of that machine.
>>
>>>
>>> The first seven lines of the execution trace of the simulated E
>>> exactly match the behavior specified by the first seven lines of the
>>> x86 source code of E. This conclusively proves beyond all possible
>>> doubt that these first seven lines have been simulated correctly.
>>
>> Right, so H has correctly done a PARTIAL simulation of its input,
>> which does NOT prove the input is non-halting.
>>
>>>
>>> *H correctly determines that E never halts*
>>>
>>> void E(void (*x)())
>>> {
>>> H(x, x);
>>> }
>>>
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(E, E));
>>> }
>>>
>>> _E()
>>> [000019d2] 55 push ebp
>>> [000019d3] 8bec mov ebp,esp
>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>> [000019d8] 50 push eax
>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>> [000019dc] 51 push ecx
>>> [000019dd] e8b0f9ffff call 00001392
>>> [000019e2] 83c408 add esp,+08
>>> [000019e5] 5d pop ebp
>>> [000019e6] c3 ret
>>> Size in bytes:(0021) [000019e6]
>>>
>>> _main()
>>> [000019f2] 55 push ebp
>>> [000019f3] 8bec mov ebp,esp
>>> [000019f5] 68d2190000 push 000019d2
>>> [000019fa] 68d2190000 push 000019d2
>>> [000019ff] e88ef9ffff call 00001392
>>> [00001a04] 83c408 add esp,+08
>>> [00001a07] 50 push eax
>>> [00001a08] 6893060000 push 00000693
>>> [00001a0d] e8a0ecffff call 000006b2
>>> [00001a12] 83c408 add esp,+08
>>> [00001a15] 33c0 xor eax,eax
>>> [00001a17] 5d pop ebp
>>> [00001a18] c3 ret
>>> Size in bytes:(0039) [00001a18]
>>>
>>> machine stack stack machine assembly
>>> address address data code language
>>> ======== ======== ======== ========= =============
>>> [000019f2][00102a7c][00000000] 55 push ebp
>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>
>>> H: Begin Simulation Execution Trace Stored at:112b28
>>> Address_of_H:1392
>>> [000019d2][00112b14][00112b18] 55 push ebp
>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> H correctly reports that E correctly simulated by H cannot possibly
>>> reach its own final state at machine address [000019e6] and terminate
>>> normally in 1 to ∞ steps of correct simulation.
>>>
>>>
>>
>> So you are just admitting you don't understand the Halting Criteria.
>>
>> The fact that H stops its simulation before it gets to the end does
>> NOT prove that the machine being simulated, or a correct and complete
>> simultion of the input would be non-halting.
> We must handle only one point at a time because you are easily
> overwhelmed. You usually cannot even handle one point at a time until
> this point is repeated 20 or more times.
>
> The fact that the line-by-line execution trace of the first seven
> instructions E simulated by H exactly match the behavior specified by
> the first seven instructions of the x86 source-code of E conclusively
> proves that these first seven instructions are simulated correctly.
>
No, that says that H did a correct PARTIAL simulation of the input. You
seem to be INTENTIONALLY using deceptive terminology to spread you lies.
So, I suppose you can correctly say that the input doesn't stop within
its first 7 instructions, but that doesn't mean anything.
Since you make a claim about a COMPLETE simulation (the it will never
end) you need to establish THAT fact (and you can't change the input to
do it, which includes the H the E calls).
YOU FAIL
You show that you don't understand what you are talking about and seem
to actually think that you are proving something by using wrong defintions.
You are just showing how stupid you are.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-11-12 18:42 +0000 |
| Message-ID | <20221112184207.000004d1@reddwarf.jmc.corp> |
| In reply to | #59561 |
On Sat, 12 Nov 2022 13:24:00 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
> On 11/12/22 1:16 PM, olcott wrote:
> > On 11/12/2022 11:59 AM, Richard Damon wrote:
> >> On 11/12/22 12:00 PM, olcott wrote:
> >>> On 11/12/2022 10:26 AM, Richard Damon wrote:
> >>>> On 11/12/22 10:50 AM, olcott wrote:
> >>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
> >>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
> >>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>
> >>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
> >>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
> >>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
> >>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
> >>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
> >>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
> >>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
> >>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
> >>>>>>>>>>>>>>>>>>>>>> you and I would have thought given your
> >>>>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
> >>>>>>>>>>>>>>>>>>>>> mostly ignores me.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond
> >>>>>>>>>>>>>>>>>>>>> to what I say, even if not in a direct reply,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
> >>>>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
> >>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
> >>>>>>>>>>>>>>>>>>>>> around to point out his errors.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
> >>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
> >>>>>>>>>>>>>>>>>>>>> showing the Truth.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
> >>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
> >>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If he
> >>>>>>>>>>>>>>>>>>>>> tries to put his explanation into explicit
> >>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I think
> >>>>>>>>>>>>>>>>>>>>> even to him, so he just refuses.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
> >>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
> >>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
> >>>>>>>>>>>>>>>>>>>> audience.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
> >>>>>>>>>>>>>>>>>>> Halting Decider.
> >>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
> >>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
> >>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
> >>>>>>>>>>>>>>>>>> basis for its halt status decision.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> void E(void (*x)())
> >>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
> >>>>>>>>>>>>>>>> infinite
> >>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
> >>>>>>>>>>>>>>>> shell game can correctly deny this.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
> >>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
> >>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
> >>>>>>>>>>>>>>> correct simulation, so any
> >>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> The need to abort the simulation is due to the self
> >>>>>>>>>>>>>> reference category error present in the proof; what
> >>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
> >>>>>>>>>>>>>> abort the simulation to a halt decision of
> >>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
> >>>>>>>>>>>>>> INVALID INPUT.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Nope, no self reference.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
> >>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
> >>>>>>>>>>>>> have the power to directly express a reference.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
> >>>>>>>>>>>> copies all the way down so is the same category error
> >>>>>>>>>>>> manifesting in a different way.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>> Only if the "decider" makes that happen, in which case it
> >>>>>>>>>>> isn't actually a decider.
> >>>>>>>>>>>
> >>>>>>>>>>> If we assume a prospective decider exists, then the
> >>>>>>>>>>> "Impossible" program is simple to make from it, and is
> >>>>>>>>>>> given one copy of the description of itself, which is
> >>>>>>>>>>> also simple to make.
> >>>>>>>>>>>
> >>>>>>>>>>> When run it makes a second copy of its description, and
> >>>>>>>>>>> then calls the decider.
> >>>>>>>>>>>
> >>>>>>>>>>> After that, it is the deciders job to make the decision
> >>>>>>>>>>> in finite
> >>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
> >>>>>>>>>>> your infinite loop, the decider is just wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> The proof shows that what ever answer the decider does
> >>>>>>>>>>> give (if it gives one) will be wrong, and thus the
> >>>>>>>>>>> decider doesn't meet the requirements.
> >>>>>>>>>>>
> >>>>>>>>>>> No "Self Reference" in sight there only a program being
> >>>>>>>>>>> given a copy of something that just happens to be its own
> >>>>>>>>>>> description.
> >>>>>>>>>>>
> >>>>>>>>>>> The only place we get any form of "Reference", is when we
> >>>>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
> >>>>>>>>>>> challenge. There the effect of the Self-Reference just
> >>>>>>>>>>> lets us see that the task turns
> >>>>>>>>>>> out be be impossible, so no such program exists.
> >>>>>>>>>>
> >>>>>>>>>> You are fractally wrong on all fronts: in the traditional
> >>>>>>>>>> halting problem proofs based on [Strachey 1965] the
> >>>>>>>>>> program is impossible not due to self reference or
> >>>>>>>>>> infinite copies but because the input
> >>>>>>>>>> tries to do the opposite of what the decider decides; the
> >>>>>>>>>> category
> >>>>>>>>>> error that I have identified is different: it is an error
> >>>>>>>>>> of self reference and/or infinite copies; it is an error
> >>>>>>>>>> related to the fact that the input references a decider
> >>>>>>>>>> rather than being related
> >>>>>>>>>> to what the input does with the decision result of a
> >>>>>>>>>> decider.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> But the infinite copies is a error in the Decider, not in
> >>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
> >>>>>>>>> handle ANY input and answer in finite time, If an input
> >>>>>>>>> causes it to make infinite copies, then the decided just
> >>>>>>>>> doesn't meet its requirements.
> >>>>>>>>>
> >>>>>>>>> Turing Machine can ALWAYS be legally built based on another
> >>>>>>>>> Turing Machine as a base. The only reason it wouldn't be
> >>>>>>>>> allowed is if H isn't actually a Turing Machine, so it
> >>>>>>>>> CAN'T be a category error if H is actualy a Turing Machine.
> >>>>>>>>>
> >>>>>>>>> All your declaration of a "Category Error" here is doing is
> >>>>>>>>> admitting that your H can't actually be a Turing Machine,
> >>>>>>>>> but must be of a HIGHER order logic system, which means H
> >>>>>>>>> fails the requirement to be the needed decider.
> >>>>>>>>
> >>>>>>>> In which case we get infinite turning machines all the way
> >>>>>>>> down: yet
> >>>>>>>> another manifestation of the category error I have
> >>>>>>>> identified.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>
> >>>>>>> Where are infinite machines? There is ONE machine being run,
> >>>>>>> either H
> >>>>>>> or D, and it SIMULATING others, and if we get an infinite
> >>>>>>> sequence of
> >>>>>>> simulations we have just shown that H was defective because
> >>>>>>> it failed
> >>>>>>> to answer in finite time.
> >>>>>>>
> >>>>>>> This isn't a category error, but a design error in H.
> >>>>>>>
> >>>>>>> Note, when we start H, there is exactly two machines present
> >>>>>>> in representation on the tape, and two is much smaller than
> >>>>>>> infinity.
> >>>>>>
> >>>>>> Nope, if,
> >>>>>>
> >>>>>> a) H is a copy, and
> >>>>>> b) H is a Turing Machine, and
> >>>>>> c) D is an input into H, and
> >>>>>> d) D references H, and
> >>>>>> e) H references D,
> >>>>>>
> >>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
> >>>>>> Machines
> >>>>>> all the way down: a manifestation of the category error I have
> >>>>>> identified.
> >>>>>>
> >>>>>> /Flibble
> >>>>>>
> >>>>>
> >>>>> void E(void (*x)())
> >>>>> {
> >>>>> H(x, x);
> >>>>> }
> >>>>>
> >>>>> The point is
> >>>>> that D correctly simulated by H would never reach its own last
> >>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>> correct simulation.
> >>>>>
> >>>>> When H returns 0 to main() it is indicating
> >>>>>
> >>>>> that D correctly simulated by H would never reach its own last
> >>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>> correct simulation.
> >>>>>
> >>>>
> >>>> Except D is NOT correctly simulated by H, so that is a incorrect
> >>>> statement. When it is correctly simulated by something other
> >>>> than H, it will come to a final state, showing your statement is
> >>>> wrong.
> >>> In order for the simulation to actually be incorrect the
> >>> execution trace of the simulated E must diverge from the behavior
> >>> that the line-by-line x86 source-code of E specifies.
> >>
> >> Right, and since you simulation does NOT continue past the call to
> >> H, it is "incorrect" in the sense that the actual code does
> >> continue past that point, so it does not actually match the
> >> behavior of that machine.
> >>>
> >>> The first seven lines of the execution trace of the simulated E
> >>> exactly match the behavior specified by the first seven lines of
> >>> the x86 source code of E. This conclusively proves beyond all
> >>> possible doubt that these first seven lines have been simulated
> >>> correctly.
> >>
> >> Right, so H has correctly done a PARTIAL simulation of its input,
> >> which does NOT prove the input is non-halting.
> >>
> >>>
> >>> *H correctly determines that E never halts*
> >>>
> >>> void E(void (*x)())
> >>> {
> >>> H(x, x);
> >>> }
> >>>
> >>>
> >>> int main()
> >>> {
> >>> Output("Input_Halts = ", H(E, E));
> >>> }
> >>>
> >>> _E()
> >>> [000019d2] 55 push ebp
> >>> [000019d3] 8bec mov ebp,esp
> >>> [000019d5] 8b4508 mov eax,[ebp+08]
> >>> [000019d8] 50 push eax
> >>> [000019d9] 8b4d08 mov ecx,[ebp+08]
> >>> [000019dc] 51 push ecx
> >>> [000019dd] e8b0f9ffff call 00001392
> >>> [000019e2] 83c408 add esp,+08
> >>> [000019e5] 5d pop ebp
> >>> [000019e6] c3 ret
> >>> Size in bytes:(0021) [000019e6]
> >>>
> >>> _main()
> >>> [000019f2] 55 push ebp
> >>> [000019f3] 8bec mov ebp,esp
> >>> [000019f5] 68d2190000 push 000019d2
> >>> [000019fa] 68d2190000 push 000019d2
> >>> [000019ff] e88ef9ffff call 00001392
> >>> [00001a04] 83c408 add esp,+08
> >>> [00001a07] 50 push eax
> >>> [00001a08] 6893060000 push 00000693
> >>> [00001a0d] e8a0ecffff call 000006b2
> >>> [00001a12] 83c408 add esp,+08
> >>> [00001a15] 33c0 xor eax,eax
> >>> [00001a17] 5d pop ebp
> >>> [00001a18] c3 ret
> >>> Size in bytes:(0039) [00001a18]
> >>>
> >>> machine stack stack machine assembly
> >>> address address data code language
> >>> ======== ======== ======== ========= =============
> >>> [000019f2][00102a7c][00000000] 55 push ebp
> >>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
> >>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
> >>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
> >>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
> >>>
> >>> H: Begin Simulation Execution Trace Stored at:112b28
> >>> Address_of_H:1392
> >>> [000019d2][00112b14][00112b18] 55 push ebp
> >>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
> >>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
> >>> [000019d8][00112b10][000019d2] 50 push eax //
> >>> push E [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
> >>> [000019dc][00112b0c][000019d2] 51 push ecx //
> >>> push E [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392
> >>> // call H H: Infinitely Recursive Simulation Detected Simulation
> >>> Stopped
> >>>
> >>> H correctly reports that E correctly simulated by H cannot
> >>> possibly reach its own final state at machine address [000019e6]
> >>> and terminate normally in 1 to ∞ steps of correct simulation.
> >>>
> >>>
> >>
> >> So you are just admitting you don't understand the Halting
> >> Criteria.
> >>
> >> The fact that H stops its simulation before it gets to the end
> >> does NOT prove that the machine being simulated, or a correct and
> >> complete simultion of the input would be non-halting.
> > We must handle only one point at a time because you are easily
> > overwhelmed. You usually cannot even handle one point at a time
> > until this point is repeated 20 or more times.
> >
> > The fact that the line-by-line execution trace of the first seven
> > instructions E simulated by H exactly match the behavior specified
> > by the first seven instructions of the x86 source-code of E
> > conclusively proves that these first seven instructions are
> > simulated correctly.
>
> No, that says that H did a correct PARTIAL simulation of the input.
> You seem to be INTENTIONALLY using deceptive terminology to spread
> you lies.
>
> So, I suppose you can correctly say that the input doesn't stop
> within its first 7 instructions, but that doesn't mean anything.
>
> Since you make a claim about a COMPLETE simulation (the it will never
> end) you need to establish THAT fact (and you can't change the input
> to do it, which includes the H the E calls).
>
> YOU FAIL
>
> You show that you don't understand what you are talking about and
> seem to actually think that you are proving something by using wrong
> defintions.
>
> You are just showing how stupid you are.
Again with the ad hominem attacks: "liar", "stupid" etc. You are not
very good at his are you, Mr Damon.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 14:00 -0500 |
| Message-ID | <d3SbL.14322$%VI9.13847@fx34.iad> |
| In reply to | #59563 |
On 11/12/22 1:42 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 13:24:00 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:16 PM, olcott wrote:
>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
>>>>>>>>>>>>>>>>>>>>>>>> you and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>> intelligence you would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond
>>>>>>>>>>>>>>>>>>>>>>> to what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
>>>>>>>>>>>>>>>>>>>>>>> has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If he
>>>>>>>>>>>>>>>>>>>>>>> tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I think
>>>>>>>>>>>>>>>>>>>>>>> even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a correct
>>>>>>>>>>>>>>>>>>>> basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>> isn't actually a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>> in finite
>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>> given a copy of something that just happens to be its own
>>>>>>>>>>>>> description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>> try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>
>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>> category
>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>> rather than being related
>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>
>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>> Turing Machine as a base. The only reason it wouldn't be
>>>>>>>>>>> allowed is if H isn't actually a Turing Machine, so it
>>>>>>>>>>> CAN'T be a category error if H is actualy a Turing Machine.
>>>>>>>>>>>
>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>> but must be of a HIGHER order logic system, which means H
>>>>>>>>>>> fails the requirement to be the needed decider.
>>>>>>>>>>
>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>> down: yet
>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>> identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>> either H
>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>> sequence of
>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>> it failed
>>>>>>>>> to answer in finite time.
>>>>>>>>>
>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>
>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>> infinity.
>>>>>>>>
>>>>>>>> Nope, if,
>>>>>>>>
>>>>>>>> a) H is a copy, and
>>>>>>>> b) H is a Turing Machine, and
>>>>>>>> c) D is an input into H, and
>>>>>>>> d) D references H, and
>>>>>>>> e) H references D,
>>>>>>>>
>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>> Machines
>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>> identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> The point is
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>> correct simulation.
>>>>>>>
>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>> correct simulation.
>>>>>>>
>>>>>>
>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>> statement. When it is correctly simulated by something other
>>>>>> than H, it will come to a final state, showing your statement is
>>>>>> wrong.
>>>>> In order for the simulation to actually be incorrect the
>>>>> execution trace of the simulated E must diverge from the behavior
>>>>> that the line-by-line x86 source-code of E specifies.
>>>>
>>>> Right, and since you simulation does NOT continue past the call to
>>>> H, it is "incorrect" in the sense that the actual code does
>>>> continue past that point, so it does not actually match the
>>>> behavior of that machine.
>>>>>
>>>>> The first seven lines of the execution trace of the simulated E
>>>>> exactly match the behavior specified by the first seven lines of
>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>> possible doubt that these first seven lines have been simulated
>>>>> correctly.
>>>>
>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>> which does NOT prove the input is non-halting.
>>>>
>>>>>
>>>>> *H correctly determines that E never halts*
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>> H(x, x);
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(E, E));
>>>>> }
>>>>>
>>>>> _E()
>>>>> [000019d2] 55 push ebp
>>>>> [000019d3] 8bec mov ebp,esp
>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>> [000019d8] 50 push eax
>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>> [000019dc] 51 push ecx
>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>> [000019e2] 83c408 add esp,+08
>>>>> [000019e5] 5d pop ebp
>>>>> [000019e6] c3 ret
>>>>> Size in bytes:(0021) [000019e6]
>>>>>
>>>>> _main()
>>>>> [000019f2] 55 push ebp
>>>>> [000019f3] 8bec mov ebp,esp
>>>>> [000019f5] 68d2190000 push 000019d2
>>>>> [000019fa] 68d2190000 push 000019d2
>>>>> [000019ff] e88ef9ffff call 00001392
>>>>> [00001a04] 83c408 add esp,+08
>>>>> [00001a07] 50 push eax
>>>>> [00001a08] 6893060000 push 00000693
>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>> [00001a12] 83c408 add esp,+08
>>>>> [00001a15] 33c0 xor eax,eax
>>>>> [00001a17] 5d pop ebp
>>>>> [00001a18] c3 ret
>>>>> Size in bytes:(0039) [00001a18]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>
>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>> Address_of_H:1392
>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>> [000019d8][00112b10][000019d2] 50 push eax //
>>>>> push E [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>>> [000019dc][00112b0c][000019d2] 51 push ecx //
>>>>> push E [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392
>>>>> // call H H: Infinitely Recursive Simulation Detected Simulation
>>>>> Stopped
>>>>>
>>>>> H correctly reports that E correctly simulated by H cannot
>>>>> possibly reach its own final state at machine address [000019e6]
>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>
>>>>>
>>>>
>>>> So you are just admitting you don't understand the Halting
>>>> Criteria.
>>>>
>>>> The fact that H stops its simulation before it gets to the end
>>>> does NOT prove that the machine being simulated, or a correct and
>>>> complete simultion of the input would be non-halting.
>>> We must handle only one point at a time because you are easily
>>> overwhelmed. You usually cannot even handle one point at a time
>>> until this point is repeated 20 or more times.
>>>
>>> The fact that the line-by-line execution trace of the first seven
>>> instructions E simulated by H exactly match the behavior specified
>>> by the first seven instructions of the x86 source-code of E
>>> conclusively proves that these first seven instructions are
>>> simulated correctly.
>>
>> No, that says that H did a correct PARTIAL simulation of the input.
>> You seem to be INTENTIONALLY using deceptive terminology to spread
>> you lies.
>>
>> So, I suppose you can correctly say that the input doesn't stop
>> within its first 7 instructions, but that doesn't mean anything.
>>
>> Since you make a claim about a COMPLETE simulation (the it will never
>> end) you need to establish THAT fact (and you can't change the input
>> to do it, which includes the H the E calls).
>>
>> YOU FAIL
>>
>> You show that you don't understand what you are talking about and
>> seem to actually think that you are proving something by using wrong
>> defintions.
>>
>> You are just showing how stupid you are.
>
> Again with the ad hominem attacks: "liar", "stupid" etc. You are not
> very good at his are you, Mr Damon.
>
> /Flibble
>
So, you don't understand the meaning of ad hominem. The fallacy of
ad-hominem is to say the person must be wrong because they are a "X".
That is not what my statement is, but that he is wrong for a specified
logical reason. I then point out that BECAUSE he is stating these
incorrect statements, he is a liar and stupid. That is a valid logical
deduction.
YOU are showing you lack of understanding.
[toc] | [prev] | [next] | [standalone]
| From | Mr Flibble <flibble@reddwarf.jmc.corp> |
|---|---|
| Date | 2022-11-12 19:26 +0000 |
| Message-ID | <20221112192618.00003dec@reddwarf.jmc.corp> |
| In reply to | #59566 |
On Sat, 12 Nov 2022 14:00:21 -0500
Richard Damon <Richard@Damon-Family.org> wrote:
> On 11/12/22 1:42 PM, Mr Flibble wrote:
> > On Sat, 12 Nov 2022 13:24:00 -0500
> > Richard Damon <Richard@Damon-Family.org> wrote:
> >
> >> On 11/12/22 1:16 PM, olcott wrote:
> >>> On 11/12/2022 11:59 AM, Richard Damon wrote:
> >>>> On 11/12/22 12:00 PM, olcott wrote:
> >>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
> >>>>>> On 11/12/22 10:50 AM, olcott wrote:
> >>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
> >>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
> >>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>
> >>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
> >>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
> >>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
> >>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
> >>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
> >>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
> >>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
> >>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
> >>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
> >>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
> >>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
> >>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
> >>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
> >>>>>>>>>>>>>>>>>>>>>>>> that.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
> >>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
> >>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
> >>>>>>>>>>>>>>>>>>>>>>> direct reply,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
> >>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
> >>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
> >>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
> >>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
> >>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
> >>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
> >>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
> >>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
> >>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
> >>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
> >>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
> >>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
> >>>>>>>>>>>>>>>>>>>>>> audience.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
> >>>>>>>>>>>>>>>>>>>>> Halting Decider.
> >>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
> >>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
> >>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
> >>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> void E(void (*x)())
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> H(x, x);
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
> >>>>>>>>>>>>>>>>>> infinite
> >>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
> >>>>>>>>>>>>>>>>>> shell game can correctly deny this.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
> >>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
> >>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
> >>>>>>>>>>>>>>>>> correct simulation, so any
> >>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
> >>>>>>>>>>>>>>>> reference category error present in the proof; what
> >>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
> >>>>>>>>>>>>>>>> abort the simulation to a halt decision of
> >>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
> >>>>>>>>>>>>>>>> INVALID INPUT.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Nope, no self reference.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
> >>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
> >>>>>>>>>>>>>>> have the power to directly express a reference.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
> >>>>>>>>>>>>>> copies all the way down so is the same category error
> >>>>>>>>>>>>>> manifesting in a different way.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> /Flibble
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
> >>>>>>>>>>>>> it isn't actually a decider.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> If we assume a prospective decider exists, then the
> >>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
> >>>>>>>>>>>>> given one copy of the description of itself, which is
> >>>>>>>>>>>>> also simple to make.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> When run it makes a second copy of its description, and
> >>>>>>>>>>>>> then calls the decider.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> After that, it is the deciders job to make the decision
> >>>>>>>>>>>>> in finite
> >>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
> >>>>>>>>>>>>> your infinite loop, the decider is just wrong.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The proof shows that what ever answer the decider does
> >>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
> >>>>>>>>>>>>> decider doesn't meet the requirements.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> No "Self Reference" in sight there only a program being
> >>>>>>>>>>>>> given a copy of something that just happens to be its
> >>>>>>>>>>>>> own description.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The only place we get any form of "Reference", is when
> >>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
> >>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
> >>>>>>>>>>>>> lets us see that the task turns
> >>>>>>>>>>>>> out be be impossible, so no such program exists.
> >>>>>>>>>>>>
> >>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
> >>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
> >>>>>>>>>>>> program is impossible not due to self reference or
> >>>>>>>>>>>> infinite copies but because the input
> >>>>>>>>>>>> tries to do the opposite of what the decider decides; the
> >>>>>>>>>>>> category
> >>>>>>>>>>>> error that I have identified is different: it is an error
> >>>>>>>>>>>> of self reference and/or infinite copies; it is an error
> >>>>>>>>>>>> related to the fact that the input references a decider
> >>>>>>>>>>>> rather than being related
> >>>>>>>>>>>> to what the input does with the decision result of a
> >>>>>>>>>>>> decider.
> >>>>>>>>>>>>
> >>>>>>>>>>>> /Flibble
> >>>>>>>>>>>
> >>>>>>>>>>> But the infinite copies is a error in the Decider, not in
> >>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
> >>>>>>>>>>> handle ANY input and answer in finite time, If an input
> >>>>>>>>>>> causes it to make infinite copies, then the decided just
> >>>>>>>>>>> doesn't meet its requirements.
> >>>>>>>>>>>
> >>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
> >>>>>>>>>>> another Turing Machine as a base. The only reason it
> >>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
> >>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
> >>>>>>>>>>> a Turing Machine.
> >>>>>>>>>>>
> >>>>>>>>>>> All your declaration of a "Category Error" here is doing
> >>>>>>>>>>> is admitting that your H can't actually be a Turing
> >>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
> >>>>>>>>>>> which means H fails the requirement to be the needed
> >>>>>>>>>>> decider.
> >>>>>>>>>>
> >>>>>>>>>> In which case we get infinite turning machines all the way
> >>>>>>>>>> down: yet
> >>>>>>>>>> another manifestation of the category error I have
> >>>>>>>>>> identified.
> >>>>>>>>>>
> >>>>>>>>>> /Flibble
> >>>>>>>>>
> >>>>>>>>> Where are infinite machines? There is ONE machine being run,
> >>>>>>>>> either H
> >>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
> >>>>>>>>> sequence of
> >>>>>>>>> simulations we have just shown that H was defective because
> >>>>>>>>> it failed
> >>>>>>>>> to answer in finite time.
> >>>>>>>>>
> >>>>>>>>> This isn't a category error, but a design error in H.
> >>>>>>>>>
> >>>>>>>>> Note, when we start H, there is exactly two machines present
> >>>>>>>>> in representation on the tape, and two is much smaller than
> >>>>>>>>> infinity.
> >>>>>>>>
> >>>>>>>> Nope, if,
> >>>>>>>>
> >>>>>>>> a) H is a copy, and
> >>>>>>>> b) H is a Turing Machine, and
> >>>>>>>> c) D is an input into H, and
> >>>>>>>> d) D references H, and
> >>>>>>>> e) H references D,
> >>>>>>>>
> >>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
> >>>>>>>> Turing Machines
> >>>>>>>> all the way down: a manifestation of the category error I
> >>>>>>>> have identified.
> >>>>>>>>
> >>>>>>>> /Flibble
> >>>>>>>>
> >>>>>>>
> >>>>>>> void E(void (*x)())
> >>>>>>> {
> >>>>>>> H(x, x);
> >>>>>>> }
> >>>>>>>
> >>>>>>> The point is
> >>>>>>> that D correctly simulated by H would never reach its own last
> >>>>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>>>> correct simulation.
> >>>>>>>
> >>>>>>> When H returns 0 to main() it is indicating
> >>>>>>>
> >>>>>>> that D correctly simulated by H would never reach its own last
> >>>>>>> instruction and terminate normally after 1 to ∞ steps of
> >>>>>>> correct simulation.
> >>>>>>>
> >>>>>>
> >>>>>> Except D is NOT correctly simulated by H, so that is a
> >>>>>> incorrect statement. When it is correctly simulated by
> >>>>>> something other than H, it will come to a final state, showing
> >>>>>> your statement is wrong.
> >>>>> In order for the simulation to actually be incorrect the
> >>>>> execution trace of the simulated E must diverge from the
> >>>>> behavior that the line-by-line x86 source-code of E specifies.
> >>>>
> >>>> Right, and since you simulation does NOT continue past the call
> >>>> to H, it is "incorrect" in the sense that the actual code does
> >>>> continue past that point, so it does not actually match the
> >>>> behavior of that machine.
> >>>>>
> >>>>> The first seven lines of the execution trace of the simulated E
> >>>>> exactly match the behavior specified by the first seven lines of
> >>>>> the x86 source code of E. This conclusively proves beyond all
> >>>>> possible doubt that these first seven lines have been simulated
> >>>>> correctly.
> >>>>
> >>>> Right, so H has correctly done a PARTIAL simulation of its input,
> >>>> which does NOT prove the input is non-halting.
> >>>>
> >>>>>
> >>>>> *H correctly determines that E never halts*
> >>>>>
> >>>>> void E(void (*x)())
> >>>>> {
> >>>>> H(x, x);
> >>>>> }
> >>>>>
> >>>>>
> >>>>> int main()
> >>>>> {
> >>>>> Output("Input_Halts = ", H(E, E));
> >>>>> }
> >>>>>
> >>>>> _E()
> >>>>> [000019d2] 55 push ebp
> >>>>> [000019d3] 8bec mov ebp,esp
> >>>>> [000019d5] 8b4508 mov eax,[ebp+08]
> >>>>> [000019d8] 50 push eax
> >>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
> >>>>> [000019dc] 51 push ecx
> >>>>> [000019dd] e8b0f9ffff call 00001392
> >>>>> [000019e2] 83c408 add esp,+08
> >>>>> [000019e5] 5d pop ebp
> >>>>> [000019e6] c3 ret
> >>>>> Size in bytes:(0021) [000019e6]
> >>>>>
> >>>>> _main()
> >>>>> [000019f2] 55 push ebp
> >>>>> [000019f3] 8bec mov ebp,esp
> >>>>> [000019f5] 68d2190000 push 000019d2
> >>>>> [000019fa] 68d2190000 push 000019d2
> >>>>> [000019ff] e88ef9ffff call 00001392
> >>>>> [00001a04] 83c408 add esp,+08
> >>>>> [00001a07] 50 push eax
> >>>>> [00001a08] 6893060000 push 00000693
> >>>>> [00001a0d] e8a0ecffff call 000006b2
> >>>>> [00001a12] 83c408 add esp,+08
> >>>>> [00001a15] 33c0 xor eax,eax
> >>>>> [00001a17] 5d pop ebp
> >>>>> [00001a18] c3 ret
> >>>>> Size in bytes:(0039) [00001a18]
> >>>>>
> >>>>> machine stack stack machine assembly
> >>>>> address address data code language
> >>>>> ======== ======== ======== ========= =============
> >>>>> [000019f2][00102a7c][00000000] 55 push ebp
> >>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
> >>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
> >>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
> >>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
> >>>>> // call H
> >>>>>
> >>>>> H: Begin Simulation Execution Trace Stored at:112b28
> >>>>> Address_of_H:1392
> >>>>> [000019d2][00112b14][00112b18] 55 push ebp
> >>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
> >>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
> >>>>> [000019d8][00112b10][000019d2] 50 push eax //
> >>>>> push E [000019d9][00112b10][000019d2] 8b4d08 mov
> >>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51 push ecx
> >>>>> // push E [000019dd][00112b08][000019e2] e8b0f9ffff
> >>>>> call 00001392 // call H H: Infinitely Recursive Simulation
> >>>>> Detected Simulation Stopped
> >>>>>
> >>>>> H correctly reports that E correctly simulated by H cannot
> >>>>> possibly reach its own final state at machine address [000019e6]
> >>>>> and terminate normally in 1 to ∞ steps of correct simulation.
> >>>>>
> >>>>>
> >>>>
> >>>> So you are just admitting you don't understand the Halting
> >>>> Criteria.
> >>>>
> >>>> The fact that H stops its simulation before it gets to the end
> >>>> does NOT prove that the machine being simulated, or a correct and
> >>>> complete simultion of the input would be non-halting.
> >>> We must handle only one point at a time because you are easily
> >>> overwhelmed. You usually cannot even handle one point at a time
> >>> until this point is repeated 20 or more times.
> >>>
> >>> The fact that the line-by-line execution trace of the first seven
> >>> instructions E simulated by H exactly match the behavior specified
> >>> by the first seven instructions of the x86 source-code of E
> >>> conclusively proves that these first seven instructions are
> >>> simulated correctly.
> >>
> >> No, that says that H did a correct PARTIAL simulation of the input.
> >> You seem to be INTENTIONALLY using deceptive terminology to spread
> >> you lies.
> >>
> >> So, I suppose you can correctly say that the input doesn't stop
> >> within its first 7 instructions, but that doesn't mean anything.
> >>
> >> Since you make a claim about a COMPLETE simulation (the it will
> >> never end) you need to establish THAT fact (and you can't change
> >> the input to do it, which includes the H the E calls).
> >>
> >> YOU FAIL
> >>
> >> You show that you don't understand what you are talking about and
> >> seem to actually think that you are proving something by using
> >> wrong defintions.
> >>
> >> You are just showing how stupid you are.
> >
> > Again with the ad hominem attacks: "liar", "stupid" etc. You are
> > not very good at his are you, Mr Damon.
> >
> > /Flibble
> >
>
> So, you don't understand the meaning of ad hominem. The fallacy of
> ad-hominem is to say the person must be wrong because they are a "X".
> That is not what my statement is, but that he is wrong for a
> specified logical reason. I then point out that BECAUSE he is stating
> these incorrect statements, he is a liar and stupid. That is a valid
> logical deduction.
>
> YOU are showing you lack of understanding.
I fully understand what constitutes an ad hominem; YOU are using a
DISGUISED ad hominem by using insults after the fact in an attempt to
strengthen your argument. A DISGUISED ad hominem is still an ad
hominem if you use it as part of your argument, which you are.
To be clear, if you called Olcott "big nose" rather than "stupid" then
that would just be an insult however calling someone "stupid" implies
you think they have a low IQ which is a characteristic that directly
relates to their ability to argue/debate (unlike "big nose") and so is
a logical fallacy, albeit a disguised one.
/Flibble
[toc] | [prev] | [next] | [standalone]
| From | olcott <none-ya@beez-waxes.com> |
|---|---|
| Date | 2022-11-12 13:37 -0600 |
| Message-ID | <tkosme$1qpn$1@gioia.aioe.org> |
| In reply to | #59570 |
On 11/12/2022 1:26 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 14:00:21 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:42 PM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 13:24:00 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
>>>>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
>>>>>>>>>>>>>>>>>>>>>>>>> direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
>>>>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
>>>>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
>>>>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>> it isn't actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a copy of something that just happens to be its
>>>>>>>>>>>>>>> own description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>>>> rather than being related
>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>> another Turing Machine as a base. The only reason it
>>>>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
>>>>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
>>>>>>>>>>>>> a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing
>>>>>>>>>>>>> is admitting that your H can't actually be a Turing
>>>>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
>>>>>>>>>>>>> which means H fails the requirement to be the needed
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>>>> identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>> Turing Machines
>>>>>>>>>> all the way down: a manifestation of the category error I
>>>>>>>>>> have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>> your statement is wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55 push ebp
>>>>>>> [000019d3] 8bec mov ebp,esp
>>>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8] 50 push eax
>>>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [000019dc] 51 push ecx
>>>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>>>> [000019e2] 83c408 add esp,+08
>>>>>>> [000019e5] 5d pop ebp
>>>>>>> [000019e6] c3 ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55 push ebp
>>>>>>> [000019f3] 8bec mov ebp,esp
>>>>>>> [000019f5] 68d2190000 push 000019d2
>>>>>>> [000019fa] 68d2190000 push 000019d2
>>>>>>> [000019ff] e88ef9ffff call 00001392
>>>>>>> [00001a04] 83c408 add esp,+08
>>>>>>> [00001a07] 50 push eax
>>>>>>> [00001a08] 6893060000 push 00000693
>>>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>>>> [00001a12] 83c408 add esp,+08
>>>>>>> [00001a15] 33c0 xor eax,eax
>>>>>>> [00001a17] 5d pop ebp
>>>>>>> [00001a18] c3 ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
>>>>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
>>>>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
>>>>>>> // call H
>>>>>>>
>>>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50 push eax //
>>>>>>> push E [000019d9][00112b10][000019d2] 8b4d08 mov
>>>>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51 push ecx
>>>>>>> // push E [000019dd][00112b08][000019e2] e8b0f9ffff
>>>>>>> call 00001392 // call H H: Infinitely Recursive Simulation
>>>>>>> Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting
>>>>>> Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>> You seem to be INTENTIONALLY using deceptive terminology to spread
>>>> you lies.
>>>>
>>>> So, I suppose you can correctly say that the input doesn't stop
>>>> within its first 7 instructions, but that doesn't mean anything.
>>>>
>>>> Since you make a claim about a COMPLETE simulation (the it will
>>>> never end) you need to establish THAT fact (and you can't change
>>>> the input to do it, which includes the H the E calls).
>>>>
>>>> YOU FAIL
>>>>
>>>> You show that you don't understand what you are talking about and
>>>> seem to actually think that you are proving something by using
>>>> wrong defintions.
>>>>
>>>> You are just showing how stupid you are.
>>>
>>> Again with the ad hominem attacks: "liar", "stupid" etc. You are
>>> not very good at his are you, Mr Damon.
>>>
>>> /Flibble
>>>
>>
>> So, you don't understand the meaning of ad hominem. The fallacy of
>> ad-hominem is to say the person must be wrong because they are a "X".
>> That is not what my statement is, but that he is wrong for a
>> specified logical reason. I then point out that BECAUSE he is stating
>> these incorrect statements, he is a liar and stupid. That is a valid
>> logical deduction.
>>
>> YOU are showing you lack of understanding.
>
> I fully understand what constitutes an ad hominem; YOU are using a
> DISGUISED ad hominem by using insults after the fact in an attempt to
> strengthen your argument. A DISGUISED ad hominem is still an ad
> hominem if you use it as part of your argument, which you are.
>
> To be clear, if you called Olcott "big nose" rather than "stupid" then
> that would just be an insult however calling someone "stupid" implies
> you think they have a low IQ which is a characteristic that directly
> relates to their ability to argue/debate (unlike "big nose") and so is
> a logical fallacy, albeit a disguised one.
>
> /Flibble
>
Good job you nailed that much better than I could have.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 14:54 -0500 |
| Message-ID | <xRSbL.52223$NeJ8.19045@fx09.iad> |
| In reply to | #59570 |
On 11/12/22 2:26 PM, Mr Flibble wrote:
> On Sat, 12 Nov 2022 14:00:21 -0500
> Richard Damon <Richard@Damon-Family.org> wrote:
>
>> On 11/12/22 1:42 PM, Mr Flibble wrote:
>>> On Sat, 12 Nov 2022 13:24:00 -0500
>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you and I would have thought given
>>>>>>>>>>>>>>>>>>>>>>>>>> your intelligence you would also understand
>>>>>>>>>>>>>>>>>>>>>>>>>> that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>> respond to what I say, even if not in a
>>>>>>>>>>>>>>>>>>>>>>>>> direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>> he has blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>> the archives, I want enough evidence to be
>>>>>>>>>>>>>>>>>>>>>>>>> around to point out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>> and provide reasoning behind the claims,
>>>>>>>>>>>>>>>>>>>>>>>>> showing the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he doesn't actually know what he is
>>>>>>>>>>>>>>>>>>>>>>>>> talking about, and reveals his ignorance. If
>>>>>>>>>>>>>>>>>>>>>>>>> he tries to put his explanation into explicit
>>>>>>>>>>>>>>>>>>>>>>>>> words, his errors become very apparent, I
>>>>>>>>>>>>>>>>>>>>>>>>> think even to him, so he just refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your
>>>>>>>>>>>>>>>>>>>>>>>> only basis. Naive readers will never notice
>>>>>>>>>>>>>>>>>>>>>>>> this, yet naive readers are not in my target
>>>>>>>>>>>>>>>>>>>>>>>> audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing machine (UTM) knows that the behavior of D
>>>>>>>>>>>>>>>>>>>>>> correctly simulated by H provides H with a
>>>>>>>>>>>>>>>>>>>>>> correct basis for its halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because the CORRECT simulation, as will the diret
>>>>>>>>>>>>>>>>>>> exectuion, will halt. Note, such an H doesn't do a
>>>>>>>>>>>>>>>>>>> correct simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference category error present in the proof; what
>>>>>>>>>>>>>>>>>> Olcott is getting wrong is the mapping of the need to
>>>>>>>>>>>>>>>>>> abort the simulation to a halt decision of
>>>>>>>>>>>>>>>>>> non-halting; it needs to instead be mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a "reference" to it. Turing Machines do not
>>>>>>>>>>>>>>>>> have the power to directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>> it isn't actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible" program is simple to make from it, and is
>>>>>>>>>>>>>>> given one copy of the description of itself, which is
>>>>>>>>>>>>>>> also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>> then calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in
>>>>>>>>>>>>>>> your infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if it gives one) will be wrong, and thus the
>>>>>>>>>>>>>>> decider doesn't meet the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a copy of something that just happens to be its
>>>>>>>>>>>>>>> own description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>> we try to ANALYSE or DESIGN the H to try to meet the
>>>>>>>>>>>>>>> challenge. There the effect of the Self-Reference just
>>>>>>>>>>>>>>> lets us see that the task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting problem proofs based on [Strachey 1965] the
>>>>>>>>>>>>>> program is impossible not due to self reference or
>>>>>>>>>>>>>> infinite copies but because the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self reference and/or infinite copies; it is an error
>>>>>>>>>>>>>> related to the fact that the input references a decider
>>>>>>>>>>>>>> rather than being related
>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle ANY input and answer in finite time, If an input
>>>>>>>>>>>>> causes it to make infinite copies, then the decided just
>>>>>>>>>>>>> doesn't meet its requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>> another Turing Machine as a base. The only reason it
>>>>>>>>>>>>> wouldn't be allowed is if H isn't actually a Turing
>>>>>>>>>>>>> Machine, so it CAN'T be a category error if H is actualy
>>>>>>>>>>>>> a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing
>>>>>>>>>>>>> is admitting that your H can't actually be a Turing
>>>>>>>>>>>>> Machine, but must be of a HIGHER order logic system,
>>>>>>>>>>>>> which means H fails the requirement to be the needed
>>>>>>>>>>>>> decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have
>>>>>>>>>>>> identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present
>>>>>>>>>>> in representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>> Turing Machines
>>>>>>>>>> all the way down: a manifestation of the category error I
>>>>>>>>>> have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>> your statement is wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55 push ebp
>>>>>>> [000019d3] 8bec mov ebp,esp
>>>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8] 50 push eax
>>>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [000019dc] 51 push ecx
>>>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>>>> [000019e2] 83c408 add esp,+08
>>>>>>> [000019e5] 5d pop ebp
>>>>>>> [000019e6] c3 ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55 push ebp
>>>>>>> [000019f3] 8bec mov ebp,esp
>>>>>>> [000019f5] 68d2190000 push 000019d2
>>>>>>> [000019fa] 68d2190000 push 000019d2
>>>>>>> [000019ff] e88ef9ffff call 00001392
>>>>>>> [00001a04] 83c408 add esp,+08
>>>>>>> [00001a07] 50 push eax
>>>>>>> [00001a08] 6893060000 push 00000693
>>>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>>>> [00001a12] 83c408 add esp,+08
>>>>>>> [00001a15] 33c0 xor eax,eax
>>>>>>> [00001a17] 5d pop ebp
>>>>>>> [00001a18] c3 ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push
>>>>>>> E [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 //
>>>>>>> push E [000019ff][00102a70][00001a04] e88ef9ffff call 00001392
>>>>>>> // call H
>>>>>>>
>>>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50 push eax //
>>>>>>> push E [000019d9][00112b10][000019d2] 8b4d08 mov
>>>>>>> ecx,[ebp+08] [000019dc][00112b0c][000019d2] 51 push ecx
>>>>>>> // push E [000019dd][00112b08][000019e2] e8b0f9ffff
>>>>>>> call 00001392 // call H H: Infinitely Recursive Simulation
>>>>>>> Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting
>>>>>> Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>> You seem to be INTENTIONALLY using deceptive terminology to spread
>>>> you lies.
>>>>
>>>> So, I suppose you can correctly say that the input doesn't stop
>>>> within its first 7 instructions, but that doesn't mean anything.
>>>>
>>>> Since you make a claim about a COMPLETE simulation (the it will
>>>> never end) you need to establish THAT fact (and you can't change
>>>> the input to do it, which includes the H the E calls).
>>>>
>>>> YOU FAIL
>>>>
>>>> You show that you don't understand what you are talking about and
>>>> seem to actually think that you are proving something by using
>>>> wrong defintions.
>>>>
>>>> You are just showing how stupid you are.
>>>
>>> Again with the ad hominem attacks: "liar", "stupid" etc. You are
>>> not very good at his are you, Mr Damon.
>>>
>>> /Flibble
>>>
>>
>> So, you don't understand the meaning of ad hominem. The fallacy of
>> ad-hominem is to say the person must be wrong because they are a "X".
>> That is not what my statement is, but that he is wrong for a
>> specified logical reason. I then point out that BECAUSE he is stating
>> these incorrect statements, he is a liar and stupid. That is a valid
>> logical deduction.
>>
>> YOU are showing you lack of understanding.
>
> I fully understand what constitutes an ad hominem; YOU are using a
> DISGUISED ad hominem by using insults after the fact in an attempt to
> strengthen your argument. A DISGUISED ad hominem is still an ad
> hominem if you use it as part of your argument, which you are.
>
> To be clear, if you called Olcott "big nose" rather than "stupid" then
> that would just be an insult however calling someone "stupid" implies
> you think they have a low IQ which is a characteristic that directly
> relates to their ability to argue/debate (unlike "big nose") and so is
> a logical fallacy, albeit a disguised one.
>
> /Flibble
>
I will point out that Peter Olcott BEGAN the insults, and continues them.
Why dont you issue the complaints to HIM?
As to thinking he has a low IQ, I DO. He has shows incredible lack of
reasoning capability. I do wonder if he has a bonafide mental condition.
He has shown an inability to put together a reasoned arguement.
He has shown a decided tendency to maintain conflicting idea and assume
they work together.
He has shown fundmental issues with the understand of basic English and
how it interacts with technical discussion.
He has ADMITTED that he doesn't have training in the basics of the
system he claims to talk about it, and brags about it as if that was a
good thing.
In other words, by the definition of the word, he has admitted to being
IGNORANT of the field.
[toc] | [prev] | [next] | [standalone]
| From | olcott <none-ya@beez-waxes.com> |
|---|---|
| Date | 2022-11-12 12:45 -0600 |
| Message-ID | <tkopjk$fah$1@gioia.aioe.org> |
| In reply to | #59561 |
On 11/12/2022 12:24 PM, Richard Damon wrote:
> On 11/12/22 1:16 PM, olcott wrote:
>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>> On 11/12/22 12:00 PM, olcott wrote:
>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>
>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence you
>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just mostly
>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet naive
>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal Turing
>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation
>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>>> all the way down so is the same category error manifesting
>>>>>>>>>>>>> in a
>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it isn't
>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>> program is simple to make from it, and is given one copy of the
>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>
>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>
>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>> finite
>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> The proof shows that what ever answer the decider does give (if
>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> No "Self Reference" in sight there only a program being given a
>>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>>
>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>> try to
>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There the
>>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>>> turns
>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>
>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>> halting
>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>> impossible
>>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>>> input
>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>> category
>>>>>>>>>>> error that I have identified is different: it is an error of
>>>>>>>>>>> self
>>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>> related
>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>>> ANY input and answer in finite time, If an input causes it to
>>>>>>>>>> make
>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>> requirements.
>>>>>>>>>>
>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>> Turing
>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is if H
>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>
>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>> admitting that your H can't actually be a Turing Machine, but
>>>>>>>>>> must
>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>
>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>> down: yet
>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>> either H
>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>> sequence of
>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>> failed
>>>>>>>> to answer in finite time.
>>>>>>>>
>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>
>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>>
>>>>>>> Nope, if,
>>>>>>>
>>>>>>> a) H is a copy, and
>>>>>>> b) H is a Turing Machine, and
>>>>>>> c) D is an input into H, and
>>>>>>> d) D references H, and
>>>>>>> e) H references D,
>>>>>>>
>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>> Machines
>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>> identified.
>>>>>>>
>>>>>>> /Flibble
>>>>>>>
>>>>>>
>>>>>> void E(void (*x)())
>>>>>> {
>>>>>> H(x, x);
>>>>>> }
>>>>>>
>>>>>> The point is
>>>>>> that D correctly simulated by H would never reach its own last
>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>> simulation.
>>>>>>
>>>>>> When H returns 0 to main() it is indicating
>>>>>>
>>>>>> that D correctly simulated by H would never reach its own last
>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>> simulation.
>>>>>>
>>>>>
>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>> statement. When it is correctly simulated by something other than
>>>>> H, it will come to a final state, showing your statement is wrong.
>>>> In order for the simulation to actually be incorrect the execution
>>>> trace of the simulated E must diverge from the behavior that the
>>>> line-by-line x86 source-code of E specifies.
>>>
>>> Right, and since you simulation does NOT continue past the call to H,
>>> it is "incorrect" in the sense that the actual code does continue
>>> past that point, so it does not actually match the behavior of that
>>> machine.
>>>
>>>>
>>>> The first seven lines of the execution trace of the simulated E
>>>> exactly match the behavior specified by the first seven lines of the
>>>> x86 source code of E. This conclusively proves beyond all possible
>>>> doubt that these first seven lines have been simulated correctly.
>>>
>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>> which does NOT prove the input is non-halting.
>>>
>>>>
>>>> *H correctly determines that E never halts*
>>>>
>>>> void E(void (*x)())
>>>> {
>>>> H(x, x);
>>>> }
>>>>
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(E, E));
>>>> }
>>>>
>>>> _E()
>>>> [000019d2] 55 push ebp
>>>> [000019d3] 8bec mov ebp,esp
>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>> [000019d8] 50 push eax
>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>> [000019dc] 51 push ecx
>>>> [000019dd] e8b0f9ffff call 00001392
>>>> [000019e2] 83c408 add esp,+08
>>>> [000019e5] 5d pop ebp
>>>> [000019e6] c3 ret
>>>> Size in bytes:(0021) [000019e6]
>>>>
>>>> _main()
>>>> [000019f2] 55 push ebp
>>>> [000019f3] 8bec mov ebp,esp
>>>> [000019f5] 68d2190000 push 000019d2
>>>> [000019fa] 68d2190000 push 000019d2
>>>> [000019ff] e88ef9ffff call 00001392
>>>> [00001a04] 83c408 add esp,+08
>>>> [00001a07] 50 push eax
>>>> [00001a08] 6893060000 push 00000693
>>>> [00001a0d] e8a0ecffff call 000006b2
>>>> [00001a12] 83c408 add esp,+08
>>>> [00001a15] 33c0 xor eax,eax
>>>> [00001a17] 5d pop ebp
>>>> [00001a18] c3 ret
>>>> Size in bytes:(0039) [00001a18]
>>>>
>>>> machine stack stack machine assembly
>>>> address address data code language
>>>> ======== ======== ======== ========= =============
>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>
>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>> Address_of_H:1392
>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> H correctly reports that E correctly simulated by H cannot possibly
>>>> reach its own final state at machine address [000019e6] and
>>>> terminate normally in 1 to ∞ steps of correct simulation.
>>>>
>>>>
>>>
>>> So you are just admitting you don't understand the Halting Criteria.
>>>
>>> The fact that H stops its simulation before it gets to the end does
>>> NOT prove that the machine being simulated, or a correct and complete
>>> simultion of the input would be non-halting.
>> We must handle only one point at a time because you are easily
>> overwhelmed. You usually cannot even handle one point at a time until
>> this point is repeated 20 or more times.
>>
>> The fact that the line-by-line execution trace of the first seven
>> instructions E simulated by H exactly match the behavior specified by
>> the first seven instructions of the x86 source-code of E conclusively
>> proves that these first seven instructions are simulated correctly.
>>
>
> No, that says that H did a correct PARTIAL simulation of the input.
Yes that is correct now we can move on to the next point.
void E(void (*x)())
{
H(x, x);
}
int main()
{
Output("Input_Halts = ", H(E, E));
}
H: Begin Simulation Execution Trace Stored at:112b28
Address_of_H:1392
[000019d2][00112b14][00112b18] 55 push ebp
[000019d3][00112b14][00112b18] 8bec mov ebp,esp
[000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
[000019d8][00112b10][000019d2] 50 push eax // push E
[000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
[000019dc][00112b0c][000019d2] 51 push ecx // push E
[000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
H: Infinitely Recursive Simulation Detected Simulation Stopped
We can see that the seventh instruction of E correctly simulated by H
would call H to simulate itself again.
We can also see that there are no instructions from the beginning of E
to its call to H that would prevent this process from repeating an
unlimited number of times.
These two things taken together conclusively prove that H would be
correct when it reports that D correctly simulated by H would never
reach its own final state at machine address [00001a18] and terminate
normally.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 13:57 -0500 |
| Message-ID | <90SbL.14321$%VI9.7406@fx34.iad> |
| In reply to | #59564 |
On 11/12/22 1:45 PM, olcott wrote:
> On 11/12/2022 12:24 PM, Richard Damon wrote:
>> On 11/12/22 1:16 PM, olcott wrote:
>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>
>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your intelligence
>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show that he
>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a Halting
>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No shell
>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT because
>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is getting
>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the simulation
>>>>>>>>>>>>>>>> to a
>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite copies
>>>>>>>>>>>>>> all the way down so is the same category error manifesting
>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>> isn't
>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>> program is simple to make from it, and is given one copy of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>
>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>>> finite
>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The proof shows that what ever answer the decider does give
>>>>>>>>>>>>> (if
>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't meet
>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>> given a
>>>>>>>>>>>>> copy of something that just happens to be its own description.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>> try to
>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge. There
>>>>>>>>>>>>> the
>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the task
>>>>>>>>>>>>> turns
>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>
>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>> halting
>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>> impossible
>>>>>>>>>>>> not due to self reference or infinite copies but because the
>>>>>>>>>>>> input
>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>> category
>>>>>>>>>>>> error that I have identified is different: it is an error of
>>>>>>>>>>>> self
>>>>>>>>>>>> reference and/or infinite copies; it is an error related to the
>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>> related
>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to handle
>>>>>>>>>>> ANY input and answer in finite time, If an input causes it to
>>>>>>>>>>> make
>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>> requirements.
>>>>>>>>>>>
>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>> Turing
>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is
>>>>>>>>>>> if H
>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category error
>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>
>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>> admitting that your H can't actually be a Turing Machine, but
>>>>>>>>>>> must
>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>
>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>> down: yet
>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>> either H
>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>> sequence of
>>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>>> failed
>>>>>>>>> to answer in finite time.
>>>>>>>>>
>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>
>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>> representation on the tape, and two is much smaller than infinity.
>>>>>>>>
>>>>>>>> Nope, if,
>>>>>>>>
>>>>>>>> a) H is a copy, and
>>>>>>>> b) H is a Turing Machine, and
>>>>>>>> c) D is an input into H, and
>>>>>>>> d) D references H, and
>>>>>>>> e) H references D,
>>>>>>>>
>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>> Machines
>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>> identified.
>>>>>>>>
>>>>>>>> /Flibble
>>>>>>>>
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>> The point is
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>> simulation.
>>>>>>>
>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>
>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>> simulation.
>>>>>>>
>>>>>>
>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>> statement. When it is correctly simulated by something other than
>>>>>> H, it will come to a final state, showing your statement is wrong.
>>>>> In order for the simulation to actually be incorrect the execution
>>>>> trace of the simulated E must diverge from the behavior that the
>>>>> line-by-line x86 source-code of E specifies.
>>>>
>>>> Right, and since you simulation does NOT continue past the call to
>>>> H, it is "incorrect" in the sense that the actual code does continue
>>>> past that point, so it does not actually match the behavior of that
>>>> machine.
>>>>
>>>>>
>>>>> The first seven lines of the execution trace of the simulated E
>>>>> exactly match the behavior specified by the first seven lines of
>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>> possible doubt that these first seven lines have been simulated
>>>>> correctly.
>>>>
>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>> which does NOT prove the input is non-halting.
>>>>
>>>>>
>>>>> *H correctly determines that E never halts*
>>>>>
>>>>> void E(void (*x)())
>>>>> {
>>>>> H(x, x);
>>>>> }
>>>>>
>>>>>
>>>>> int main()
>>>>> {
>>>>> Output("Input_Halts = ", H(E, E));
>>>>> }
>>>>>
>>>>> _E()
>>>>> [000019d2] 55 push ebp
>>>>> [000019d3] 8bec mov ebp,esp
>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>> [000019d8] 50 push eax
>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>> [000019dc] 51 push ecx
>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>> [000019e2] 83c408 add esp,+08
>>>>> [000019e5] 5d pop ebp
>>>>> [000019e6] c3 ret
>>>>> Size in bytes:(0021) [000019e6]
>>>>>
>>>>> _main()
>>>>> [000019f2] 55 push ebp
>>>>> [000019f3] 8bec mov ebp,esp
>>>>> [000019f5] 68d2190000 push 000019d2
>>>>> [000019fa] 68d2190000 push 000019d2
>>>>> [000019ff] e88ef9ffff call 00001392
>>>>> [00001a04] 83c408 add esp,+08
>>>>> [00001a07] 50 push eax
>>>>> [00001a08] 6893060000 push 00000693
>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>> [00001a12] 83c408 add esp,+08
>>>>> [00001a15] 33c0 xor eax,eax
>>>>> [00001a17] 5d pop ebp
>>>>> [00001a18] c3 ret
>>>>> Size in bytes:(0039) [00001a18]
>>>>>
>>>>> machine stack stack machine assembly
>>>>> address address data code language
>>>>> ======== ======== ======== ========= =============
>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>
>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>> Address_of_H:1392
>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> H correctly reports that E correctly simulated by H cannot possibly
>>>>> reach its own final state at machine address [000019e6] and
>>>>> terminate normally in 1 to ∞ steps of correct simulation.
>>>>>
>>>>>
>>>>
>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>
>>>> The fact that H stops its simulation before it gets to the end does
>>>> NOT prove that the machine being simulated, or a correct and
>>>> complete simultion of the input would be non-halting.
>>> We must handle only one point at a time because you are easily
>>> overwhelmed. You usually cannot even handle one point at a time until
>>> this point is repeated 20 or more times.
>>>
>>> The fact that the line-by-line execution trace of the first seven
>>> instructions E simulated by H exactly match the behavior specified by
>>> the first seven instructions of the x86 source-code of E conclusively
>>> proves that these first seven instructions are simulated correctly.
>>>
>>
>> No, that says that H did a correct PARTIAL simulation of the input.
>
> Yes that is correct now we can move on to the next point.
>
> void E(void (*x)())
> {
> H(x, x);
> }
>
> int main()
> {
> Output("Input_Halts = ", H(E, E));
> }
>
> H: Begin Simulation Execution Trace Stored at:112b28
> Address_of_H:1392
> [000019d2][00112b14][00112b18] 55 push ebp
> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
> [000019d8][00112b10][000019d2] 50 push eax // push E
> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
> [000019dc][00112b0c][000019d2] 51 push ecx // push E
> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
> H: Infinitely Recursive Simulation Detected Simulation Stopped
>
> We can see that the seventh instruction of E correctly simulated by H
> would call H to simulate itself again.
No, E calls H which will HALT DECIDER (by simulation) its input. This H
will simulate its input ONLY to the point when it THINKS it is
non-halting, which will happen at the point when the simulation reaches
the call to H instuction, thus we don't get "infinite" simulation loop,
but just 1 level inside E.
Unless you are claiming that H is just a pure simulator that never
aborts its simulation, you statement is just a lie. But then, H(E,E)
doesn't return an answer, so you also are caught in a lie. The only
other opition is that you have lied that the H that main calls and the H
the E calls are the same function. In other words, you have just been
proven to have LIED.
The problem is that you are LYING that H will correct simulate its
input, which it doesn't.
>
> We can also see that there are no instructions from the beginning of E
> to its call to H that would prevent this process from repeating an
> unlimited number of times.
Which isn't a requirement. An instruction inside the H that it calls
that terminates the loop is sufficient.
You clearly don't understand the meaning of what you are talking about.
>
> These two things taken together conclusively prove that H would be
> correct when it reports that D correctly simulated by H would never
> reach its own final state at machine address [00001a18] and terminate
> normally.
>
>
Nope, two errors do not make a right statement.
You are just showing your ignorance.
[toc] | [prev] | [next] | [standalone]
| From | olcott <none-ya@beez-waxes.com> |
|---|---|
| Date | 2022-11-12 13:04 -0600 |
| Message-ID | <tkoqo1$ta1$1@gioia.aioe.org> |
| In reply to | #59565 |
On 11/12/2022 12:57 PM, Richard Damon wrote:
> On 11/12/22 1:45 PM, olcott wrote:
>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>> On 11/12/22 1:16 PM, olcott wrote:
>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>
>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked you
>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he has
>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around to
>>>>>>>>>>>>>>>>>>>>>>>> point
>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing the
>>>>>>>>>>>>>>>>>>>>>>>> Truth.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about, and
>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for its
>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion, will
>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct simulation,
>>>>>>>>>>>>>>>>>> so any
>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding it,
>>>>>>>>>>>>>>>> not a
>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the power to
>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>>> isn't
>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> After that, it is the deciders job to make the decision in
>>>>>>>>>>>>>> finite
>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't
>>>>>>>>>>>>>> meet
>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>>> try to
>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>
>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>> halting
>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>> impossible
>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>> the input
>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>> category
>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>> of self
>>>>>>>>>>>>> reference and/or infinite copies; it is an error related to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>>> related
>>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>> handle
>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>> to make
>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>> requirements.
>>>>>>>>>>>>
>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>>> Turing
>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed is
>>>>>>>>>>>> if H
>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>> error
>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>
>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>> but must
>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>
>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>> down: yet
>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>> either H
>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>> sequence of
>>>>>>>>>> simulations we have just shown that H was defective because it
>>>>>>>>>> failed
>>>>>>>>>> to answer in finite time.
>>>>>>>>>>
>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>
>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>> infinity.
>>>>>>>>>
>>>>>>>>> Nope, if,
>>>>>>>>>
>>>>>>>>> a) H is a copy, and
>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>> c) D is an input into H, and
>>>>>>>>> d) D references H, and
>>>>>>>>> e) H references D,
>>>>>>>>>
>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>>> Machines
>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>> identified.
>>>>>>>>>
>>>>>>>>> /Flibble
>>>>>>>>>
>>>>>>>>
>>>>>>>> void E(void (*x)())
>>>>>>>> {
>>>>>>>> H(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>> The point is
>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>
>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>> instruction and terminate normally after 1 to ∞ steps of correct
>>>>>>>> simulation.
>>>>>>>>
>>>>>>>
>>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>>> statement. When it is correctly simulated by something other than
>>>>>>> H, it will come to a final state, showing your statement is wrong.
>>>>>> In order for the simulation to actually be incorrect the execution
>>>>>> trace of the simulated E must diverge from the behavior that the
>>>>>> line-by-line x86 source-code of E specifies.
>>>>>
>>>>> Right, and since you simulation does NOT continue past the call to
>>>>> H, it is "incorrect" in the sense that the actual code does
>>>>> continue past that point, so it does not actually match the
>>>>> behavior of that machine.
>>>>>
>>>>>>
>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>> possible doubt that these first seven lines have been simulated
>>>>>> correctly.
>>>>>
>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>> which does NOT prove the input is non-halting.
>>>>>
>>>>>>
>>>>>> *H correctly determines that E never halts*
>>>>>>
>>>>>> void E(void (*x)())
>>>>>> {
>>>>>> H(x, x);
>>>>>> }
>>>>>>
>>>>>>
>>>>>> int main()
>>>>>> {
>>>>>> Output("Input_Halts = ", H(E, E));
>>>>>> }
>>>>>>
>>>>>> _E()
>>>>>> [000019d2] 55 push ebp
>>>>>> [000019d3] 8bec mov ebp,esp
>>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>>> [000019d8] 50 push eax
>>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>>> [000019dc] 51 push ecx
>>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>>> [000019e2] 83c408 add esp,+08
>>>>>> [000019e5] 5d pop ebp
>>>>>> [000019e6] c3 ret
>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>
>>>>>> _main()
>>>>>> [000019f2] 55 push ebp
>>>>>> [000019f3] 8bec mov ebp,esp
>>>>>> [000019f5] 68d2190000 push 000019d2
>>>>>> [000019fa] 68d2190000 push 000019d2
>>>>>> [000019ff] e88ef9ffff call 00001392
>>>>>> [00001a04] 83c408 add esp,+08
>>>>>> [00001a07] 50 push eax
>>>>>> [00001a08] 6893060000 push 00000693
>>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>>> [00001a12] 83c408 add esp,+08
>>>>>> [00001a15] 33c0 xor eax,eax
>>>>>> [00001a17] 5d pop ebp
>>>>>> [00001a18] c3 ret
>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>
>>>>>> machine stack stack machine assembly
>>>>>> address address data code language
>>>>>> ======== ======== ======== ========= =============
>>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>
>>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>>> Address_of_H:1392
>>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>
>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>
>>>>>>
>>>>>
>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>
>>>>> The fact that H stops its simulation before it gets to the end does
>>>>> NOT prove that the machine being simulated, or a correct and
>>>>> complete simultion of the input would be non-halting.
>>>> We must handle only one point at a time because you are easily
>>>> overwhelmed. You usually cannot even handle one point at a time
>>>> until this point is repeated 20 or more times.
>>>>
>>>> The fact that the line-by-line execution trace of the first seven
>>>> instructions E simulated by H exactly match the behavior specified
>>>> by the first seven instructions of the x86 source-code of E
>>>> conclusively proves that these first seven instructions are
>>>> simulated correctly.
>>>>
>>>
>>> No, that says that H did a correct PARTIAL simulation of the input.
>>
>> Yes that is correct now we can move on to the next point.
>>
>> void E(void (*x)())
>> {
>> H(x, x);
>> }
>>
>> int main()
>> {
>> Output("Input_Halts = ", H(E, E));
>> }
>>
>> H: Begin Simulation Execution Trace Stored at:112b28
>> Address_of_H:1392
>> [000019d2][00112b14][00112b18] 55 push ebp
>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>> [000019d8][00112b10][000019d2] 50 push eax // push E
>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>
>> We can see that the seventh instruction of E correctly simulated by H
>> would call H to simulate itself again.
>
> No, E calls H which will HALT DECIDER (by simulation) its input.
Try again this time don't use a noun as a verb gibberish.
--
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]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2022-11-12 14:21 -0500 |
| Message-ID | <LmSbL.74300$Jjx8.17367@fx15.iad> |
| In reply to | #59567 |
On 11/12/22 2:04 PM, olcott wrote:
> On 11/12/2022 12:57 PM, Richard Damon wrote:
>> On 11/12/22 1:45 PM, olcott wrote:
>>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has blocked
>>>>>>>>>>>>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to respond to
>>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if he
>>>>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into the
>>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around
>>>>>>>>>>>>>>>>>>>>>>>>> to point
>>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know and
>>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing
>>>>>>>>>>>>>>>>>>>>>>>>> the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking about,
>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors become
>>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this, yet
>>>>>>>>>>>>>>>>>>>>>>>> naive
>>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis for
>>>>>>>>>>>>>>>>>>>>>> its
>>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion,
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct
>>>>>>>>>>>>>>>>>>> simulation, so any
>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>> it, not a
>>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>>>>>> power to
>>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case it
>>>>>>>>>>>>>>> isn't
>>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When run it makes a second copy of its description, and then
>>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider doesn't
>>>>>>>>>>>>>>> meet
>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when we
>>>>>>>>>>>>>>> try to
>>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>> halting
>>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>>> the input
>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>> category
>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>> of self
>>>>>>>>>>>>>> reference and/or infinite copies; it is an error related
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> fact that the input references a decider rather than being
>>>>>>>>>>>>>> related
>>>>>>>>>>>>>> to what the input does with the decision result of a decider.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>
>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>> handle
>>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>>> to make
>>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on another
>>>>>>>>>>>>> Turing
>>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed
>>>>>>>>>>>>> is if H
>>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>>> error
>>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>>
>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>>> but must
>>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>>
>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>> down: yet
>>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>>
>>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>> either H
>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>> sequence of
>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>> it failed
>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>
>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>
>>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>>> infinity.
>>>>>>>>>>
>>>>>>>>>> Nope, if,
>>>>>>>>>>
>>>>>>>>>> a) H is a copy, and
>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>> d) D references H, and
>>>>>>>>>> e) H references D,
>>>>>>>>>>
>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite Turing
>>>>>>>>>> Machines
>>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>>> identified.
>>>>>>>>>>
>>>>>>>>>> /Flibble
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> void E(void (*x)())
>>>>>>>>> {
>>>>>>>>> H(x, x);
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> The point is
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>
>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>> correct simulation.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Except D is NOT correctly simulated by H, so that is a incorrect
>>>>>>>> statement. When it is correctly simulated by something other
>>>>>>>> than H, it will come to a final state, showing your statement is
>>>>>>>> wrong.
>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>> execution trace of the simulated E must diverge from the behavior
>>>>>>> that the line-by-line x86 source-code of E specifies.
>>>>>>
>>>>>> Right, and since you simulation does NOT continue past the call to
>>>>>> H, it is "incorrect" in the sense that the actual code does
>>>>>> continue past that point, so it does not actually match the
>>>>>> behavior of that machine.
>>>>>>
>>>>>>>
>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>> correctly.
>>>>>>
>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>> which does NOT prove the input is non-halting.
>>>>>>
>>>>>>>
>>>>>>> *H correctly determines that E never halts*
>>>>>>>
>>>>>>> void E(void (*x)())
>>>>>>> {
>>>>>>> H(x, x);
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> Output("Input_Halts = ", H(E, E));
>>>>>>> }
>>>>>>>
>>>>>>> _E()
>>>>>>> [000019d2] 55 push ebp
>>>>>>> [000019d3] 8bec mov ebp,esp
>>>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8] 50 push eax
>>>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [000019dc] 51 push ecx
>>>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>>>> [000019e2] 83c408 add esp,+08
>>>>>>> [000019e5] 5d pop ebp
>>>>>>> [000019e6] c3 ret
>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>
>>>>>>> _main()
>>>>>>> [000019f2] 55 push ebp
>>>>>>> [000019f3] 8bec mov ebp,esp
>>>>>>> [000019f5] 68d2190000 push 000019d2
>>>>>>> [000019fa] 68d2190000 push 000019d2
>>>>>>> [000019ff] e88ef9ffff call 00001392
>>>>>>> [00001a04] 83c408 add esp,+08
>>>>>>> [00001a07] 50 push eax
>>>>>>> [00001a08] 6893060000 push 00000693
>>>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>>>> [00001a12] 83c408 add esp,+08
>>>>>>> [00001a15] 33c0 xor eax,eax
>>>>>>> [00001a17] 5d pop ebp
>>>>>>> [00001a18] c3 ret
>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>
>>>>>>> machine stack stack machine assembly
>>>>>>> address address data code language
>>>>>>> ======== ======== ======== ========= =============
>>>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>>
>>>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>>>> Address_of_H:1392
>>>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>>>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>
>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>>
>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>> complete simultion of the input would be non-halting.
>>>>> We must handle only one point at a time because you are easily
>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>> until this point is repeated 20 or more times.
>>>>>
>>>>> The fact that the line-by-line execution trace of the first seven
>>>>> instructions E simulated by H exactly match the behavior specified
>>>>> by the first seven instructions of the x86 source-code of E
>>>>> conclusively proves that these first seven instructions are
>>>>> simulated correctly.
>>>>>
>>>>
>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>
>>> Yes that is correct now we can move on to the next point.
>>>
>>> void E(void (*x)())
>>> {
>>> H(x, x);
>>> }
>>>
>>> int main()
>>> {
>>> Output("Input_Halts = ", H(E, E));
>>> }
>>>
>>> H: Begin Simulation Execution Trace Stored at:112b28
>>> Address_of_H:1392
>>> [000019d2][00112b14][00112b18] 55 push ebp
>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>
>>> We can see that the seventh instruction of E correctly simulated by H
>>> would call H to simulate itself again.
>>
>> No, E calls H which will HALT DECIDER (by simulation) its input.
> Try again this time don't use a noun as a verb gibberish.
>
So you can't understand that the call to H is supposed to Halt Decide
its input?
Minor typo, not gibberish like what you post that might follow correct
syntax but has a lack of semantics.
Do you agree that H(E,E) does return 0 when called?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott2@gmail.com> |
|---|---|
| Date | 2022-11-12 13:36 -0600 |
| Message-ID | <tkoskf$17pff$1@dont-email.me> |
| In reply to | #59569 |
On 11/12/2022 1:21 PM, Richard Damon wrote:
> On 11/12/22 2:04 PM, olcott wrote:
>> On 11/12/2022 12:57 PM, Richard Damon wrote:
>>> On 11/12/22 1:45 PM, olcott wrote:
>>>> On 11/12/2022 12:24 PM, Richard Damon wrote:
>>>>> On 11/12/22 1:16 PM, olcott wrote:
>>>>>> On 11/12/2022 11:59 AM, Richard Damon wrote:
>>>>>>> On 11/12/22 12:00 PM, olcott wrote:
>>>>>>>> On 11/12/2022 10:26 AM, Richard Damon wrote:
>>>>>>>>> On 11/12/22 10:50 AM, olcott wrote:
>>>>>>>>>> On 11/12/2022 9:03 AM, Mr Flibble wrote:
>>>>>>>>>>> On Sat, 12 Nov 2022 09:52:12 -0500
>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On 11/12/22 9:41 AM, Mr Flibble wrote:
>>>>>>>>>>>>> On Sat, 12 Nov 2022 09:32:23 -0500
>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>> On 11/12/22 9:09 AM, Mr Flibble wrote:
>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 19:24:53 -0500
>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>> On 11/11/22 6:55 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 18:25:58 -0500
>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>> On 11/11/22 4:54 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>> On Fri, 11 Nov 2022 16:44:49 -0500
>>>>>>>>>>>>>>>>>>> Richard Damon <Richard@Damon-Family.org> wrote:
>>>>>>>>>>>>>>>>>>>> On 11/11/22 4:15 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 3:07 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:39 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 1:30 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 2:16 PM, olcott wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/2022 12:43 PM, Richard Damon wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> On 11/11/22 1:36 PM, Mr Flibble wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> It is my understanding that Olcott has
>>>>>>>>>>>>>>>>>>>>>>>>>>> blocked you
>>>>>>>>>>>>>>>>>>>>>>>>>>> and I would have thought given your
>>>>>>>>>>>>>>>>>>>>>>>>>>> intelligence you
>>>>>>>>>>>>>>>>>>>>>>>>>>> would also understand that.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think he has actually blocked me, just
>>>>>>>>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>>>>>>>>> ignores me.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I say this because at times he seems to
>>>>>>>>>>>>>>>>>>>>>>>>>> respond to
>>>>>>>>>>>>>>>>>>>>>>>>>> what I say, even if not in a direct reply,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Also, when someone like you replies, even if
>>>>>>>>>>>>>>>>>>>>>>>>>> he has
>>>>>>>>>>>>>>>>>>>>>>>>>> blocked me, he will still see me.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> More importantly, If anyone naive wanders into
>>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>>> archives, I want enough evidence to be around
>>>>>>>>>>>>>>>>>>>>>>>>>> to point
>>>>>>>>>>>>>>>>>>>>>>>>>> out his errors.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Note also, my longer replies shows what I know
>>>>>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>>>>>> provide reasoning behind the claims, showing
>>>>>>>>>>>>>>>>>>>>>>>>>> the Truth.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> His short claims, and guff replies just show
>>>>>>>>>>>>>>>>>>>>>>>>>> that he
>>>>>>>>>>>>>>>>>>>>>>>>>> doesn't actually know what he is talking
>>>>>>>>>>>>>>>>>>>>>>>>>> about, and
>>>>>>>>>>>>>>>>>>>>>>>>>> reveals his ignorance. If he tries to put his
>>>>>>>>>>>>>>>>>>>>>>>>>> explanation into explicit words, his errors
>>>>>>>>>>>>>>>>>>>>>>>>>> become
>>>>>>>>>>>>>>>>>>>>>>>>>> very apparent, I think even to him, so he just
>>>>>>>>>>>>>>>>>>>>>>>>>> refuses.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> You always use the strawman deception as your only
>>>>>>>>>>>>>>>>>>>>>>>>> basis. Naive readers will never notice this,
>>>>>>>>>>>>>>>>>>>>>>>>> yet naive
>>>>>>>>>>>>>>>>>>>>>>>>> readers are not in my target audience.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> No, because *I* use the actual definition of a
>>>>>>>>>>>>>>>>>>>>>>>> Halting
>>>>>>>>>>>>>>>>>>>>>>>> Decider.
>>>>>>>>>>>>>>>>>>>>>>> Anyone that accepts the definition of a universal
>>>>>>>>>>>>>>>>>>>>>>> Turing
>>>>>>>>>>>>>>>>>>>>>>> machine (UTM) knows that the behavior of D correctly
>>>>>>>>>>>>>>>>>>>>>>> simulated by H provides H with a correct basis
>>>>>>>>>>>>>>>>>>>>>>> for its
>>>>>>>>>>>>>>>>>>>>>>> halt status decision.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> But only if H DOES correctly simulate its input.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> void E(void (*x)())
>>>>>>>>>>>>>>>>>>>>> {
>>>>>>>>>>>>>>>>>>>>> H(x, x);
>>>>>>>>>>>>>>>>>>>>> }
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Any H that does abort its simulation to prevent the
>>>>>>>>>>>>>>>>>>>>> infinite
>>>>>>>>>>>>>>>>>>>>> execution of E is correct to report non-halting. No
>>>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>>>> game can correctly deny this.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Any H that does aborts its simulation is INCORRECT
>>>>>>>>>>>>>>>>>>>> because
>>>>>>>>>>>>>>>>>>>> the CORRECT simulation, as will the diret exectuion,
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> halt. Note, such an H doesn't do a correct
>>>>>>>>>>>>>>>>>>>> simulation, so any
>>>>>>>>>>>>>>>>>>>> arguement based on it doing so it just WRONG.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The need to abort the simulation is due to the self
>>>>>>>>>>>>>>>>>>> reference
>>>>>>>>>>>>>>>>>>> category error present in the proof; what Olcott is
>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>> wrong is the mapping of the need to abort the
>>>>>>>>>>>>>>>>>>> simulation to a
>>>>>>>>>>>>>>>>>>> halt decision of non-halting; it needs to instead be
>>>>>>>>>>>>>>>>>>> mapped to
>>>>>>>>>>>>>>>>>>> INVALID INPUT.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Nope, no self reference.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> E just has a copy of the H that claim to be deciding
>>>>>>>>>>>>>>>>>> it, not a
>>>>>>>>>>>>>>>>>> "reference" to it. Turing Machines do not have the
>>>>>>>>>>>>>>>>>> power to
>>>>>>>>>>>>>>>>>> directly express a reference.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Nope, if it isn't a self reference then it is infinite
>>>>>>>>>>>>>>>>> copies
>>>>>>>>>>>>>>>>> all the way down so is the same category error
>>>>>>>>>>>>>>>>> manifesting in a
>>>>>>>>>>>>>>>>> different way.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Only if the "decider" makes that happen, in which case
>>>>>>>>>>>>>>>> it isn't
>>>>>>>>>>>>>>>> actually a decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> If we assume a prospective decider exists, then the
>>>>>>>>>>>>>>>> "Impossible"
>>>>>>>>>>>>>>>> program is simple to make from it, and is given one copy
>>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>>> description of itself, which is also simple to make.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When run it makes a second copy of its description, and
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> calls the decider.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> After that, it is the deciders job to make the decision
>>>>>>>>>>>>>>>> in finite
>>>>>>>>>>>>>>>> time, by whatever method it wants. If it gets stuck in your
>>>>>>>>>>>>>>>> infinite loop, the decider is just wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The proof shows that what ever answer the decider does
>>>>>>>>>>>>>>>> give (if
>>>>>>>>>>>>>>>> it gives one) will be wrong, and thus the decider
>>>>>>>>>>>>>>>> doesn't meet
>>>>>>>>>>>>>>>> the requirements.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> No "Self Reference" in sight there only a program being
>>>>>>>>>>>>>>>> given a
>>>>>>>>>>>>>>>> copy of something that just happens to be its own
>>>>>>>>>>>>>>>> description.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The only place we get any form of "Reference", is when
>>>>>>>>>>>>>>>> we try to
>>>>>>>>>>>>>>>> ANALYSE or DESIGN the H to try to meet the challenge.
>>>>>>>>>>>>>>>> There the
>>>>>>>>>>>>>>>> effect of the Self-Reference just lets us see that the
>>>>>>>>>>>>>>>> task turns
>>>>>>>>>>>>>>>> out be be impossible, so no such program exists.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> You are fractally wrong on all fronts: in the traditional
>>>>>>>>>>>>>>> halting
>>>>>>>>>>>>>>> problem proofs based on [Strachey 1965] the program is
>>>>>>>>>>>>>>> impossible
>>>>>>>>>>>>>>> not due to self reference or infinite copies but because
>>>>>>>>>>>>>>> the input
>>>>>>>>>>>>>>> tries to do the opposite of what the decider decides; the
>>>>>>>>>>>>>>> category
>>>>>>>>>>>>>>> error that I have identified is different: it is an error
>>>>>>>>>>>>>>> of self
>>>>>>>>>>>>>>> reference and/or infinite copies; it is an error related
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> fact that the input references a decider rather than
>>>>>>>>>>>>>>> being related
>>>>>>>>>>>>>>> to what the input does with the decision result of a
>>>>>>>>>>>>>>> decider.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> But the infinite copies is a error in the Decider, not in
>>>>>>>>>>>>>> Strachey's program. The decider is SUPPOSED to be able to
>>>>>>>>>>>>>> handle
>>>>>>>>>>>>>> ANY input and answer in finite time, If an input causes it
>>>>>>>>>>>>>> to make
>>>>>>>>>>>>>> infinite copies, then the decided just doesn't meet its
>>>>>>>>>>>>>> requirements.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Turing Machine can ALWAYS be legally built based on
>>>>>>>>>>>>>> another Turing
>>>>>>>>>>>>>> Machine as a base. The only reason it wouldn't be allowed
>>>>>>>>>>>>>> is if H
>>>>>>>>>>>>>> isn't actually a Turing Machine, so it CAN'T be a category
>>>>>>>>>>>>>> error
>>>>>>>>>>>>>> if H is actualy a Turing Machine.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All your declaration of a "Category Error" here is doing is
>>>>>>>>>>>>>> admitting that your H can't actually be a Turing Machine,
>>>>>>>>>>>>>> but must
>>>>>>>>>>>>>> be of a HIGHER order logic system, which means H fails the
>>>>>>>>>>>>>> requirement to be the needed decider.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In which case we get infinite turning machines all the way
>>>>>>>>>>>>> down: yet
>>>>>>>>>>>>> another manifestation of the category error I have identified.
>>>>>>>>>>>>>
>>>>>>>>>>>>> /Flibble
>>>>>>>>>>>>
>>>>>>>>>>>> Where are infinite machines? There is ONE machine being run,
>>>>>>>>>>>> either H
>>>>>>>>>>>> or D, and it SIMULATING others, and if we get an infinite
>>>>>>>>>>>> sequence of
>>>>>>>>>>>> simulations we have just shown that H was defective because
>>>>>>>>>>>> it failed
>>>>>>>>>>>> to answer in finite time.
>>>>>>>>>>>>
>>>>>>>>>>>> This isn't a category error, but a design error in H.
>>>>>>>>>>>>
>>>>>>>>>>>> Note, when we start H, there is exactly two machines present in
>>>>>>>>>>>> representation on the tape, and two is much smaller than
>>>>>>>>>>>> infinity.
>>>>>>>>>>>
>>>>>>>>>>> Nope, if,
>>>>>>>>>>>
>>>>>>>>>>> a) H is a copy, and
>>>>>>>>>>> b) H is a Turing Machine, and
>>>>>>>>>>> c) D is an input into H, and
>>>>>>>>>>> d) D references H, and
>>>>>>>>>>> e) H references D,
>>>>>>>>>>>
>>>>>>>>>>> then (d) and (e) repeat ad infinitum so we get infinite
>>>>>>>>>>> Turing Machines
>>>>>>>>>>> all the way down: a manifestation of the category error I have
>>>>>>>>>>> identified.
>>>>>>>>>>>
>>>>>>>>>>> /Flibble
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> void E(void (*x)())
>>>>>>>>>> {
>>>>>>>>>> H(x, x);
>>>>>>>>>> }
>>>>>>>>>>
>>>>>>>>>> The point is
>>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>> correct simulation.
>>>>>>>>>>
>>>>>>>>>> When H returns 0 to main() it is indicating
>>>>>>>>>>
>>>>>>>>>> that D correctly simulated by H would never reach its own last
>>>>>>>>>> instruction and terminate normally after 1 to ∞ steps of
>>>>>>>>>> correct simulation.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Except D is NOT correctly simulated by H, so that is a
>>>>>>>>> incorrect statement. When it is correctly simulated by
>>>>>>>>> something other than H, it will come to a final state, showing
>>>>>>>>> your statement is wrong.
>>>>>>>> In order for the simulation to actually be incorrect the
>>>>>>>> execution trace of the simulated E must diverge from the
>>>>>>>> behavior that the line-by-line x86 source-code of E specifies.
>>>>>>>
>>>>>>> Right, and since you simulation does NOT continue past the call
>>>>>>> to H, it is "incorrect" in the sense that the actual code does
>>>>>>> continue past that point, so it does not actually match the
>>>>>>> behavior of that machine.
>>>>>>>
>>>>>>>>
>>>>>>>> The first seven lines of the execution trace of the simulated E
>>>>>>>> exactly match the behavior specified by the first seven lines of
>>>>>>>> the x86 source code of E. This conclusively proves beyond all
>>>>>>>> possible doubt that these first seven lines have been simulated
>>>>>>>> correctly.
>>>>>>>
>>>>>>> Right, so H has correctly done a PARTIAL simulation of its input,
>>>>>>> which does NOT prove the input is non-halting.
>>>>>>>
>>>>>>>>
>>>>>>>> *H correctly determines that E never halts*
>>>>>>>>
>>>>>>>> void E(void (*x)())
>>>>>>>> {
>>>>>>>> H(x, x);
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> int main()
>>>>>>>> {
>>>>>>>> Output("Input_Halts = ", H(E, E));
>>>>>>>> }
>>>>>>>>
>>>>>>>> _E()
>>>>>>>> [000019d2] 55 push ebp
>>>>>>>> [000019d3] 8bec mov ebp,esp
>>>>>>>> [000019d5] 8b4508 mov eax,[ebp+08]
>>>>>>>> [000019d8] 50 push eax
>>>>>>>> [000019d9] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [000019dc] 51 push ecx
>>>>>>>> [000019dd] e8b0f9ffff call 00001392
>>>>>>>> [000019e2] 83c408 add esp,+08
>>>>>>>> [000019e5] 5d pop ebp
>>>>>>>> [000019e6] c3 ret
>>>>>>>> Size in bytes:(0021) [000019e6]
>>>>>>>>
>>>>>>>> _main()
>>>>>>>> [000019f2] 55 push ebp
>>>>>>>> [000019f3] 8bec mov ebp,esp
>>>>>>>> [000019f5] 68d2190000 push 000019d2
>>>>>>>> [000019fa] 68d2190000 push 000019d2
>>>>>>>> [000019ff] e88ef9ffff call 00001392
>>>>>>>> [00001a04] 83c408 add esp,+08
>>>>>>>> [00001a07] 50 push eax
>>>>>>>> [00001a08] 6893060000 push 00000693
>>>>>>>> [00001a0d] e8a0ecffff call 000006b2
>>>>>>>> [00001a12] 83c408 add esp,+08
>>>>>>>> [00001a15] 33c0 xor eax,eax
>>>>>>>> [00001a17] 5d pop ebp
>>>>>>>> [00001a18] c3 ret
>>>>>>>> Size in bytes:(0039) [00001a18]
>>>>>>>>
>>>>>>>> machine stack stack machine assembly
>>>>>>>> address address data code language
>>>>>>>> ======== ======== ======== ========= =============
>>>>>>>> [000019f2][00102a7c][00000000] 55 push ebp
>>>>>>>> [000019f3][00102a7c][00000000] 8bec mov ebp,esp
>>>>>>>> [000019f5][00102a78][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>> [000019fa][00102a74][000019d2] 68d2190000 push 000019d2 // push E
>>>>>>>> [000019ff][00102a70][00001a04] e88ef9ffff call 00001392 // call H
>>>>>>>>
>>>>>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>>>>>> Address_of_H:1392
>>>>>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>>>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>>>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>>>>>> [000019d8][00112b10][000019d2] 50 push eax //
>>>>>>>> push E
>>>>>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>>>>>> [000019dc][00112b0c][000019d2] 51 push ecx //
>>>>>>>> push E
>>>>>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 //
>>>>>>>> call H
>>>>>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>>>>>
>>>>>>>> H correctly reports that E correctly simulated by H cannot
>>>>>>>> possibly reach its own final state at machine address [000019e6]
>>>>>>>> and terminate normally in 1 to ∞ steps of correct simulation.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> So you are just admitting you don't understand the Halting Criteria.
>>>>>>>
>>>>>>> The fact that H stops its simulation before it gets to the end
>>>>>>> does NOT prove that the machine being simulated, or a correct and
>>>>>>> complete simultion of the input would be non-halting.
>>>>>> We must handle only one point at a time because you are easily
>>>>>> overwhelmed. You usually cannot even handle one point at a time
>>>>>> until this point is repeated 20 or more times.
>>>>>>
>>>>>> The fact that the line-by-line execution trace of the first seven
>>>>>> instructions E simulated by H exactly match the behavior specified
>>>>>> by the first seven instructions of the x86 source-code of E
>>>>>> conclusively proves that these first seven instructions are
>>>>>> simulated correctly.
>>>>>>
>>>>>
>>>>> No, that says that H did a correct PARTIAL simulation of the input.
>>>>
>>>> Yes that is correct now we can move on to the next point.
>>>>
>>>> void E(void (*x)())
>>>> {
>>>> H(x, x);
>>>> }
>>>>
>>>> int main()
>>>> {
>>>> Output("Input_Halts = ", H(E, E));
>>>> }
>>>>
>>>> H: Begin Simulation Execution Trace Stored at:112b28
>>>> Address_of_H:1392
>>>> [000019d2][00112b14][00112b18] 55 push ebp
>>>> [000019d3][00112b14][00112b18] 8bec mov ebp,esp
>>>> [000019d5][00112b14][00112b18] 8b4508 mov eax,[ebp+08]
>>>> [000019d8][00112b10][000019d2] 50 push eax // push E
>>>> [000019d9][00112b10][000019d2] 8b4d08 mov ecx,[ebp+08]
>>>> [000019dc][00112b0c][000019d2] 51 push ecx // push E
>>>> [000019dd][00112b08][000019e2] e8b0f9ffff call 00001392 // call H
>>>> H: Infinitely Recursive Simulation Detected Simulation Stopped
>>>>
>>>> We can see that the seventh instruction of E correctly simulated by
>>>> H would call H to simulate itself again.
>>>
>>> No, E calls H which will HALT DECIDER (by simulation) its input.
>> Try again this time don't use a noun as a verb gibberish.
>>
>
> So you can't understand that the call to H is supposed to Halt Decide
> its input?
>
> Minor typo, not gibberish like what you post that might follow correct
> syntax but has a lack of semantics.
>
> Do you agree that H(E,E) does return 0 when called?
Again you leap ahead past the point at hand. Doing this makes sure that
the point at hand is never addressed and you false assumptions continue.
It is agreed that H does correctly simulate the first seven instructions
of E.
The first seven instructions of E correctly simulated by H show that E
would call H to simulate itself again and that no instructions from the
beginning of E to its call to H can possibly prevent this from repeating
an unlimited number of times.
--
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]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.theory
csiph-web