Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.theory > #105431 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-05-23 12:04 -0500 |
| Last post | 2024-05-24 18:17 -0400 |
| Articles | 20 on this page of 186 — 8 participants |
Back to article view | Back to comp.theory
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 ⟨Ĥ⟩ Mikko <mikko.levanto@iki.fi> - 2024-05-29 11:37 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-29 08:13 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-29 19:47 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Mikko <mikko.levanto@iki.fi> - 2024-05-30 10:06 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-30 08:20 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Richard Damon <richard@damon-family.org> - 2024-05-30 21:37 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Mikko <mikko.levanto@iki.fi> - 2024-05-31 16:00 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ olcott <polcott333@gmail.com> - 2024-05-31 10:35 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ immibis <news@immibis.com> - 2024-05-31 19:51 +0200
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ Mikko <mikko.levanto@iki.fi> - 2024-06-01 10:52 +0300
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 ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-02 10:42 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-02 08:21 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details immibis <news@immibis.com> - 2024-06-02 15:29 +0200
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-03 11:01 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-03 07:36 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-03 18:16 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details wij <wyniijj5@gmail.com> - 2024-06-03 23:27 +0800
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-03 13:28 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-06-03 21:58 +0200
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-03 14:00 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details joes <noreply@example.com> - 2024-06-03 20:01 +0000
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-03 16:17 -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-03 20:56 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-02 10:36 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-02 08:07 -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-02 13:23 -0400
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-03 11:07 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details olcott <polcott333@gmail.com> - 2024-06-03 07:48 -0500
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Mikko <mikko.levanto@iki.fi> - 2024-06-03 18:19 +0300
Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details Richard Damon <richard@damon-family.org> - 2024-06-03 20:56 -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: D correctly simulated by pure function H cannot possibly reach its, own line 06 olcott <polcott333@gmail.com> - 2024-05-25 16:27 -0500
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
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? Mikko <mikko.levanto@iki.fi> - 2024-05-24 12:03 +0300
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 12:16 -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:31 -0400
Re: Can you see that D correctly simulated by H remains stuck in recursive simulation? olcott <polcott333@gmail.com> - 2024-05-24 15:07 -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:41 -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
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | joes <noreply@example.com> |
|---|---|
| Date | 2024-06-03 20:01 +0000 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3l7e5$2uji4$1@i2pn2.org> |
| In reply to | #106165 |
Am Mon, 03 Jun 2024 14:00:04 -0500 schrieb olcott: > On 6/3/2024 10:16 AM, Mikko wrote: >> On 2024-06-03 12:36:00 +0000, olcott said: >>> On 6/3/2024 3:01 AM, Mikko wrote: >>>> On 2024-06-02 13:21:56 +0000, olcott said: >>>>> On 6/2/2024 2:42 AM, Mikko wrote: >>>>>> On 2024-06-01 19:26:55 +0000, olcott said: >>>>>>> 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: > I am so sure that I must be right that I do not notice any actual mistakes. FTFY. > The only "mistake" that anyone ever pointed out is essentially "that's > not the way that I memorized it". No, your mistake is the contradictory requirements for H: > When the behavior of DD correctly simulated by HH is not the same as the > behavior of the directly executed DD(DD) > they assume the simulation must be wrong even though it it an easily > verified fact that it is correct. That's not an assumption. That's the definition of simulation: doing exactly the same thing as the direct execution, which may be infinite recursion. But then H is not a decider. -- joes
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 16:17 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3lbt7$228t$1@dont-email.me> |
| In reply to | #106175 |
On 6/3/2024 3:01 PM, joes wrote: > Am Mon, 03 Jun 2024 14:00:04 -0500 schrieb olcott: >> On 6/3/2024 10:16 AM, Mikko wrote: >>> On 2024-06-03 12:36:00 +0000, olcott said: >>>> On 6/3/2024 3:01 AM, Mikko wrote: >>>>> On 2024-06-02 13:21:56 +0000, olcott said: >>>>>> On 6/2/2024 2:42 AM, Mikko wrote: >>>>>>> On 2024-06-01 19:26:55 +0000, olcott said: >>>>>>>> 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: > >> I am so sure that I must be right that I do not notice any actual > mistakes. > FTFY. > >> The only "mistake" that anyone ever pointed out is essentially "that's >> not the way that I memorized it". > No, your mistake is the contradictory requirements for H: > The way that the halting problem is conventionally understood is that H must correctly answer yes or no to an input that contradicts both answers. That is the exact same incorrect question as this: Is this sentence: "this sentence is not true" true or false? >> When the behavior of DD correctly simulated by HH is not the same as the >> behavior of the directly executed DD(DD) >> they assume the simulation must be wrong even though it it an easily >> verified fact that it is correct. > That's not an assumption. That's the definition of simulation: doing > exactly the same thing as the direct execution, which may be infinite > recursion. But then H is not a decider. > -- 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-03 20:56 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3lon7$2uv04$3@i2pn2.org> |
| In reply to | #106180 |
On 6/3/24 5:17 PM, olcott wrote: > On 6/3/2024 3:01 PM, joes wrote: >> Am Mon, 03 Jun 2024 14:00:04 -0500 schrieb olcott: >>> On 6/3/2024 10:16 AM, Mikko wrote: >>>> On 2024-06-03 12:36:00 +0000, olcott said: >>>>> On 6/3/2024 3:01 AM, Mikko wrote: >>>>>> On 2024-06-02 13:21:56 +0000, olcott said: >>>>>>> On 6/2/2024 2:42 AM, Mikko wrote: >>>>>>>> On 2024-06-01 19:26:55 +0000, olcott said: >>>>>>>>> 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: >> >>> I am so sure that I must be right that I do not notice any actual >> mistakes. >> FTFY. >> >>> The only "mistake" that anyone ever pointed out is essentially "that's >>> not the way that I memorized it". >> No, your mistake is the contradictory requirements for H: >> > > The way that the halting problem is conventionally understood is > that H must correctly answer yes or no to an input that contradicts > both answers. > > That is the exact same incorrect question as this: > Is this sentence: "this sentence is not true" true or false? Nope. The difference is that the decider is created first, and then the question is constructed with a correct answer, that just isn't the one that that decider gives. That you don't understand this diffference just shows how little you understand about programs. > >>> When the behavior of DD correctly simulated by HH is not the same as the >>> behavior of the directly executed DD(DD) >>> they assume the simulation must be wrong even though it it an easily >>> verified fact that it is correct. >> That's not an assumption. That's the definition of simulation: doing >> exactly the same thing as the direct execution, which may be infinite >> recursion. But then H is not a decider. >> >
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-02 10:36 +0300 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3h7dn$38sid$1@dont-email.me> |
| In reply to | #105872 |
On 2024-06-01 14:37:01 +0000, olcott said: > 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. If there are no more questions about the details of the reasoning we may assume that the presiented reasoning is sufficieant. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-02 08:07 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3hqqd$3bkv5$2@dont-email.me> |
| In reply to | #105983 |
On 6/2/2024 2:36 AM, Mikko wrote: > On 2024-06-01 14:37:01 +0000, olcott said: > >> 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. > > If there are no more questions about the details of the reasoning > we may assume that the presiented reasoning is sufficieant. > The above <is> the structure of his proof your empty assertion utterly bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. Linz claims that of every Turing Machine there are none that solve the halting problem. ∃!H ∈ Turing_Machines (What Richard was saying) would say that there does not exist exactly one Turing Machine that solves the halting problem thus fails if there are more than one. -- 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-02 13:23 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3i9q3$2qu72$8@i2pn2.org> |
| In reply to | #106005 |
On 6/2/24 9:07 AM, olcott wrote: > On 6/2/2024 2:36 AM, Mikko wrote: >> On 2024-06-01 14:37:01 +0000, olcott said: >> >>> 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. >> >> If there are no more questions about the details of the reasoning >> we may assume that the presiented reasoning is sufficieant. >> > > The above <is> the structure of his proof your empty assertion utterly > bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. > > Linz claims that of every Turing Machine there are none that solve the > halting problem. > > ∃!H ∈ Turing_Machines (What Richard was saying) > would say that there does not exist exactly one Turing Machine that > solves the halting problem thus fails if there are more than one. > I never said that, which prove you to be a LILAR. That yo might think I said that just shows that you are an IDIOT.
[toc] | [prev] | [next] | [standalone]
| From | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-03 11:07 +0300 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3jtj4$3qgmo$1@dont-email.me> |
| In reply to | #106005 |
On 2024-06-02 13:07:25 +0000, olcott said: > On 6/2/2024 2:36 AM, Mikko wrote: >> On 2024-06-01 14:37:01 +0000, olcott said: >> >>> 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. >> >> If there are no more questions about the details of the reasoning >> we may assume that the presiented reasoning is sufficieant. >> > > The above <is> the structure of his proof your empty assertion utterly > bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. Those how know what "structure" means can see that it is not a structure. > Linz claims that of every Turing Machine there are none that solve the > halting problem. And proves the claim. > ∃!H ∈ Turing_Machines (What Richard was saying) > would say that there does not exist exactly one Turing Machine that > solves the halting problem thus fails if there are more than one. Irrelevant as that is not what Linz' says. And you should not lie about Rchard. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-06-03 07:48 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3ke2r$3t5s5$1@dont-email.me> |
| In reply to | #106110 |
On 6/3/2024 3:07 AM, Mikko wrote: > On 2024-06-02 13:07:25 +0000, olcott said: > >> On 6/2/2024 2:36 AM, Mikko wrote: >>> On 2024-06-01 14:37:01 +0000, olcott said: >>> >>>> 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. >>> >>> If there are no more questions about the details of the reasoning >>> we may assume that the presiented reasoning is sufficieant. >>> >> >> The above <is> the structure of his proof your empty assertion utterly >> bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. > > Those how know what "structure" means can see that it is not a structure. > >> Linz claims that of every Turing Machine there are none that solve the >> halting problem. > > And proves the claim. > >> ∃!H ∈ Turing_Machines (What Richard was saying) >> would say that there does not exist exactly one Turing Machine that >> solves the halting problem thus fails if there are more than one. > > Irrelevant as that is not what Linz' says. > And you should not lie about Rchard. > Richard was confused bout this. Linz words were confusing unless one had read many other proofs one might be confused. -- 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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-06-03 18:19 +0300 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3kmun$3unpj$1@dont-email.me> |
| In reply to | #106130 |
On 2024-06-03 12:48:26 +0000, olcott said: > On 6/3/2024 3:07 AM, Mikko wrote: >> On 2024-06-02 13:07:25 +0000, olcott said: >> >>> On 6/2/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-01 14:37:01 +0000, olcott said: >>>> >>>>> 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. >>>> >>>> If there are no more questions about the details of the reasoning >>>> we may assume that the presiented reasoning is sufficieant. >>>> >>> >>> The above <is> the structure of his proof your empty assertion utterly >>> bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. >> >> Those how know what "structure" means can see that it is not a structure. >> >>> Linz claims that of every Turing Machine there are none that solve the >>> halting problem. >> >> And proves the claim. >> >>> ∃!H ∈ Turing_Machines (What Richard was saying) >>> would say that there does not exist exactly one Turing Machine that >>> solves the halting problem thus fails if there are more than one. >> >> Irrelevant as that is not what Linz' says. >> And you should not lie about Rchard. >> > > Richard was confused bout this. Linz words were confusing > unless one had read many other proofs one might be confused. Anybody can be confused about your delusions. I havn't seen Richard confused about anything else. Sometiones his typos can be as confusing as mine. -- Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-06-03 20:56 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ -- key details |
| Message-ID | <v3lon1$2uv04$2@i2pn2.org> |
| In reply to | #106130 |
On 6/3/24 8:48 AM, olcott wrote: > On 6/3/2024 3:07 AM, Mikko wrote: >> On 2024-06-02 13:07:25 +0000, olcott said: >> >>> On 6/2/2024 2:36 AM, Mikko wrote: >>>> On 2024-06-01 14:37:01 +0000, olcott said: >>>> >>>>> 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. >>>> >>>> If there are no more questions about the details of the reasoning >>>> we may assume that the presiented reasoning is sufficieant. >>>> >>> >>> The above <is> the structure of his proof your empty assertion >>> utterly bereft of any supporting (EAUBoaSR)) reasoning counts for zilch. >> >> Those how know what "structure" means can see that it is not a structure. >> >>> Linz claims that of every Turing Machine there are none that solve >>> the halting problem. >> >> And proves the claim. >> >>> ∃!H ∈ Turing_Machines (What Richard was saying) >>> would say that there does not exist exactly one Turing Machine that >>> solves the halting problem thus fails if there are more than one. >> >> Irrelevant as that is not what Linz' says. >> And you should not lie about Rchard. >> > > Richard was confused bout this. Linz words were confusing > unless one had read many other proofs one might be confused. > > I know perfectly well what Linz says. YOU are the one that is confused, as you have even admitted.
[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 | #105625 |
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]
| 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 | <v34fft$2bb65$1@i2pn2.org> |
| In reply to | #105637 |
On 5/27/24 11:24 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.
>>
>
> *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
*** a single Turing Machine ***
not singular
>
> ...
>
> 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
*** some Turing Machine ***
Note singular
>
> Ordinary existential quantification looks for at least one
> element not exactly one element:
But you can look for at least one by looking for one without an
assumption that it is unique.
>
> Does at least one Turing machine exist of the infinite set
> of all Turing machines ...
Right, so if we can prove that none of them are correct, you have shown
that some is contradicted.
>
> So like I have always said, the second ⊢* specifies
> an infinite set of Turing machines.
>
As a SPECIFICATION of the domain of selection, yes.
As a SPECIFICATION of what THIS ONE machine does, no.
You just don't understand categorical logic.
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
Which categorically defines the limits of the behavior of the specific
H, as well as the set that H is taken from.
In the specific machine, ⊢* gets replaced with the precise set of
transitions that particular machine does.
In the Set that H was selected from, its just specifies limits of
behavior in that set.
But, as the proof moves on, he talks about assuming A machine, which is
THE H.
>
>> 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-28 10:37 -0500 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v34tnf$lfph$1@dont-email.me> |
| In reply to | #105641 |
On 5/28/2024 6:34 AM, Richard Damon wrote: > On 5/27/24 11:24 PM, olcott wrote: >> On 5/27/2024 7:17 PM, Richard Damon wrote: >>> >>> 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 > > *** a single Turing Machine *** > > not singular > >> >> ... >> >> 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 > > *** some Turing Machine *** > > Note singular > >> >> Ordinary existential quantification looks for at least one >> element not exactly one element: > > But you can look for at least one by looking for one without an > assumption that it is unique. > The Peter Linz words refer to ordinary existential quantification anchored in the infinite set of Turing machines. ∃H ∈ Turing_Machines ∀x ∈ Turing_Machines_Descriptions ∀y ∈ Finite_Strings such that H(x,y) = Halts(x,x) >> >> Does at least one Turing machine exist of the infinite set >> of all Turing machines ... > > Right, so if we can prove that none of them are correct, you have shown > that some is contradicted. > >> >> So like I have always said, the second ⊢* specifies >> an infinite set of Turing machines. >> > > As a SPECIFICATION of the domain of selection, yes. > > As a SPECIFICATION of what THIS ONE machine does, no. > My formalization already handles this. *Here is the same thing applied to H/D pairs* ∃H ∈ C_Functions ∀D ∈ x86_Machine_Code_of_C_Functions such that H(D,D) = Halts(D,D) -- 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 22:04 -0400 |
| Subject | Re: A simulating halt decider applied to the The Peter Linz Turing Machine description ⟨Ĥ⟩ |
| Message-ID | <v362f0$2d367$4@i2pn2.org> |
| In reply to | #105648 |
On 5/28/24 11:37 AM, olcott wrote: > On 5/28/2024 6:34 AM, Richard Damon wrote: >> On 5/27/24 11:24 PM, olcott wrote: >>> On 5/27/2024 7:17 PM, Richard Damon wrote: >>>> >>>> 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 >> >> *** a single Turing Machine *** >> >> not singular >> >>> >>> ... >>> >>> 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 >> >> *** some Turing Machine *** >> >> Note singular >> >>> >>> Ordinary existential quantification looks for at least one >>> element not exactly one element: >> >> But you can look for at least one by looking for one without an >> assumption that it is unique. >> > > The Peter Linz words refer to ordinary existential quantification > anchored in the infinite set of Turing machines. > > ∃H ∈ Turing_Machines > ∀x ∈ Turing_Machines_Descriptions > ∀y ∈ Finite_Strings > such that H(x,y) = Halts(x,x) > >>> >>> Does at least one Turing machine exist of the infinite set >>> of all Turing machines ... >> >> Right, so if we can prove that none of them are correct, you have >> shown that some is contradicted. >> >>> >>> So like I have always said, the second ⊢* specifies >>> an infinite set of Turing machines. >>> >> >> As a SPECIFICATION of the domain of selection, yes. >> >> As a SPECIFICATION of what THIS ONE machine does, no. >> > > My formalization already handles this. > > *Here is the same thing applied to H/D pairs* > ∃H ∈ C_Functions > ∀D ∈ x86_Machine_Code_of_C_Functions > such that H(D,D) = Halts(D,D) > > Do you REALLY mean to relax your specification to H just needing to be a "C Function"? Note, that might allow my cheat to get H to answer THIS PARTICULAR problem, but it still won't let H handle ALL machines. I don't think the limitation of asking D only about the input D fixes all the other non-computable problems.
[toc] | [prev] | [next] | [standalone]
| From | Alan Mackenzie <acm@muc.de> |
|---|---|
| Date | 2024-05-25 21:09 +0000 |
| Subject | Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 |
| Message-ID | <v2tk27$dut$1@news.muc.de> |
| In reply to | #105504 |
[ Followup-To: set ]
In comp.theory olcott <polcott333@gmail.com> wrote:
[ .... ]
> Not at all. I simply utterly reject the dishonest dodge
> of the strawman deception change-the-subject rebuttal.
> 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 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 at least one
> of the x86 instructions of D in the order specified by the x86
> instructions of D.
Having simulated at least one x86 instruction, what does a correct
simulator then do? This isn't made clear. I'm assuming it must return
an integer, as its C specification says.
> This may include correctly emulating the x86 instructions of H in the
> order specified by the x86 instructions of H thus calling H(D,D) in
> recursive simulation.
> *Execution Trace*
> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03 of
> D. This invokes H(D,D) again to repeat the process in endless recursive
> simulation.
Not if the simulation is "correct"; suppose the simulation emulates just
one instruction of D. Supposing it then returns 0 (somewhat extending
your definition of a "correct simulator"). The execution trace will then
be somewhat different from what you've outlined above.
> --
> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
> hits a target no one else can see." Arthur Schopenhauer
--
Alan Mackenzie (Nuremberg, Germany).
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-25 16:27 -0500 |
| Subject | Re: D correctly simulated by pure function H cannot possibly reach its, own line 06 |
| Message-ID | <v2tl3c$31uo4$1@dont-email.me> |
| In reply to | #105516 |
On 5/25/2024 4:09 PM, Alan Mackenzie wrote:
> [ Followup-To: set ]
>
> In comp.theory olcott <polcott333@gmail.com> wrote:
>
> [ .... ]
>
>> Not at all. I simply utterly reject the dishonest dodge
>> of the strawman deception change-the-subject rebuttal.
>
>> 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 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 at least one
>> of the x86 instructions of D in the order specified by the x86
>> instructions of D.
>
> Having simulated at least one x86 instruction, what does a correct
> simulator then do? This isn't made clear. I'm assuming it must return
> an integer, as its C specification says.
>
D correctly simulated by pure function H means that H correctly emulates
1 to N of the machine language instructions of D with an x86 emulator
and this involves 0 to M recursive emulations of H emulating itself
emulating D.
Because H is a pure function we know that H halts and returns some
value. For simplicity we will say that this value is the meaningless 56.
>> This may include correctly emulating the x86 instructions of H in the
>> order specified by the x86 instructions of H thus calling H(D,D) in
>> recursive simulation.
>
>> *Execution Trace*
>> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03 of
>> D. This invokes H(D,D) again to repeat the process in endless recursive
>> simulation.
>
> Not if the simulation is "correct"; suppose the simulation emulates just
> one instruction of D. Supposing it then returns 0 (somewhat extending
> your definition of a "correct simulator"). The execution trace will then
> be somewhat different from what you've outlined above.
>
I rephrased it to be more clear.
Thanks for your review.
>> --
>> Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
>> hits a target no one else can see." Arthur Schopenhauer
>
--
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 | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-05-26 12:47 +0200 |
| Message-ID | <v2v40u$3citg$1@dont-email.me> |
| In reply to | #105491 |
Op 25.mei.2024 om 19:56 schreef olcott:
> On 5/25/2024 7:52 AM, Richard Damon wrote:
>> On 5/25/24 12:28 AM, olcott wrote:
>
>
>
>>>> That you H, by just needing to be a "Pure Funtion" is not
>>>> necessarily the computatinal eqivalent of a Turing Machine.
>>>>
>>>
>>> Totally moot for the subject line.
>>
>> Nope, ESSENTINTIAL. I am not asking you to change your definition,
>> just accept its consequences.
>>
>
> 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 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 at least one
> of the x86 instructions of D in the order specified by the x86
> instructions of D.
>
> This may include correctly emulating the x86 instructions of H in the
> order specified by the x86 instructions of H thus calling H(D,D) in
> recursive simulation.
>
> *Execution Trace*
> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03 of
> D. This invokes H(D,D) again to repeat the process in endless recursive
> simulation.
>
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
>
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
> *This is only talking about the H/D c function pairs*
>
The claim is that the simulation of D does not halt, because it call to
H does not halt. The simulation does not even reach line 04, so the
simulation does not even see that D contradicts H. The claim, therefore
does not change if lines 04 and 05 are removed. What remains is that D
is a parameter duplicator, so that H can simulate itself. The result is
that each H in the infinite set of H finds that H is not halting. A
clear indication that a simulating decider is not a good idea.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-26 08:38 -0500 |
| Message-ID | <v2ve0q$3dtct$4@dont-email.me> |
| In reply to | #105555 |
On 5/26/2024 5:47 AM, Fred. Zwarts wrote:
> Op 25.mei.2024 om 19:56 schreef olcott:
>> On 5/25/2024 7:52 AM, Richard Damon wrote:
>>> On 5/25/24 12:28 AM, olcott wrote:
>>
>>
>>
>>>>> That you H, by just needing to be a "Pure Funtion" is not
>>>>> necessarily the computatinal eqivalent of a Turing Machine.
>>>>>
>>>>
>>>> Totally moot for the subject line.
>>>
>>> Nope, ESSENTINTIAL. I am not asking you to change your definition,
>>> just accept its consequences.
>>>
>>
>> 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 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 at least one
>> of the x86 instructions of D in the order specified by the x86
>> instructions of D.
>>
>> This may include correctly emulating the x86 instructions of H in the
>> order specified by the x86 instructions of H thus calling H(D,D) in
>> recursive simulation.
>>
>> *Execution Trace*
>> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03 of
>> D. This invokes H(D,D) again to repeat the process in endless recursive
>> simulation.
>>
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>>
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>> *This is only talking about the H/D c function pairs*
>>
>
> The claim is that the simulation of D does not halt, because it call to
> H does not halt. The simulation does not even reach line 04, so the
> simulation does not even see that D contradicts H. The claim, therefore
> does not change if lines 04 and 05 are removed. What remains is that D
> is a parameter duplicator, so that H can simulate itself. The result is
> that each H in the infinite set of H finds that H is not halting. A
> clear indication that a simulating decider is not a good idea.
Your transformation would have been acceptable if you retained the
fact that H is a pure function that always halts and returns some value.
In retrospect I should not have assumed that people here knew what a
pure function is.
In computer programming, a pure function is a function that has the
following properties:
(1) the function return values are identical for identical arguments
(no variation with local static variables, non-local variables, mutable
reference arguments or input streams), and
(2) the function has no side effects (no mutation of local static
variables, non-local variables, mutable reference arguments or
input/output streams). https://en.wikipedia.org/wiki/Pure_function
Because we can see that D correctly simulated by pure function
H cannot possibly reach its final state at line 06 and halt even
when an infinite number of steps are simulated we can know that
D specifies non-halting behavior.
That H is a pure function means that H eventually halts and returns
some value. We can say H returns the meaningless value of 56.
*Thanks for your review*
--
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 | Mikko <mikko.levanto@iki.fi> |
|---|---|
| Date | 2024-05-24 12:03 +0300 |
| Message-ID | <v2pl4r$28ohs$1@dont-email.me> |
| In reply to | #105431 |
On 2024-05-23 17:04:49 +0000, olcott said:
> 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 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 every reviewer had a different notion of
> correct simulation that diverges from this notion.
>
> A simulator is an x86 emulator that correctly emulates at least one
> of the x86 instructions of D in the order specified by the x86
> instructions of D.
>
> This may include correctly emulating the x86 instructions of H in
> the order specified by the x86 instructions of H thus calling H(D,D)
> in recursive simulation.
>
> *Execution Trace*
> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03
> of D. This invokes H(D,D) again to repeat the process in endless
> recursive simulation.
One can see that D is never stuch in recursive simulation unless H is.
Whether H is cannot be seen has the details of H are not shown. Even
if they were H must, in order to simulate any x86 execution, be so
big and complicated that essential aspect may be hard to see; depending,
of course, on how the code is organized.
--
Mikko
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-24 07:14 -0400 |
| Message-ID | <v2pspt$1v3p0$1@i2pn2.org> |
| In reply to | #105447 |
On 5/24/24 5:03 AM, Mikko wrote:
> On 2024-05-23 17:04:49 +0000, olcott said:
>
>> 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 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 every reviewer had a different notion of
>> correct simulation that diverges from this notion.
>>
>> A simulator is an x86 emulator that correctly emulates at least one
>> of the x86 instructions of D in the order specified by the x86
>> instructions of D.
>>
>> This may include correctly emulating the x86 instructions of H in
>> the order specified by the x86 instructions of H thus calling H(D,D)
>> in recursive simulation.
>>
>> *Execution Trace*
>> Line 11: main() invokes H(D,D); H(D,D) simulates lines 01, 02, and 03
>> of D. This invokes H(D,D) again to repeat the process in endless
>> recursive simulation.
>
> One can see that D is never stuch in recursive simulation unless H is.
> Whether H is cannot be seen has the details of H are not shown. Even
> if they were H must, in order to simulate any x86 execution, be so
> big and complicated that essential aspect may be hard to see; depending,
> of course, on how the code is organized.
>
Yep, that is a key part of the issue.
We could say that his H proves that his H isn't a decider, because it
isn't a "Halting Program" for the input.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.theory
csiph-web