Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #334468 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-23 12:04 -0500 |
| Last post | 2024-05-26 08:38 -0500 |
| Articles | 20 on this page of 146 — 5 participants |
Back to article view | Back to sci.logic
Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-23 12:04 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-23 21:44 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-23 21:22 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-23 22:41 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-23 22:06 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-23 23:47 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-23 22:59 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 07:18 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 14:57 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 17:03 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 16:27 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 18:17 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-24 12:46 +0200
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 07:14 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 14:52 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 17:03 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 16:35 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 18:18 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 12:06 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 13:25 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 15:03 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 17:03 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 16:37 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 18:18 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-24 09:37 +0200
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 12:10 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 13:25 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 15:01 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 17:03 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 16:39 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 18:17 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 17:20 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-24 19:20 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 23:28 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-25 08:52 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-25 12:56 -0500
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Richard Damon <richard@damon-family.org> - 2024-05-25 14:16 -0400
D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 13:27 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 15:23 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 14:55 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 16:16 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 15:20 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 17:04 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 16:13 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 17:18 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 16:29 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 17:45 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:03 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:36 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:40 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:49 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:52 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:57 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:13 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:36 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:40 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:49 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 17:53 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 18:59 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 18:11 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 19:14 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 18:23 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 19:40 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 19:12 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 21:23 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 19:45 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 21:23 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 20:47 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 22:06 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 21:09 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 22:18 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 21:16 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Richard Damon <richard@damon-family.org> - 2024-05-25 22:19 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? olcott <polcott333@gmail.com> - 2024-05-25 21:03 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? Richard Damon <richard@damon-family.org> - 2024-05-25 22:25 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? olcott <polcott333@gmail.com> - 2024-05-25 21:40 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? Richard Damon <richard@damon-family.org> - 2024-05-26 07:43 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? olcott <polcott333@gmail.com> - 2024-05-26 09:13 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Dishonest? Richard Damon <richard@damon-family.org> - 2024-05-26 12:31 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- olcott <polcott333@gmail.com> - 2024-05-26 12:01 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Richard Damon <richard@damon-family.org> - 2024-05-26 13:16 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- olcott <polcott333@gmail.com> - 2024-05-26 12:26 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Richard Damon <richard@damon-family.org> - 2024-05-26 13:48 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz proof olcott <polcott333@gmail.com> - 2024-05-26 12:54 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz proof Richard Damon <richard@damon-family.org> - 2024-05-26 14:01 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz proof olcott <polcott333@gmail.com> - 2024-05-26 13:11 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz proof Richard Damon <richard@damon-family.org> - 2024-05-26 14:23 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz olcott <polcott333@gmail.com> - 2024-05-26 14:14 -0500
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 --- Linz Richard Damon <richard@damon-family.org> - 2024-05-26 16:20 -0400
A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 17:47 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 19:07 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 18:45 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 20:15 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 19:21 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 20:44 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 20:03 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 21:19 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 21:06 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 22:30 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 21:53 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 23:15 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 21:43 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 23:05 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 22:17 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-26 23:30 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-26 22:47 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 09:27 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 09:25 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 10:48 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 10:06 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 11:25 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 10:46 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 11:58 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 11:22 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 12:33 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 14:45 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 17:21 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 17:32 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 18:44 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 19:08 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 20:17 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 19:26 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 20:48 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 20:04 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 21:24 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 20:39 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 21:54 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 21:01 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 22:23 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 21:41 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-27 22:52 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 21:59 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-28 07:34 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-28 10:20 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-01 09:37 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Richard Damon <richard@damon-family.org> - 2024-06-01 11:20 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details joes <noreply@example.com> - 2024-06-01 18:52 +0000
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-01 14:26 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Richard Damon <richard@damon-family.org> - 2024-06-01 15:45 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-27 22:24 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-28 07:34 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-28 10:37 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-28 22:04 -0400
Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 Alan Mackenzie <acm@muc.de> - 2024-05-25 21:09 +0000
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-26 12:47 +0200
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-26 08:38 -0500
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-27 20:17 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v337r0$29dee$2@i2pn2.org> |
| In reply to | #334639 |
On 5/27/24 8:08 PM, olcott wrote:
> On 5/27/2024 5:44 PM, Richard Damon wrote:
>> On 5/27/24 6:32 PM, olcott wrote:
>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>> 01 int D(ptr p)
>>>>>>>>> 02 {
>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>> 06 return Halt_Status;
>>>>>>>>> 07 }
>>>>>>>>> 08
>>>>>>>>> 09 int main()
>>>>>>>>> 10 {
>>>>>>>>> 11 H(D,D);
>>>>>>>>> 12 return 0;
>>>>>>>>> 13 }
>>>>>>>>>
>>>>>>>>> The above template refers to an infinite set of H/D pairs where
>>>>>>>>> D is
>>>>>>>>> correctly simulated by either pure simulator H or pure function
>>>>>>>>> H. This
>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>> endlessly
>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>
>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>> notion of
>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>
>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1 to
>>>>>>>>> N of the
>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>> instructions
>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>> emulating itself
>>>>>>>>> emulating D.
>>>>>>>>
>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define what
>>>>>>>> a call H means (as it could be any of the infinite set of Hs
>>>>>>>> that you can instantiate the template on)?
>>>>>>>>
>>>>>>>
>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>
>>>>>> I note that YOU keep on switching between your C program and
>>>>>> Turing Machines.
>>>>>>
>>>>>> Note, per the implications that you implicitly agreed to (by not
>>>>>> even trying to refute) the two systems are NOT equivalents of each
>>>>>> other.
>>>>>>
>>>>>
>>>>> (1) I think you are wrong. I have not seen any of your
>>>>> reasoning that was not anchored in false assumptions.
>>>>> Your make fake rebuttal is to change the subject.
>>>>>
>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>> basis to perfectly anchor things such as the correct meaning
>>>>> of D correctly simulated by H so that people cannot get away
>>>>> with claiming that an incorrect simulation is correct.
>>>>>
>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED
>>>>> BY H.
>>>>> One cannot simply ignore the pathological relationship between H
>>>>> and D.
>>>>>
>>>>>>>
>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>
>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>
>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>
>>>>>> And what you do mean by that?
>>>>>>
>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>
>>>>> The original proof does not consider the notion of a simulating
>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>> than any definition of H.
>>>>
>>>> The biggest problem is that the input to the Turing machine decider
>>>> H is the description of a Turing Machine H^, which is a SPECIFIC
>>>> machine,
>>>
>>> When you say "specific machine" you don't mean anything like a
>>> 100% completely specified sequence of state transitions encoded
>>> as a single unique finite string.
>>
>> Mostly.
>>
>> There doesn't need to be a unique finite string, but it is a 100%
>> completely specified state transition/tape operation table.
>>
>
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> In other words Linz did not prove that there are no set
> of state transitions specified by ⊢* that derives the
> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>
> He only said there there is one specific machine that
> gets the wrong answer.
>
He STARTS with a proof that one specific (but arbitrary) machine gets
the wrong answer.
Then he shows that the same proof can be applied to ANY such machine
(becaue the proof didn't depend on any specific details of the machine,
just the general properties of that machine)
I guess you don't understand how to do categorical proofs.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 19:26 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v338c5$94g8$1@dont-email.me> |
| In reply to | #334640 |
On 5/27/2024 7:17 PM, Richard Damon wrote:
> On 5/27/24 8:08 PM, olcott wrote:
>> On 5/27/2024 5:44 PM, Richard Damon wrote:
>>> On 5/27/24 6:32 PM, olcott wrote:
>>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>> 02 {
>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 int main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11 H(D,D);
>>>>>>>>>> 12 return 0;
>>>>>>>>>> 13 }
>>>>>>>>>>
>>>>>>>>>> The above template refers to an infinite set of H/D pairs
>>>>>>>>>> where D is
>>>>>>>>>> correctly simulated by either pure simulator H or pure
>>>>>>>>>> function H. This
>>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>>> endlessly
>>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>>
>>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>>> notion of
>>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>>
>>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1
>>>>>>>>>> to N of the
>>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>>> instructions
>>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>>> emulating itself
>>>>>>>>>> emulating D.
>>>>>>>>>
>>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define
>>>>>>>>> what a call H means (as it could be any of the infinite set of
>>>>>>>>> Hs that you can instantiate the template on)?
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>>
>>>>>>> I note that YOU keep on switching between your C program and
>>>>>>> Turing Machines.
>>>>>>>
>>>>>>> Note, per the implications that you implicitly agreed to (by not
>>>>>>> even trying to refute) the two systems are NOT equivalents of
>>>>>>> each other.
>>>>>>>
>>>>>>
>>>>>> (1) I think you are wrong. I have not seen any of your
>>>>>> reasoning that was not anchored in false assumptions.
>>>>>> Your make fake rebuttal is to change the subject.
>>>>>>
>>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>>> basis to perfectly anchor things such as the correct meaning
>>>>>> of D correctly simulated by H so that people cannot get away
>>>>>> with claiming that an incorrect simulation is correct.
>>>>>>
>>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED
>>>>>> BY H.
>>>>>> One cannot simply ignore the pathological relationship between H
>>>>>> and D.
>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>>
>>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>>
>>>>>>> And what you do mean by that?
>>>>>>>
>>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>>
>>>>>> The original proof does not consider the notion of a simulating
>>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>>> than any definition of H.
>>>>>
>>>>> The biggest problem is that the input to the Turing machine decider
>>>>> H is the description of a Turing Machine H^, which is a SPECIFIC
>>>>> machine,
>>>>
>>>> When you say "specific machine" you don't mean anything like a
>>>> 100% completely specified sequence of state transitions encoded
>>>> as a single unique finite string.
>>>
>>> Mostly.
>>>
>>> There doesn't need to be a unique finite string, but it is a 100%
>>> completely specified state transition/tape operation table.
>>>
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> In other words Linz did not prove that there are no set
>> of state transitions specified by ⊢* that derives the
>> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> He only said there there is one specific machine that
>> gets the wrong answer.
>>
>
> He STARTS with a proof that one specific (but arbitrary) machine gets
> the wrong answer.
>
> Then he shows that the same proof can be applied to ANY such machine
> (becaue the proof didn't depend on any specific details of the machine,
> just the general properties of that machine)
>
> I guess you don't understand how to do categorical proofs.
>
I totally do. Can you please write down the
"completely specified state transition/tape operation table."
of this specific (thus uniquely identifiable) machine I would
really like to see it.
--
Copyright 2024 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 | 2024-05-27 20:48 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v339kr$29dee$3@i2pn2.org> |
| In reply to | #334641 |
On 5/27/24 8:26 PM, olcott wrote:
> On 5/27/2024 7:17 PM, Richard Damon wrote:
>> On 5/27/24 8:08 PM, olcott wrote:
>>> On 5/27/2024 5:44 PM, Richard Damon wrote:
>>>> On 5/27/24 6:32 PM, olcott wrote:
>>>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>> 02 {
>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>> 07 }
>>>>>>>>>>> 08
>>>>>>>>>>> 09 int main()
>>>>>>>>>>> 10 {
>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>> 12 return 0;
>>>>>>>>>>> 13 }
>>>>>>>>>>>
>>>>>>>>>>> The above template refers to an infinite set of H/D pairs
>>>>>>>>>>> where D is
>>>>>>>>>>> correctly simulated by either pure simulator H or pure
>>>>>>>>>>> function H. This
>>>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>>>> endlessly
>>>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>>>
>>>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>>>> notion of
>>>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>>>
>>>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1
>>>>>>>>>>> to N of the
>>>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>>>> instructions
>>>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>>>> emulating itself
>>>>>>>>>>> emulating D.
>>>>>>>>>>
>>>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define
>>>>>>>>>> what a call H means (as it could be any of the infinite set of
>>>>>>>>>> Hs that you can instantiate the template on)?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>>>
>>>>>>>> I note that YOU keep on switching between your C program and
>>>>>>>> Turing Machines.
>>>>>>>>
>>>>>>>> Note, per the implications that you implicitly agreed to (by not
>>>>>>>> even trying to refute) the two systems are NOT equivalents of
>>>>>>>> each other.
>>>>>>>>
>>>>>>>
>>>>>>> (1) I think you are wrong. I have not seen any of your
>>>>>>> reasoning that was not anchored in false assumptions.
>>>>>>> Your make fake rebuttal is to change the subject.
>>>>>>>
>>>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>>>> basis to perfectly anchor things such as the correct meaning
>>>>>>> of D correctly simulated by H so that people cannot get away
>>>>>>> with claiming that an incorrect simulation is correct.
>>>>>>>
>>>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED
>>>>>>> BY H.
>>>>>>> One cannot simply ignore the pathological relationship between H
>>>>>>> and D.
>>>>>>>
>>>>>>>>>
>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>
>>>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>>>
>>>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>>>
>>>>>>>> And what you do mean by that?
>>>>>>>>
>>>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>>>
>>>>>>> The original proof does not consider the notion of a simulating
>>>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>>>> than any definition of H.
>>>>>>
>>>>>> The biggest problem is that the input to the Turing machine
>>>>>> decider H is the description of a Turing Machine H^, which is a
>>>>>> SPECIFIC machine,
>>>>>
>>>>> When you say "specific machine" you don't mean anything like a
>>>>> 100% completely specified sequence of state transitions encoded
>>>>> as a single unique finite string.
>>>>
>>>> Mostly.
>>>>
>>>> There doesn't need to be a unique finite string, but it is a 100%
>>>> completely specified state transition/tape operation table.
>>>>
>>>
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>
>>> In other words Linz did not prove that there are no set
>>> of state transitions specified by ⊢* that derives the
>>> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>
>>> He only said there there is one specific machine that
>>> gets the wrong answer.
>>>
>>
>> He STARTS with a proof that one specific (but arbitrary) machine gets
>> the wrong answer.
>>
>> Then he shows that the same proof can be applied to ANY such machine
>> (becaue the proof didn't depend on any specific details of the
>> machine, just the general properties of that machine)
>>
>> I guess you don't understand how to do categorical proofs.
>>
>
> I totally do. Can you please write down the
> "completely specified state transition/tape operation table."
> of this specific (thus uniquely identifiable) machine I would
> really like to see it.
>
But it was proven that no such machine exists!
Remember, the proof starts with the hypothetical that such a machine
exists. Such a machine WOULD HAVE a completely specified state
transition/tape operation table.
(The fact you ask the question means you don't understand the method of
proof).
Given the assumption of such a machine, we can show how to construct the
H^ machine to test it with.
We can then show that, whatever the actual behavior of the machine H, it
will be wrong.
Thus we proved that machine didn't meet the requirements.
And, because we didn't use any specific details of that machine, we can
show that we can do the same for ANY machine that might claim to be a
halt decider.
Sort of like the proof that there doesn't exist a highest prime number,
we first presume that there might be, and then show how that assumption
proves itself wrong.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 20:04 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33aj7$9f3u$1@dont-email.me> |
| In reply to | #334642 |
On 5/27/2024 7:48 PM, Richard Damon wrote:
> On 5/27/24 8:26 PM, olcott wrote:
>> On 5/27/2024 7:17 PM, Richard Damon wrote:
>>> On 5/27/24 8:08 PM, olcott wrote:
>>>> On 5/27/2024 5:44 PM, Richard Damon wrote:
>>>>> On 5/27/24 6:32 PM, olcott wrote:
>>>>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>> 02 {
>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>> 07 }
>>>>>>>>>>>> 08
>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>> 10 {
>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>> 13 }
>>>>>>>>>>>>
>>>>>>>>>>>> The above template refers to an infinite set of H/D pairs
>>>>>>>>>>>> where D is
>>>>>>>>>>>> correctly simulated by either pure simulator H or pure
>>>>>>>>>>>> function H. This
>>>>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>>>>> endlessly
>>>>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>>>>
>>>>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>>>>> notion of
>>>>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>>>>
>>>>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1
>>>>>>>>>>>> to N of the
>>>>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>>>>> instructions
>>>>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>>>>> emulating itself
>>>>>>>>>>>> emulating D.
>>>>>>>>>>>
>>>>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define
>>>>>>>>>>> what a call H means (as it could be any of the infinite set
>>>>>>>>>>> of Hs that you can instantiate the template on)?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>>>>
>>>>>>>>> I note that YOU keep on switching between your C program and
>>>>>>>>> Turing Machines.
>>>>>>>>>
>>>>>>>>> Note, per the implications that you implicitly agreed to (by
>>>>>>>>> not even trying to refute) the two systems are NOT equivalents
>>>>>>>>> of each other.
>>>>>>>>>
>>>>>>>>
>>>>>>>> (1) I think you are wrong. I have not seen any of your
>>>>>>>> reasoning that was not anchored in false assumptions.
>>>>>>>> Your make fake rebuttal is to change the subject.
>>>>>>>>
>>>>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>>>>> basis to perfectly anchor things such as the correct meaning
>>>>>>>> of D correctly simulated by H so that people cannot get away
>>>>>>>> with claiming that an incorrect simulation is correct.
>>>>>>>>
>>>>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY
>>>>>>>> SIMULATED BY H.
>>>>>>>> One cannot simply ignore the pathological relationship between H
>>>>>>>> and D.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>
>>>>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>>>>
>>>>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>>>>
>>>>>>>>> And what you do mean by that?
>>>>>>>>>
>>>>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>>>>
>>>>>>>> The original proof does not consider the notion of a simulating
>>>>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>>>>> than any definition of H.
>>>>>>>
>>>>>>> The biggest problem is that the input to the Turing machine
>>>>>>> decider H is the description of a Turing Machine H^, which is a
>>>>>>> SPECIFIC machine,
>>>>>>
>>>>>> When you say "specific machine" you don't mean anything like a
>>>>>> 100% completely specified sequence of state transitions encoded
>>>>>> as a single unique finite string.
>>>>>
>>>>> Mostly.
>>>>>
>>>>> There doesn't need to be a unique finite string, but it is a 100%
>>>>> completely specified state transition/tape operation table.
>>>>>
>>>>
>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>
>>>> In other words Linz did not prove that there are no set
>>>> of state transitions specified by ⊢* that derives the
>>>> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>
>>>> He only said there there is one specific machine that
>>>> gets the wrong answer.
>>>>
>>>
>>> He STARTS with a proof that one specific (but arbitrary) machine gets
>>> the wrong answer.
>>>
>>> Then he shows that the same proof can be applied to ANY such machine
>>> (becaue the proof didn't depend on any specific details of the
>>> machine, just the general properties of that machine)
>>>
>>> I guess you don't understand how to do categorical proofs.
>>>
>>
>> I totally do. Can you please write down the
>> "completely specified state transition/tape operation table."
>> of this specific (thus uniquely identifiable) machine I would
>> really like to see it.
>>
>
> But it was proven that no such machine exists!
>
> Remember, the proof starts with the hypothetical that such a machine
> exists. Such a machine WOULD HAVE a completely specified state
> transition/tape operation table.
>
That is not what you said.
>>>>> There doesn't need to be a unique finite string, but it is a 100%
>>>>> completely specified state transition/tape operation table.
"a 100% completely specified state transition/tape operation table"
of a non-existent machine.
> (The fact you ask the question means you don't understand the method of
> proof).
>
Socratic questions resulted in you contradicting yourself, exactly as I
expected. That is how Socratic questions work. When someone contradicts
themselves they say whoops, lets try again.
A Troll would say: "I never contradicted myself you liar!"
Socratic questions expose Trolls for all to see.
> Given the assumption of such a machine, we can show how to construct the
> H^ machine to test it with.
>
> We can then show that, whatever the actual behavior of the machine H, it
> will be wrong.
>
There is no "whatever the actual behavior" of a specific machine.
That only applies to a set of implementations of a machine.
> Thus we proved that machine didn't meet the requirements.
>
No we actually proved that you were never really talking about
a single specific machine.
> And, because we didn't use any specific details of that machine, we can
> show that we can do the same for ANY machine that might claim to be a
> halt decider.
>
A set of machines specified by a template have common properties.
> Sort of like the proof that there doesn't exist a highest prime number,
> we first presume that there might be, and then show how that assumption
> proves itself wrong.
>
>
*Just like when we see that when we know that*
⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
own simulated final state of ⟨Ĥ.qn⟩ and halt in an infinite sequence of
correctly simulated steps we can see that this also applies to every
less than infinite (AKA finite) sequence.
Like mathematical induction in reverse.
--
Copyright 2024 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 | 2024-05-27 21:24 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33bo5$29def$4@i2pn2.org> |
| In reply to | #334643 |
On 5/27/24 9:04 PM, olcott wrote:
> On 5/27/2024 7:48 PM, Richard Damon wrote:
>> On 5/27/24 8:26 PM, olcott wrote:
>>> On 5/27/2024 7:17 PM, Richard Damon wrote:
>>>> On 5/27/24 8:08 PM, olcott wrote:
>>>>> On 5/27/2024 5:44 PM, Richard Damon wrote:
>>>>>> On 5/27/24 6:32 PM, olcott wrote:
>>>>>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>>>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>>>>> 02 {
>>>>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>>>>> 07 }
>>>>>>>>>>>>> 08
>>>>>>>>>>>>> 09 int main()
>>>>>>>>>>>>> 10 {
>>>>>>>>>>>>> 11 H(D,D);
>>>>>>>>>>>>> 12 return 0;
>>>>>>>>>>>>> 13 }
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above template refers to an infinite set of H/D pairs
>>>>>>>>>>>>> where D is
>>>>>>>>>>>>> correctly simulated by either pure simulator H or pure
>>>>>>>>>>>>> function H. This
>>>>>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>>>>>> endlessly
>>>>>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>>>>>
>>>>>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>>>>>> notion of
>>>>>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>>>>>
>>>>>>>>>>>>> A simulator is an x86 emulator that correctly emulates
>>>>>>>>>>>>> 1 to N of the
>>>>>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>>>>>> instructions
>>>>>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>>>>>> emulating itself
>>>>>>>>>>>>> emulating D.
>>>>>>>>>>>>
>>>>>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define
>>>>>>>>>>>> what a call H means (as it could be any of the infinite set
>>>>>>>>>>>> of Hs that you can instantiate the template on)?
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>>>>>
>>>>>>>>>> I note that YOU keep on switching between your C program and
>>>>>>>>>> Turing Machines.
>>>>>>>>>>
>>>>>>>>>> Note, per the implications that you implicitly agreed to (by
>>>>>>>>>> not even trying to refute) the two systems are NOT equivalents
>>>>>>>>>> of each other.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> (1) I think you are wrong. I have not seen any of your
>>>>>>>>> reasoning that was not anchored in false assumptions.
>>>>>>>>> Your make fake rebuttal is to change the subject.
>>>>>>>>>
>>>>>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>>>>>> basis to perfectly anchor things such as the correct meaning
>>>>>>>>> of D correctly simulated by H so that people cannot get away
>>>>>>>>> with claiming that an incorrect simulation is correct.
>>>>>>>>>
>>>>>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY
>>>>>>>>> SIMULATED BY H.
>>>>>>>>> One cannot simply ignore the pathological relationship between
>>>>>>>>> H and D.
>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>>>>
>>>>>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>>>>>
>>>>>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>>>>>
>>>>>>>>>> And what you do mean by that?
>>>>>>>>>>
>>>>>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>>>>>
>>>>>>>>> The original proof does not consider the notion of a simulating
>>>>>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>>>>>> than any definition of H.
>>>>>>>>
>>>>>>>> The biggest problem is that the input to the Turing machine
>>>>>>>> decider H is the description of a Turing Machine H^, which is a
>>>>>>>> SPECIFIC machine,
>>>>>>>
>>>>>>> When you say "specific machine" you don't mean anything like a
>>>>>>> 100% completely specified sequence of state transitions encoded
>>>>>>> as a single unique finite string.
>>>>>>
>>>>>> Mostly.
>>>>>>
>>>>>> There doesn't need to be a unique finite string, but it is a 100%
>>>>>> completely specified state transition/tape operation table.
>>>>>>
>>>>>
>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>
>>>>> In other words Linz did not prove that there are no set
>>>>> of state transitions specified by ⊢* that derives the
>>>>> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>>>>
>>>>> He only said there there is one specific machine that
>>>>> gets the wrong answer.
>>>>>
>>>>
>>>> He STARTS with a proof that one specific (but arbitrary) machine
>>>> gets the wrong answer.
>>>>
>>>> Then he shows that the same proof can be applied to ANY such machine
>>>> (becaue the proof didn't depend on any specific details of the
>>>> machine, just the general properties of that machine)
>>>>
>>>> I guess you don't understand how to do categorical proofs.
>>>>
>>>
>>> I totally do. Can you please write down the
>>> "completely specified state transition/tape operation table."
>>> of this specific (thus uniquely identifiable) machine I would
>>> really like to see it.
>>>
>>
>> But it was proven that no such machine exists!
>>
>> Remember, the proof starts with the hypothetical that such a machine
>> exists. Such a machine WOULD HAVE a completely specified state
>> transition/tape operation table.
>>
>
> That is not what you said.
> >>>>> There doesn't need to be a unique finite string, but it is a 100%
> >>>>> completely specified state transition/tape operation table.
>
> "a 100% completely specified state transition/tape operation table"
> of a non-existent machine.
Right, by presuming that you have a Turing Machine, you have a completly
specified state transition/tape operation table.
You may not KNOW what that table is if you don't know what the exact
machine is, but you know it exists.
>
>> (The fact you ask the question means you don't understand the method
>> of proof).
>>
>
> Socratic questions resulted in you contradicting yourself, exactly as I
> expected. That is how Socratic questions work. When someone contradicts
> themselves they say whoops, lets try again.
Nope. Just shows you don't understand the meaning of the worda.
>
> A Troll would say: "I never contradicted myself you liar!"
> Socratic questions expose Trolls for all to see.
So, what was the "Lie", tell me or just prove yourself to be the Troll
liar you are talking about.
Note,
>
>> Given the assumption of such a machine, we can show how to construct
>> the H^ machine to test it with.
>>
>> We can then show that, whatever the actual behavior of the machine H,
>> it will be wrong.
>>
>
> There is no "whatever the actual behavior" of a specific machine.
> That only applies to a set of implementations of a machine.
???
A given machine has a behavior.
If we don't care about the details of that behavior, we can say WHATEVER
THAT BEHAVIOR WAS.
You just don't understand how English works.
>
>> Thus we proved that machine didn't meet the requirements.
>>
>
> No we actually proved that you were never really talking about
> a single specific machine.
Nope, just that you don't understand what anything means.
>
>> And, because we didn't use any specific details of that machine, we
>> can show that we can do the same for ANY machine that might claim to
>> be a halt decider.
>>
>
> A set of machines specified by a template have common properties.
Maybe. but the are still different, and thus are not identical.
>
>> Sort of like the proof that there doesn't exist a highest prime
>> number, we first presume that there might be, and then show how that
>> assumption proves itself wrong.
>>
>>
>
> *Just like when we see that when we know that*
> ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly reach its
> own simulated final state of ⟨Ĥ.qn⟩ and halt in an infinite sequence of
> correctly simulated steps we can see that this also applies to every
> less than infinite (AKA finite) sequence.
>
> Like mathematical induction in reverse.
>
Nope. How do you simulate a template? Especially when it gets into the
variable part?
You never answered that one.
Your logic is just broken.
You can only trace in detail a detail specific machine, which is the
type of simulation you have defined being done, so it can't be of a
template, so you claim that it is a template just shows that you have lied.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 20:39 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33ckr$dg88$1@dont-email.me> |
| In reply to | #334644 |
On 5/27/2024 8:24 PM, Richard Damon wrote: > On 5/27/24 9:04 PM, olcott wrote: >>>> I totally do. Can you please write down the >>>> "completely specified state transition/tape operation table." >>>> of this specific (thus uniquely identifiable) machine I would >>>> really like to see it. >>>> >>> >>> But it was proven that no such machine exists! >>> >>> Remember, the proof starts with the hypothetical that such a machine >>> exists. Such a machine WOULD HAVE a completely specified state >>> transition/tape operation table. >>> >> >> That is not what you said. >> >>>>> There doesn't need to be a unique finite string, but it is a 100% >> >>>>> completely specified state transition/tape operation table. >> >> "a 100% completely specified state transition/tape operation table" >> of a non-existent machine. > > Right, by presuming that you have a Turing Machine, you have a completly > specified state transition/tape operation table. > > You may not KNOW what that table is if you don't know what the exact > machine is, but you know it exists. > > >>> But it was proven that no such machine exists! If you can't notice that you are contradicting yourself it seems that no further progress can be made with you. -- Copyright 2024 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 | 2024-05-27 21:54 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33dg9$29def$5@i2pn2.org> |
| In reply to | #334645 |
On 5/27/24 9:39 PM, olcott wrote: > On 5/27/2024 8:24 PM, Richard Damon wrote: >> On 5/27/24 9:04 PM, olcott wrote: > >>>>> I totally do. Can you please write down the >>>>> "completely specified state transition/tape operation table." >>>>> of this specific (thus uniquely identifiable) machine I would >>>>> really like to see it. >>>>> >>>> >>>> But it was proven that no such machine exists! >>>> >>>> Remember, the proof starts with the hypothetical that such a machine >>>> exists. Such a machine WOULD HAVE a completely specified state >>>> transition/tape operation table. >>>> >>> >>> That is not what you said. >>> >>>>> There doesn't need to be a unique finite string, but it is a 100% >>> >>>>> completely specified state transition/tape operation table. >>> >>> "a 100% completely specified state transition/tape operation table" >>> of a non-existent machine. >> >> Right, by presuming that you have a Turing Machine, you have a >> completly specified state transition/tape operation table. >> >> You may not KNOW what that table is if you don't know what the exact >> machine is, but you know it exists. >> >> > > >>> But it was proven that no such machine exists! > > If you can't notice that you are contradicting yourself > it seems that no further progress can be made with you. > > Nope. You just don't understand how a proof by contradiction works, do you. We begin by assuming that such a machine exists. If such a machine exsited, it would have a full specified state transition/tape operation table. The proof them move on, building another machine based on that presumed table, with precisely specified methods. Then, by the principles of Turing Machines, we can show, based on the few limitations of what Turing Machine has specified, what the results of running that machine will be, even without knowing the details of that machine, just knowing that such a specification exists. And thus, we can show that the given hypothetical H couldn't have meet its specification, because out of the limited number of classes of final behaviors, we can show that it had to be wrong, or just not exist. Of course, since you don't understand about specifications, this may seem like magic to you, but it works. So, if you don't have an infinite set of these 100% specified state transistion/tape operation tables, you can't do YOUR proof. And if you don't have those tables, you can not have any of your embedded_H's "simulate" their inputs, as that is what specifies what the simulation does. So, I guess YOU have a bigger contradiction.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 21:01 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33dt7$dlnv$1@dont-email.me> |
| In reply to | #334644 |
On 5/27/2024 8:24 PM, Richard Damon wrote: > On 5/27/24 9:04 PM, olcott wrote: >>>> I totally do. Can you please write down the >>>> "completely specified state transition/tape operation table." >>>> of this specific (thus uniquely identifiable) machine I would >>>> really like to see it. >>>> >>> >>> But it was proven that no such machine exists! >>> >>> Remember, the proof starts with the hypothetical that such a machine >>> exists. Such a machine WOULD HAVE a completely specified state >>> transition/tape operation table. >>> >> >> That is not what you said. >> >>>>> There doesn't need to be a unique finite string, but it is a 100% >> >>>>> completely specified state transition/tape operation table. >> >> "a 100% completely specified state transition/tape operation table" >> of a non-existent machine. > > Right, by presuming that you have a Turing Machine, you have a completly > specified state transition/tape operation table. > > You may not KNOW what that table is if you don't know what the exact > machine is, but you know it exists. >>> But it was proven that no such machine exists! > ... but you know it exists. >>> But it was proven that no such machine exists! > ... but you know it exists. >>> But it was proven that no such machine exists! > ... but you know it exists. -- Copyright 2024 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 | 2024-05-27 22:23 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33f6d$29dee$4@i2pn2.org> |
| In reply to | #334647 |
On 5/27/24 10:01 PM, olcott wrote: > On 5/27/2024 8:24 PM, Richard Damon wrote: >> On 5/27/24 9:04 PM, olcott wrote: > >>>>> I totally do. Can you please write down the >>>>> "completely specified state transition/tape operation table." >>>>> of this specific (thus uniquely identifiable) machine I would >>>>> really like to see it. >>>>> >>>> >>>> But it was proven that no such machine exists! >>>> >>>> Remember, the proof starts with the hypothetical that such a machine >>>> exists. Such a machine WOULD HAVE a completely specified state >>>> transition/tape operation table. >>>> >>> >>> That is not what you said. >>> >>>>> There doesn't need to be a unique finite string, but it is a 100% >>> >>>>> completely specified state transition/tape operation table. >>> >>> "a 100% completely specified state transition/tape operation table" >>> of a non-existent machine. >> >> Right, by presuming that you have a Turing Machine, you have a >> completly specified state transition/tape operation table. >> >> You may not KNOW what that table is if you don't know what the exact >> machine is, but you know it exists. > > >>> But it was proven that no such machine exists! > > ... but you know it exists. > > >>> But it was proven that no such machine exists! > > ... but you know it exists. > > >>> But it was proven that no such machine exists! > > ... but you know it exists. > > Really, then show that one exists! That is, an actual Turing Machine that halts in state Qy if the Machine/Input that its input describes will halt when run and halt in state Qn if the Machine/Input that its input describes will never halt when run. All you have done is claimed that your "Turing machine equivalent" (that actually isn't) was correct to answer non-halting even thought the program given to it actually halted, but you said it was still right. I think you have gotten something confuesed.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 21:41 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33g9j$e3ug$1@dont-email.me> |
| In reply to | #334648 |
On 5/27/2024 9:23 PM, Richard Damon wrote: > On 5/27/24 10:01 PM, olcott wrote: >> On 5/27/2024 8:24 PM, Richard Damon wrote: >>> On 5/27/24 9:04 PM, olcott wrote: >> >>>>>> I totally do. Can you please write down the >>>>>> "completely specified state transition/tape operation table." >>>>>> of this specific (thus uniquely identifiable) machine I would >>>>>> really like to see it. >>>>>> >>>>> >>>>> But it was proven that no such machine exists! >>>>> >>>>> Remember, the proof starts with the hypothetical that such a >>>>> machine exists. Such a machine WOULD HAVE a completely specified >>>>> state transition/tape operation table. >>>>> >>>> >>>> That is not what you said. >>>> >>>>> There doesn't need to be a unique finite string, but it is a >>>> 100% >>>> >>>>> completely specified state transition/tape operation table. >>>> >>>> "a 100% completely specified state transition/tape operation table" >>>> of a non-existent machine. >>> >>> Right, by presuming that you have a Turing Machine, you have a >>> completly specified state transition/tape operation table. >>> >>> You may not KNOW what that table is if you don't know what the exact >>> machine is, but you know it exists. >> >> >>> But it was proven that no such machine exists! >> > ... but you know it exists. >> >> >>> But it was proven that no such machine exists! >> > ... but you know it exists. >> >> >>> But it was proven that no such machine exists! >> > ... but you know it exists. >> >> > > > Really, then show that one exists! > *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* *I am quoting your words. You did contradict yourself* -- Copyright 2024 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 | 2024-05-27 22:52 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33gss$29def$6@i2pn2.org> |
| In reply to | #334649 |
On 5/27/24 10:41 PM, olcott wrote: > On 5/27/2024 9:23 PM, Richard Damon wrote: >> On 5/27/24 10:01 PM, olcott wrote: >>> On 5/27/2024 8:24 PM, Richard Damon wrote: >>>> On 5/27/24 9:04 PM, olcott wrote: >>> >>>>>>> I totally do. Can you please write down the >>>>>>> "completely specified state transition/tape operation table." >>>>>>> of this specific (thus uniquely identifiable) machine I would >>>>>>> really like to see it. >>>>>>> >>>>>> >>>>>> But it was proven that no such machine exists! >>>>>> >>>>>> Remember, the proof starts with the hypothetical that such a >>>>>> machine exists. Such a machine WOULD HAVE a completely specified >>>>>> state transition/tape operation table. >>>>>> >>>>> >>>>> That is not what you said. >>>>> >>>>> There doesn't need to be a unique finite string, but it is a >>>>> 100% >>>>> >>>>> completely specified state transition/tape operation table. >>>>> >>>>> "a 100% completely specified state transition/tape operation table" >>>>> of a non-existent machine. >>>> >>>> Right, by presuming that you have a Turing Machine, you have a >>>> completly specified state transition/tape operation table. >>>> >>>> You may not KNOW what that table is if you don't know what the exact >>>> machine is, but you know it exists. >>> >>> >>> But it was proven that no such machine exists! >>> > ... but you know it exists. >>> >>> >>> But it was proven that no such machine exists! >>> > ... but you know it exists. >>> >>> >>> But it was proven that no such machine exists! >>> > ... but you know it exists. >>> >>> >> >> >> Really, then show that one exists! >> > > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > *I am quoting your words. You did contradict yourself* > Really, where did I say that H exists? I said that if a Turing Machine exists, then its transition table does too. Show me a Turing Machine, fully defined, and I will show you the state transition table (since that is how we define a Turing Machine) So, are you misquoting again. I note that your quotes there have no actual reference, so apparently pulling things out of context. You seem to like doing this sort of lie. It seems to be part of your nature. It might just be your total ignorance of how language works, but seems more deliberate than that.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 21:59 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33hbf$e6qn$1@dont-email.me> |
| In reply to | #334650 |
On 5/27/2024 9:52 PM, Richard Damon wrote: > On 5/27/24 10:41 PM, olcott wrote: >> On 5/27/2024 9:23 PM, Richard Damon wrote: >>> On 5/27/24 10:01 PM, olcott wrote: >>>> On 5/27/2024 8:24 PM, Richard Damon wrote: >>>>> On 5/27/24 9:04 PM, olcott wrote: >>>> >>>>>>>> I totally do. Can you please write down the >>>>>>>> "completely specified state transition/tape operation table." >>>>>>>> of this specific (thus uniquely identifiable) machine I would >>>>>>>> really like to see it. >>>>>>>> >>>>>>> >>>>>>> But it was proven that no such machine exists! >>>>>>> >>>>>>> Remember, the proof starts with the hypothetical that such a >>>>>>> machine exists. Such a machine WOULD HAVE a completely specified >>>>>>> state transition/tape operation table. >>>>>>> >>>>>> >>>>>> That is not what you said. >>>>>> >>>>> There doesn't need to be a unique finite string, but it is >>>>>> a 100% >>>>>> >>>>> completely specified state transition/tape operation table. >>>>>> >>>>>> "a 100% completely specified state transition/tape operation table" >>>>>> of a non-existent machine. >>>>> >>>>> Right, by presuming that you have a Turing Machine, you have a >>>>> completly specified state transition/tape operation table. >>>>> >>>>> You may not KNOW what that table is if you don't know what the >>>>> exact machine is, but you know it exists. >>>> >>>> >>> But it was proven that no such machine exists! >>>> > ... but you know it exists. >>>> >>>> >>> But it was proven that no such machine exists! >>>> > ... but you know it exists. >>>> >>>> >>> But it was proven that no such machine exists! >>>> > ... but you know it exists. >>>> >>>> >>> >>> >>> Really, then show that one exists! >>> >> >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> *I am quoting your words. You did contradict yourself* >> > > > Really, where did I say that H exists? > > I said that if a Turing Machine exists, then its transition table does too. > OK my mistake this time. I did not take into account the full context. I will go back an read the Linz proof and see if he said anything about a specific machine. None of the proofs ever try to show that there exists one machine that gets the wrong answer. They are always at least trying to prove that no machine of the infinite set of machine gets the right answer. -- Copyright 2024 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 | 2024-05-28 07:34 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v34fg0$2bb65$2@i2pn2.org> |
| In reply to | #334651 |
On 5/27/24 10:59 PM, olcott wrote: > On 5/27/2024 9:52 PM, Richard Damon wrote: >> On 5/27/24 10:41 PM, olcott wrote: >>> On 5/27/2024 9:23 PM, Richard Damon wrote: >>>> On 5/27/24 10:01 PM, olcott wrote: >>>>> On 5/27/2024 8:24 PM, Richard Damon wrote: >>>>>> On 5/27/24 9:04 PM, olcott wrote: >>>>> >>>>>>>>> I totally do. Can you please write down the >>>>>>>>> "completely specified state transition/tape operation table." >>>>>>>>> of this specific (thus uniquely identifiable) machine I would >>>>>>>>> really like to see it. >>>>>>>>> >>>>>>>> >>>>>>>> But it was proven that no such machine exists! >>>>>>>> >>>>>>>> Remember, the proof starts with the hypothetical that such a >>>>>>>> machine exists. Such a machine WOULD HAVE a completely specified >>>>>>>> state transition/tape operation table. >>>>>>>> >>>>>>> >>>>>>> That is not what you said. >>>>>>> >>>>> There doesn't need to be a unique finite string, but it is >>>>>>> a 100% >>>>>>> >>>>> completely specified state transition/tape operation table. >>>>>>> >>>>>>> "a 100% completely specified state transition/tape operation table" >>>>>>> of a non-existent machine. >>>>>> >>>>>> Right, by presuming that you have a Turing Machine, you have a >>>>>> completly specified state transition/tape operation table. >>>>>> >>>>>> You may not KNOW what that table is if you don't know what the >>>>>> exact machine is, but you know it exists. >>>>> >>>>> >>> But it was proven that no such machine exists! >>>>> > ... but you know it exists. >>>>> >>>>> >>> But it was proven that no such machine exists! >>>>> > ... but you know it exists. >>>>> >>>>> >>> But it was proven that no such machine exists! >>>>> > ... but you know it exists. >>>>> >>>>> >>>> >>>> >>>> Really, then show that one exists! >>>> >>> >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> *I am quoting your words. You did contradict yourself* >>> >> >> >> Really, where did I say that H exists? >> >> I said that if a Turing Machine exists, then its transition table does >> too. >> > > OK my mistake this time. I did not take into account the full context. > I will go back an read the Linz proof and see if he said anything > about a specific machine. Read the DEFINITION of the problem. He talks about "a" machine. Using a singular article means you are working with just one. Taking stuff out of context is a common problem with you, when you don't understand something, you just make up what it must mean, and stick to that. That isn't the way to learn. > > None of the proofs ever try to show that there exists one machine that > gets the wrong answer. They are always at least trying to prove that no > machine of the infinite set of machine gets the right answer. > What I see, is they always start with a prototypical single machine, and show that it gets the answer wrong, and then they use categorical logic to say that we can do this same thing for all of them.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-28 10:20 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v34snt$l6mn$3@dont-email.me> |
| In reply to | #334657 |
On 5/28/2024 6:34 AM, Richard Damon wrote: > On 5/27/24 10:59 PM, olcott wrote: >> On 5/27/2024 9:52 PM, Richard Damon wrote: >>> On 5/27/24 10:41 PM, olcott wrote: >>>> On 5/27/2024 9:23 PM, Richard Damon wrote: >>>>> On 5/27/24 10:01 PM, olcott wrote: >>>>>> On 5/27/2024 8:24 PM, Richard Damon wrote: >>>>>>> On 5/27/24 9:04 PM, olcott wrote: >>>>>> >>>>>>>>>> I totally do. Can you please write down the >>>>>>>>>> "completely specified state transition/tape operation table." >>>>>>>>>> of this specific (thus uniquely identifiable) machine I would >>>>>>>>>> really like to see it. >>>>>>>>>> >>>>>>>>> >>>>>>>>> But it was proven that no such machine exists! >>>>>>>>> >>>>>>>>> Remember, the proof starts with the hypothetical that such a >>>>>>>>> machine exists. Such a machine WOULD HAVE a completely >>>>>>>>> specified state transition/tape operation table. >>>>>>>>> >>>>>>>> >>>>>>>> That is not what you said. >>>>>>>> >>>>> There doesn't need to be a unique finite string, but it >>>>>>>> is a 100% >>>>>>>> >>>>> completely specified state transition/tape operation table. >>>>>>>> >>>>>>>> "a 100% completely specified state transition/tape operation table" >>>>>>>> of a non-existent machine. >>>>>>> >>>>>>> Right, by presuming that you have a Turing Machine, you have a >>>>>>> completly specified state transition/tape operation table. >>>>>>> >>>>>>> You may not KNOW what that table is if you don't know what the >>>>>>> exact machine is, but you know it exists. >>>>>> >>>>>> >>> But it was proven that no such machine exists! >>>>>> > ... but you know it exists. >>>>>> >>>>>> >>> But it was proven that no such machine exists! >>>>>> > ... but you know it exists. >>>>>> >>>>>> >>> But it was proven that no such machine exists! >>>>>> > ... but you know it exists. >>>>>> >>>>>> >>>>> >>>>> >>>>> Really, then show that one exists! >>>>> >>>> >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> *I am quoting your words. You did contradict yourself* >>>> >>> >>> >>> Really, where did I say that H exists? >>> >>> I said that if a Turing Machine exists, then its transition table >>> does too. >>> >> >> OK my mistake this time. I did not take into account the full context. >> I will go back an read the Linz proof and see if he said anything >> about a specific machine. > I did not take into account the full context of your words, this was entirely my mistake. I was very happy to find that the other view that you provided about a specific machine were actually supported by words that Peter Linz used. My other reply will analyze the meaning of those Peter Linz words. > Read the DEFINITION of the problem. He talks about "a" machine. Using a > singular article means you are working with just one. > > > Taking stuff out of context is a common problem with you, when you don't > understand something, you just make up what it must mean, and stick to > that. That isn't the way to learn. > > >> >> None of the proofs ever try to show that there exists one machine that >> gets the wrong answer. They are always at least trying to prove that no >> machine of the infinite set of machine gets the right answer. >> > > What I see, is they always start with a prototypical single machine, and > show that it gets the answer wrong, and then they use categorical logic > to say that we can do this same thing for all of them. -- Copyright 2024 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 | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 09:37 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3fbme$2qsgd$1@dont-email.me> |
| In reply to | #334657 |
On 6/1/2024 2:52 AM, Mikko wrote: > On 2024-05-31 15:35:18 +0000, olcott said: >> >> When Ĥ is applied to ⟨Ĥ⟩ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > Of those two lines one is false. > As embedded_H is a copy of H both lines imply that H is not a halt decider. > >> *Formalizing the Linz Proof structure* >> ∃H ∈ Turing_Machines >> ∀x ∈ Turing_Machine_Descriptions >> ∀y ∈ Finite_Strings >> such that H(x,y) = Halts(x,y) > > As already noted, the above is not a part of a proof structure. > Unless and until you provide reasoning to back that up it counts as if you said nothing about it. >> That <is> what Linz is claiming is false. >> *Here is the same claim with 100% complete specificity* >> such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, ⟨Ĥ⟩) > > That does not make sense. Every H such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, ⟨Ĥ⟩) > is uninteresting. > *Unless it is proven that there is a fatal flaw in the proof* >> *A quick summary of the reasoning provided below* >> The LHS is behavior that embedded_H is allowed to report on. > > There is no restrictions on what embedded_H is allowed to report on. embedded_H is only allowed to report on the behavior that its finite string Turing Machine Description specifies to a UTM. embedded_H <is> a UTM except that it stops simulating and reports non-halting as soon as it correctly recognizes a non-halting behavior pattern that is specified by its input. When Ĥ is applied to ⟨Ĥ⟩ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn (a) Ĥ copies its input ⟨Ĥ⟩ (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ (g) goto (d) embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can only be finite strings and Ĥ is not a finite string. This means that embedded_H is not allowed to report on its own actual behavior. embedded_H only allowed to report on the behavior specified by its finite string input. That behavior never stops running for 1 to ∞ steps of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H. > The only reauirement is that embedded_H has the same transition > rules as H. Therefore embedded_H reports the same as H, whether > allowed or not. > Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. This is because the in the latter case embedded_H must determine that ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop running after 1 to ∞ steps of correct simulation. Thus embedded_H meets its abort simulation criteria. The former case of Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ can see that embedded_H has already aborted its simulation, thus it never reaches its own abort criteria. It is only because everyone since 1936 has rejected simulation OUT-OF-HAND without review that no one ever noticed this before. >> The RHS is behavior that embedded_H NOT is allowed to report on. >> The LHS and the RHS specify different behaviors. > > You have not shown anything with behaviours as LHS and RHS. > >> Please to not reply here instead reply at the end of my proof >> after all of the steps have been presented. > > Not a reasonable request. Correctness of a step of proof does not > depend on what follows. If one step is erroneous the rest is > irrelevant. > -- Copyright 2024 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 | 2024-06-01 11:20 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3fe8g$2n53o$2@i2pn2.org> |
| In reply to | #334809 |
On 6/1/24 10:37 AM, olcott wrote: > On 6/1/2024 2:52 AM, Mikko wrote: >> On 2024-05-31 15:35:18 +0000, olcott said: > >>> >>> When Ĥ is applied to ⟨Ĥ⟩ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> >> Of those two lines one is false. >> As embedded_H is a copy of H both lines imply that H is not a halt >> decider. >> >>> *Formalizing the Linz Proof structure* >>> ∃H ∈ Turing_Machines >>> ∀x ∈ Turing_Machine_Descriptions >>> ∀y ∈ Finite_Strings >>> such that H(x,y) = Halts(x,y) >> >> As already noted, the above is not a part of a proof structure. >> > > Unless and until you provide reasoning to back that up it counts > as if you said nothing about it. YOU ARE THE ONE Claiming it is. I guess you don't understand about Russel's teapot. > >>> That <is> what Linz is claiming is false. >>> *Here is the same claim with 100% complete specificity* >>> such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, ⟨Ĥ⟩) >> >> That does not make sense. Every H such that H(⟨Ĥ⟩, ⟨Ĥ⟩) != Halts(⟨Ĥ⟩, >> ⟨Ĥ⟩) >> is uninteresting. >> > > *Unless it is proven that there is a fatal flaw in the proof* But your proof has been shown to have the fatal flaw. You are just proving you don't understand enough of what you are talking about to understand the problem > >>> *A quick summary of the reasoning provided below* >>> The LHS is behavior that embedded_H is allowed to report on. >> >> There is no restrictions on what embedded_H is allowed to report on. > > embedded_H is only allowed to report on the behavior that its finite > string Turing Machine Description specifies to a UTM.trace H^ (H^) to Qn and it will halt, thus eyour embedded_H will halt. And that is the problem it can't. Remember, if embedded_H (H^) (H^) goes to Qn, then it can be shown that UTH (H^) (H^) will > > embedded_H <is> a UTM except that it stops simulating and reports > non-halting as soon as it correctly recognizes a non-halting behavior > pattern that is specified by its input. Which means it isn't a UTM. You seem to think that if you take an electric car are replace the electric motor with an internal combustion engine, that you still have an electric car. > > When Ĥ is applied to ⟨Ĥ⟩ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > (a) Ĥ copies its input ⟨Ĥ⟩ > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ > (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ > (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ > (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ > (g) goto (d) If that IS what happens, then neither H nor embeeded_H will ever answer and thus are not deciders. You must look at the ACTUAL behavior of the machine, not the behavior of some other machine where "embedded_H" isn't the machine it is. > > embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can > only be finite strings and Ĥ is not a finite string. This means > that embedded_H is not allowed to report on its own actual behavior. But (H^) (H^) represent the machine H^ (H^), and as you said earlier, H / embedded_H are supposed to answer about their input give to a UTM, and that definiton says that UTM (H^) (H^) will have, BY DEFINITION, the exact same final behavior as H^ (H^), so while H / embedded_H was given the input (H^) (H^) the behavior it needs to decide on it the behavior of H^ (H^) as expressed by UTM (H^) (H^) which is by definition the same. > > embedded_H only allowed to report on the behavior specified by its > finite string input. That behavior never stops running for 1 to ∞ steps > of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H. Nope. Remember, embedded_H is a SPECIFIC machine that this point, so it wlll always simulate this given input (also based on this specific embedded_H) for a fixed number of steps before it aborts. > >> The only reauirement is that embedded_H has the same transition >> rules as H. Therefore embedded_H reports the same as H, whether >> allowed or not. >> > > Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than > embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. Nope, Can you show that? He uses the fact that if we assume that all copies of H do the correct thing, we get a contradiction. You don't seem to understand how proof by contradiction works, maybe because your world seems to be based on the assumption that contradictions are not a problem, which is why your logic systems just fail. > > This is because the in the latter case embedded_H must determine that > ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop running > after 1 to ∞ steps of correct simulation. Thus embedded_H meets its > abort simulation criteria. > Where does he say that? > The former case of Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ can see that embedded_H > has already aborted its simulation, thus it never reaches its own > abort criteria. > > It is only because everyone since 1936 has rejected simulation > OUT-OF-HAND without review that no one ever noticed this before. Nope, you just don't unerstand what people have been talking about since you have decided to talk about things you haven't actually studied. > >>> The RHS is behavior that embedded_H NOT is allowed to report on. >>> The LHS and the RHS specify different behaviors. >> >> You have not shown anything with behaviours as LHS and RHS. >> >>> Please to not reply here instead reply at the end of my proof >>> after all of the steps have been presented. >> >> Not a reasonable request. Correctness of a step of proof does not >> depend on what follows. If one step is erroneous the rest is >> irrelevant. >> >
[toc] | [prev] | [next] | [standalone]
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-01 18:52 +0000 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3fqkp$2o13h$7@i2pn2.org> |
| In reply to | #334809 |
Am Sat, 01 Jun 2024 09:37:01 -0500 schrieb olcott: > On 6/1/2024 2:52 AM, Mikko wrote: >> On 2024-05-31 15:35:18 +0000, olcott said: >>> *A quick summary of the reasoning provided below* >>> The LHS is behavior that embedded_H is allowed to report on. >> There is no restrictions on what embedded_H is allowed to report on. > > embedded_H is only allowed to report on the behavior that its finite > string Turing Machine Description specifies to a UTM. > > embedded_H <is> a UTM except that it stops simulating and reports > non-halting as soon as it correctly recognizes a non-halting behavior > pattern that is specified by its input. "Except". So it is not an UTM. > When Ĥ is applied to ⟨Ĥ⟩ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ > Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn > > (a) Ĥ copies its input ⟨Ĥ⟩ > (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ > (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ > (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ > (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ > (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ > (g) goto (d) > > embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can > only be finite strings and Ĥ is not a finite string. This means > that embedded_H is not allowed to report on its own actual behavior. I can't read that notation. What is H^ and what does it look like? > embedded_H only allowed to report on the behavior specified by its > finite string input. That behavior never stops running for 1 to ∞ steps > of ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H. > >> The only reauirement is that embedded_H has the same transition >> rules as H. Therefore embedded_H reports the same as H, whether >> allowed or not. >> > Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ derives a different result than > embedded_H applied to ⟨Ĥ⟩ ⟨Ĥ⟩. > > This is because the in the latter case embedded_H must determine that > ⟨Ĥ⟩ ⟨Ĥ⟩ correctly simulated by embedded_H cannot possibly stop running > after 1 to ∞ steps of correct simulation. Thus embedded_H meets its > abort simulation criteria. > > The former case of Linz H applied to ⟨Ĥ⟩ ⟨Ĥ⟩ can see that embedded_H > has already aborted its simulation, thus it never reaches its own > abort criteria. > > It is only because everyone since 1936 has rejected simulation > OUT-OF-HAND without review that no one ever noticed this before. > >>> The RHS is behavior that embedded_H NOT is allowed to report on. >>> The LHS and the RHS specify different behaviors. >> >> You have not shown anything with behaviours as LHS and RHS. >> >>> Please to not reply here instead reply at the end of my proof >>> after all of the steps have been presented. >> >> Not a reasonable request. Correctness of a step of proof does not >> depend on what follows. If one step is erroneous the rest is >> irrelevant. ^ -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-01 14:26 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3fsm0$2uah1$1@dont-email.me> |
| In reply to | #334856 |
On 6/1/2024 1:52 PM, joes wrote: > Am Sat, 01 Jun 2024 09:37:01 -0500 schrieb olcott: >> On 6/1/2024 2:52 AM, Mikko wrote: >>> On 2024-05-31 15:35:18 +0000, olcott said: > >>>> *A quick summary of the reasoning provided below* >>>> The LHS is behavior that embedded_H is allowed to report on. >>> There is no restrictions on what embedded_H is allowed to report on. >> >> embedded_H is only allowed to report on the behavior that its finite >> string Turing Machine Description specifies to a UTM. >> >> embedded_H <is> a UTM except that it stops simulating and reports >> non-halting as soon as it correctly recognizes a non-halting behavior >> pattern that is specified by its input. > "Except". So it is not an UTM. > >> When Ĥ is applied to ⟨Ĥ⟩ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >> >> (a) Ĥ copies its input ⟨Ĥ⟩ >> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ >> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >> (g) goto (d) >> >> embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can >> only be finite strings and Ĥ is not a finite string. This means >> that embedded_H is not allowed to report on its own actual behavior. > I can't read that notation. What is H^ and what does it look like? > *Here is the whole Linz proof* I simplified the Linz notation at the bottom of page 2 of the proof. https://www.liarparadox.org/Linz_Proof.pdf -- Copyright 2024 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 | 2024-06-01 15:45 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3ftpn$2n53n$13@i2pn2.org> |
| In reply to | #334867 |
On 6/1/24 3:26 PM, olcott wrote: > On 6/1/2024 1:52 PM, joes wrote: >> Am Sat, 01 Jun 2024 09:37:01 -0500 schrieb olcott: >>> On 6/1/2024 2:52 AM, Mikko wrote: >>>> On 2024-05-31 15:35:18 +0000, olcott said: >> >>>>> *A quick summary of the reasoning provided below* >>>>> The LHS is behavior that embedded_H is allowed to report on. >>>> There is no restrictions on what embedded_H is allowed to report on. >>> >>> embedded_H is only allowed to report on the behavior that its finite >>> string Turing Machine Description specifies to a UTM. >>> >>> embedded_H <is> a UTM except that it stops simulating and reports >>> non-halting as soon as it correctly recognizes a non-halting behavior >>> pattern that is specified by its input. >> "Except". So it is not an UTM. >> >>> When Ĥ is applied to ⟨Ĥ⟩ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞ >>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn >>> >>> (a) Ĥ copies its input ⟨Ĥ⟩ >>> (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>> (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>> (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩ >>> (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ >>> (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩ >>> (g) goto (d) >>> >>> embedded_H is not allowed to be applied to Ĥ ⟨Ĥ⟩ because inputs can >>> only be finite strings and Ĥ is not a finite string. This means >>> that embedded_H is not allowed to report on its own actual behavior. >> I can't read that notation. What is H^ and what does it look like? >> > > *Here is the whole Linz proof* > I simplified the Linz notation at the bottom of page 2 of the proof. > https://www.liarparadox.org/Linz_Proof.pdf > > Yes, you "simplified" it by removing essential parts of the requirements listed. Probably because you don't understand what they mean, because requirements don't seem to mean anything to you.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-27 22:24 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v33iqc$ebbg$1@dont-email.me> |
| In reply to | #334640 |
On 5/27/2024 7:17 PM, Richard Damon wrote:
> On 5/27/24 8:08 PM, olcott wrote:
>> On 5/27/2024 5:44 PM, Richard Damon wrote:
>>> On 5/27/24 6:32 PM, olcott wrote:
>>>> On 5/27/2024 4:21 PM, Richard Damon wrote:
>>>>> On 5/27/24 3:45 PM, olcott wrote:
>>>>>> On 5/27/2024 11:33 AM, Richard Damon wrote:
>>>>>>> On 5/27/24 12:22 PM, olcott wrote:
>>>>>>>> On 5/27/2024 10:58 AM, Richard Damon wrote:
>>>>>>>>> On 5/27/24 11:46 AM, olcott wrote:
>>>>>>>>>> On 5/27/2024 10:25 AM, Richard Damon wrote:
>>>>>>>>>>> On 5/27/24 11:06 AM, olcott wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function in C
>>>>>>>>>> 00 int H(ptr p, ptr i);
>>>>>>>>>> 01 int D(ptr p)
>>>>>>>>>> 02 {
>>>>>>>>>> 03 int Halt_Status = H(p, p);
>>>>>>>>>> 04 if (Halt_Status)
>>>>>>>>>> 05 HERE: goto HERE;
>>>>>>>>>> 06 return Halt_Status;
>>>>>>>>>> 07 }
>>>>>>>>>> 08
>>>>>>>>>> 09 int main()
>>>>>>>>>> 10 {
>>>>>>>>>> 11 H(D,D);
>>>>>>>>>> 12 return 0;
>>>>>>>>>> 13 }
>>>>>>>>>>
>>>>>>>>>> The above template refers to an infinite set of H/D pairs
>>>>>>>>>> where D is
>>>>>>>>>> correctly simulated by either pure simulator H or pure
>>>>>>>>>> function H. This
>>>>>>>>>> was done because many reviewers used the shell game ploy to
>>>>>>>>>> endlessly
>>>>>>>>>> switch which H/D pair was being referred to.
>>>>>>>>>>
>>>>>>>>>> *Correct Simulation Defined*
>>>>>>>>>> This is provided because many reviewers had a different
>>>>>>>>>> notion of
>>>>>>>>>> correct simulation that diverges from this notion.
>>>>>>>>>>
>>>>>>>>>> A simulator is an x86 emulator that correctly emulates 1
>>>>>>>>>> to N of the
>>>>>>>>>> x86 instructions of D in the order specified by the x86
>>>>>>>>>> instructions
>>>>>>>>>> of D. This may include M recursive emulations of H
>>>>>>>>>> emulating itself
>>>>>>>>>> emulating D.
>>>>>>>>>
>>>>>>>>> And how do you apply that to a TEMPLATE that doesn't define
>>>>>>>>> what a call H means (as it could be any of the infinite set of
>>>>>>>>> Hs that you can instantiate the template on)?
>>>>>>>>>
>>>>>>>>
>>>>>>>> *Somehow we got off track of the subject of this thread*
>>>>>>>
>>>>>>> I note that YOU keep on switching between your C program and
>>>>>>> Turing Machines.
>>>>>>>
>>>>>>> Note, per the implications that you implicitly agreed to (by not
>>>>>>> even trying to refute) the two systems are NOT equivalents of
>>>>>>> each other.
>>>>>>>
>>>>>>
>>>>>> (1) I think you are wrong. I have not seen any of your
>>>>>> reasoning that was not anchored in false assumptions.
>>>>>> Your make fake rebuttal is to change the subject.
>>>>>>
>>>>>> (2) It does not matter my proof is anchored in the Linz
>>>>>> proof and the H/D pairs are only used to have a 100% concrete
>>>>>> basis to perfectly anchor things such as the correct meaning
>>>>>> of D correctly simulated by H so that people cannot get away
>>>>>> with claiming that an incorrect simulation is correct.
>>>>>>
>>>>>> int main() { D(D); } IS NOT THE BEHAVIOR OF D CORRECTLY SIMULATED
>>>>>> BY H.
>>>>>> One cannot simply ignore the pathological relationship between H
>>>>>> and D.
>>>>>>
>>>>>>>>
>>>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>>>
>>>>>>>> Ĥ copies its own Turing machine description: ⟨Ĥ⟩
>>>>>>>> then invokes embedded_H that simulates ⟨Ĥ⟩ with ⟨Ĥ⟩ as input.
>>>>>>>>
>>>>>>>> For the purposes of the above analysis we hypothesize that
>>>>>>>> embedded_H is either a UTM or a UTM that has been adapted
>>>>>>>> to stop simulating after a finite number of steps of simulation.
>>>>>>>
>>>>>>> And what you do mean by that?
>>>>>>>
>>>>>>> Do you hypothesize that the original H was just a pure UTM,
>>>>>>
>>>>>> The original proof does not consider the notion of a simulating
>>>>>> halt decider so I have to begin the proof at an earlier stage
>>>>>> than any definition of H.
>>>>>
>>>>> The biggest problem is that the input to the Turing machine decider
>>>>> H is the description of a Turing Machine H^, which is a SPECIFIC
>>>>> machine,
>>>>
>>>> When you say "specific machine" you don't mean anything like a
>>>> 100% completely specified sequence of state transitions encoded
>>>> as a single unique finite string.
>>>
>>> Mostly.
>>>
>>> There doesn't need to be a unique finite string, but it is a 100%
>>> completely specified state transition/tape operation table.
>>>
>>
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> In other words Linz did not prove that there are no set
>> of state transitions specified by ⊢* that derives the
>> correct halt status of ⟨Ĥ⟩ ⟨Ĥ⟩.
>>
>> He only said there there is one specific machine that
>> gets the wrong answer.
>>
>
> He STARTS with a proof that one specific (but arbitrary) machine gets
> the wrong answer.
>
*Not exactly, you are misreading this*
The domain of this problem is to be taken as the set of all Turing
machines and all w; that is, we are looking for a single Turing machine
that, given the description of an arbitrary M and w, will predict
whether or not the computation of M applied to w will halt.
...
Proof: We assume the contrary, namely that there exists an algorithm,
and consequently some Turing machine H, that solves the halting problem
https://www.liarparadox.org/Peter_Linz_HP_317-320.pdf
Ordinary existential quantification looks for at least one
element not exactly one element:
Does at least one Turing machine exist of the infinite set
of all Turing machines ...
So like I have always said, the second ⊢* specifies
an infinite set of Turing machines.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Then he shows that the same proof can be applied to ANY such machine
> (becaue the proof didn't depend on any specific details of the machine,
> just the general properties of that machine)
>
> I guess you don't understand how to do categorical proofs.
>
--
Copyright 2024 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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | sci.logic
csiph-web