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 1 of 10 [1] 2 3 … 10 Next page →
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-23 12:04 -0500 |
| Subject | Can you see that D correctly simulated by H remains stuck in recursive simulation? |
| Message-ID | <v2nsvh$1rd65$2@dont-email.me> |
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.
--
Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius
hits a target no one else can see." Arthur Schopenhauer
[toc] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-23 21:44 -0400 |
| Message-ID | <v2oreb$1tsmo$4@i2pn2.org> |
| In reply to | #105431 |
On 5/23/24 1:04 PM, 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 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.
>
Questions:
By your definiton of "Correct Simulation", you do realize that you have
broken connection between the simulaiton not completing and the program
described by the input not halting?
Also, you do realize that by your requirement on H just being a "pure
function" that does NOT say that you H qualified to be the computational
equivalent for a Turing Machine?
That due to your "strange" definition of what D is, you are putting
yourself outside of the grounds of "Computation Theory", as that deals
with the behavior of specific PROGRAMS, and not the "Program Templates"
like your D, our the "Infinite set of H/D pairs"?
Also, your "templagte D" is NOT built per either the Linz or Sipser
rules, as both of those had D built with a COPY of H, which is one of
your problems with a "Pure Function" as the equivelent. You have shown
that your H fails to meet the requirements of a Turing Machine
equivalent, as you can't (or it seems you can't) make equivalent copies,
where all copies always give the same answer for the same inputs. This
is a fundamental property of Turing Machines, which is why just bing a
"Pure Function" isn't good enough.
These issus need to be handled or acknowledged, before agreement on your
question, as you have shown a history of taking a statement and twisting
it (perhaps not intentionally, but because you don't understand what was
being communicated) so we need to have a firm understand of what you
mean and evidence that you accept the limititation causes by your
altered definitions from the problem that you initially claimed to have
started on.
Of course, it also means that even if/when you get your agreement, you
are no closer to your halting proof, as you have shown that you
undestand that you conditions actually tell you NOTHING about the actual
behavior of halting.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-23 21:22 -0500 |
| Message-ID | <v2otlq$24vfk$1@dont-email.me> |
| In reply to | #105438 |
On 5/23/2024 8:44 PM, Richard Damon wrote:
> On 5/23/24 1:04 PM, 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 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.
>>
>
> Questions:
>
> By your definiton of "Correct Simulation", you do realize that you have
> broken connection between the simulaiton not completing and the program
> described by the input not halting?
>
In other words you are requiring that the x86 instructions of D
(and possibly H) be simulated incorrectly and/or in the wrong order.
> Also, you do realize that by your requirement on H just being a "pure
> function" that does NOT say that you H qualified to be the computational
> equivalent for a Turing Machine?
>
That I require it to be a pure function
(a) Disallows you use of static local data.
(b) Does mean that H is Turing computable even if you don't understand
this.
> That due to your "strange" definition of what D is, you are putting
> yourself outside of the grounds of "Computation Theory", as that deals
> with the behavior of specific PROGRAMS, and not the "Program Templates"
> like your D, our the "Infinite set of H/D pairs"?
>
How you can fail to understand that this <is> such a template?
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
> Also, your "templagte D" is NOT built per either the Linz or Sipser
> rules, as both of those had D built with a COPY of H, which is one of
> your problems with a "Pure Function" as the equivelent. You have shown
> that your H fails to meet the requirements of a Turing Machine
This post is only talking about the above specified H, you keep
forgetting that.
> equivalent, as you can't (or it seems you can't) make equivalent copies,
> where all copies always give the same answer for the same inputs. This
> is a fundamental property of Turing Machines, which is why just bing a
> "Pure Function" isn't good enough.
>
For simulator H it is plenty good enough.
> These issus need to be handled or acknowledged, before agreement on your
> question, as you have shown a history of taking a statement and twisting
> it (perhaps not intentionally, but because you don't understand what was
> being communicated) so we need to have a firm understand of what you
> mean and evidence that you accept the limititation causes by your
> altered definitions from the problem that you initially claimed to have
> started on.
>
You just claimed that you do not understand that the Linz example is a
template. That does not seem like an honest mistake to me.
> Of course, it also means that even if/when you get your agreement, you
> are no closer to your halting proof, as you have shown that you
> undestand that you conditions actually tell you NOTHING about the actual
> behavior of halting.
>
You just claimed that you do not understand that the Linz example is a
template. That does not seem like an honest mistake to me.
--
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-23 22:41 -0400 |
| Message-ID | <v2oupf$1tsmn$1@i2pn2.org> |
| In reply to | #105440 |
On 5/23/24 10:22 PM, olcott wrote:
> On 5/23/2024 8:44 PM, Richard Damon wrote:
>> On 5/23/24 1:04 PM, 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 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.
>>>
>>
>> Questions:
>>
>> By your definiton of "Correct Simulation", you do realize that you
>> have broken connection between the simulaiton not completing and the
>> program described by the input not halting?
>>
>
> In other words you are requiring that the x86 instructions of D
> (and possibly H) be simulated incorrectly and/or in the wrong order.
No, they must be simulated COMPLETELY.
That is the only simulation that Computation Theory recognises as
showing halting status.
You should know that, so you are just showing you are deflecting.
>
>> Also, you do realize that by your requirement on H just being a "pure
>> function" that does NOT say that you H qualified to be the
>> computational equivalent for a Turing Machine?
>>
>
> That I require it to be a pure function
> (a) Disallows you use of static local data.
> (b) Does mean that H is Turing computable even if you don't understand
> this.
>
Nope.
It is neither suffient or required.
Your H1 being claimed to be a "copy" but giving a different value is a
proof of the insufficiency.
>> That due to your "strange" definition of what D is, you are putting
>> yourself outside of the grounds of "Computation Theory", as that deals
>> with the behavior of specific PROGRAMS, and not the "Program
>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>
>
> How you can fail to understand that this <is> such a template?
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
Nope, not a "template" as H (from which you built your embedded H) is a
SPEICIF (but arbitary) machine that meets that specification, and thus,
so is H^.
You don't seem to understand the maning of the terms.
>
>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>> rules, as both of those had D built with a COPY of H, which is one of
>> your problems with a "Pure Function" as the equivelent. You have shown
>> that your H fails to meet the requirements of a Turing Machine
>
> This post is only talking about the above specified H, you keep
> forgetting that.
Which my question are trying to confirm exactly what you means by that,
and that you understand the implications of it.
Clearly you don't.
>
>> equivalent, as you can't (or it seems you can't) make equivalent
>> copies, where all copies always give the same answer for the same
>> inputs. This is a fundamental property of Turing Machines, which is
>> why just bing a "Pure Function" isn't good enough.
>>
>
> For simulator H it is plenty good enough.
Nope.
>
>> These issus need to be handled or acknowledged, before agreement on
>> your question, as you have shown a history of taking a statement and
>> twisting it (perhaps not intentionally, but because you don't
>> understand what was being communicated) so we need to have a firm
>> understand of what you mean and evidence that you accept the
>> limititation causes by your altered definitions from the problem that
>> you initially claimed to have started on.
>>
>
> You just claimed that you do not understand that the Linz example is a
> template. That does not seem like an honest mistake to me.
Linz STARTS from a templete, the ^ template (that he introduces later in
the proof), and then select a SINGLE (but arbitrary) decider H, and from
that he builds (with his template) a single input to give to that
decider H^.
That is NOT what you are doing, and the fact you can't see the
difference shows your blindness to the truth,
>
>> Of course, it also means that even if/when you get your agreement, you
>> are no closer to your halting proof, as you have shown that you
>> undestand that you conditions actually tell you NOTHING about the
>> actual behavior of halting.
>>
>
> You just claimed that you do not understand that the Linz example is a
> template. That does not seem like an honest mistake to me.
>
It isn't, it is a specific H applied to a specific input showwing that
this specific machine could not have been a correct decider.
AFTER proving that for the specific machine that it was wrong, he can
point out that because he made no assumption about the details of that
H, we can select anew, ANY other machine as the H, and do the same
thing, and thus NO machine that met the original specification, which
includes ANY machine that would claim to be a Halt Decider, can actually
be correct.
You just don't understand the logic of universal categorical logic, even
though you try to claim you evented it under a different naem.
He proves for one SPECIFIC, but arbitary case, using the fact that it IS
a specific case (but not which one) and that he can show he can make
an input that disproves that one, he can show that he can make an input
for any decider that claims to meet the specification.
THAT is valid logic, but yours isn't, as all you show is that in your
full set of deciders, each looking at a different input machine (since
only machines have behavior, not templates) that particular decider gave
up before getting the answer.
We can also show that the answer it "gueess" can't be correct about the
halting problem.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-23 22:06 -0500 |
| Message-ID | <v2p07v$25aq3$1@dont-email.me> |
| In reply to | #105441 |
On 5/23/2024 9:41 PM, Richard Damon wrote:
> On 5/23/24 10:22 PM, olcott wrote:
>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>> On 5/23/24 1:04 PM, 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 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.
>>>>
>>>
>>> Questions:
>>>
>>> By your definiton of "Correct Simulation", you do realize that you
>>> have broken connection between the simulaiton not completing and the
>>> program described by the input not halting?
>>>
>>
>> In other words you are requiring that the x86 instructions of D
>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>
> No, they must be simulated COMPLETELY.
>
(a) *Clearly you are terrible at reading a spec*
(b) *non terminating computations cannot be simulated completely*
> That is the only simulation that Computation Theory recognises as
> showing halting status.
>
*Infinite loops need not be simulated completely to show a halt status*
> You should know that, so you are just showing you are deflecting.
>
DUMB MISTAKE ON YOUR PART
*Infinite loops need not be simulated completely to show a halt status*
>>
>>> Also, you do realize that by your requirement on H just being a "pure
>>> function" that does NOT say that you H qualified to be the
>>> computational equivalent for a Turing Machine?
>>>
>>
>> That I require it to be a pure function
>> (a) Disallows you use of static local data.
>> (b) Does mean that H is Turing computable even if you don't understand
>> this.
>>
>
> Nope.
>
> It is neither suffient or required.
>
*So you don't even know what a spec is*
> Your H1 being claimed to be a "copy" but giving a different value is a
> proof of the insufficiency.
>
THAT IS OFF-TOPIC FOR THE SUBJECT OF THIS THREAD.
>>> That due to your "strange" definition of what D is, you are putting
>>> yourself outside of the grounds of "Computation Theory", as that
>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>
>>
>> How you can fail to understand that this <is> such a template?
>> When Ĥ is applied to ⟨Ĥ⟩
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> Nope, not a "template" as H (from which you built your embedded H) is a
> SPEICIF (but arbitary) machine that meets that specification, and thus,
> so is H^.
>
Arbitrary MEANS template.
> You don't seem to understand the maning of the terms.
>
You are the one the directly contradicted yourself
It cannot be {A SPECIFIC MACHINE} and {AN ARBITRARY MACHINE}
>>
>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>> rules, as both of those had D built with a COPY of H, which is one of
>>> your problems with a "Pure Function" as the equivelent. You have
>>> shown that your H fails to meet the requirements of a Turing Machine
>>
>> This post is only talking about the above specified H, you keep
>> forgetting that.
>
> Which my question are trying to confirm exactly what you means by that,
> and that you understand the implications of it.
>
My spec if clear and you clearly keep ignoring it.
> Clearly you don't.
>
>>
>>> equivalent, as you can't (or it seems you can't) make equivalent
>>> copies, where all copies always give the same answer for the same
>>> inputs. This is a fundamental property of Turing Machines, which is
>>> why just bing a "Pure Function" isn't good enough.
>>>
>>
>> For simulator H it is plenty good enough.
>
> Nope.
>
We know that simulation is Turing computable on the basis of UTMs
Are you going to try and get away with pretending that you don't know this?
>>
>>> These issus need to be handled or acknowledged, before agreement on
>>> your question, as you have shown a history of taking a statement and
>>> twisting it (perhaps not intentionally, but because you don't
>>> understand what was being communicated) so we need to have a firm
>>> understand of what you mean and evidence that you accept the
>>> limititation causes by your altered definitions from the problem that
>>> you initially claimed to have started on.
>>>
>>
>> You just claimed that you do not understand that the Linz example is a
>> template. That does not seem like an honest mistake to me.
>
> Linz STARTS from a templete, the ^ template (that he introduces later in
> the proof), and then select a SINGLE (but arbitrary) decider H, and from
> that he builds (with his template) a single input to give to that
> decider H^.
>
SINGLE and arbitrary are mutually exclusive.
When Ĥ is applied to ⟨Ĥ⟩
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
*THIS SEEMS TO HELP YOU PAY BETTER ATTENTION*
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
Specifies an infinite set of implementations for embedded_H.
> That is NOT what you are doing, and the fact you can't see the
> difference shows your blindness to the truth,
>
>>
>>> Of course, it also means that even if/when you get your agreement,
>>> you are no closer to your halting proof, as you have shown that you
>>> undestand that you conditions actually tell you NOTHING about the
>>> actual behavior of halting.
>>>
>>
>> You just claimed that you do not understand that the Linz example is a
>> template. That does not seem like an honest mistake to me.
>>
>
>
> It isn't, it is a specific H applied to a specific input showwing that
> this specific machine could not have been a correct decider.
>
> AFTER proving that for the specific machine that it was wrong, he can
> point out that because he made no assumption about the details of that
> H, we can select anew, ANY other machine as the H, and do the same
> thing, and thus NO machine that met the original specification, which
> includes ANY machine that would claim to be a Halt Decider, can actually
> be correct.
>
Likewise for D correctly simulated by pure function H for
every H/D pair Linz specifies every embedded_H/⟨Ĥ⟩ pair.
> You just don't understand the logic of universal categorical logic, even
> though you try to claim you evented it under a different naem.
>
No the whole problem seems to be your attention span.
> He proves for one SPECIFIC, but arbitary case, using the fact that it IS
> a specific case (but not which one) and that he can show he can make
> an input that disproves that one, he can show that he can make an input
> for any decider that claims to meet the specification.
>
> THAT is valid logic, but yours isn't, as all you show is that in your
> full set of deciders, each looking at a different input machine (since
> only machines have behavior, not templates) that particular decider gave
> up before getting the answer.
>
> We can also show that the answer it "gueess" can't be correct about the
> halting problem.
--
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-23 23:47 -0400 |
| Message-ID | <v2p2km$1tsmo$6@i2pn2.org> |
| In reply to | #105442 |
On 5/23/24 11:06 PM, olcott wrote:
> On 5/23/2024 9:41 PM, Richard Damon wrote:
>> On 5/23/24 10:22 PM, olcott wrote:
>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>
>>>>
>>>> Questions:
>>>>
>>>> By your definiton of "Correct Simulation", you do realize that you
>>>> have broken connection between the simulaiton not completing and the
>>>> program described by the input not halting?
>>>>
>>>
>>> In other words you are requiring that the x86 instructions of D
>>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>>
>> No, they must be simulated COMPLETELY.
>>
>
> (a) *Clearly you are terrible at reading a spec*
> (b) *non terminating computations cannot be simulated completely*
Not by your definition,
D(D) proves you wrong, since it HALTS when run, it terminates.
You may be able to prove that no decider can simulate the "not a machine
but a template" that your D is. Since the problem space SHOULD be
"programs", you fail at even that point
>
>> That is the only simulation that Computation Theory recognises as
>> showing halting status.
>>
>
> *Infinite loops need not be simulated completely to show a halt status*
Right, becasue we can prove that the
Computaton-Theory-Correct-Simulation will never reach an end,
>
>> You should know that, so you are just showing you are deflecting.
>>
>
> DUMB MISTAKE ON YOUR PART
> *Infinite loops need not be simulated completely to show a halt status*
Right, because we can prove that the
Computaiton-Theory-Correct-Simulation will never reach an end.
That doesn't happen for your H/D compinations, the
Computation-Theory-correct-simulation of the input to any of the H/D
pairs where H returns an answer, will reacn the final state, so the H
was wrong about halting.
And so is your logic.
>
>>>
>>>> Also, you do realize that by your requirement on H just being a
>>>> "pure function" that does NOT say that you H qualified to be the
>>>> computational equivalent for a Turing Machine?
>>>>
>>>
>>> That I require it to be a pure function
>>> (a) Disallows you use of static local data.
>>> (b) Does mean that H is Turing computable even if you don't
>>> understand this.
>>>
>>
>> Nope.
>>
>> It is neither suffient or required.
>>
>
> *So you don't even know what a spec is*
Sure I do, you are the one that fails at it.
>
>> Your H1 being claimed to be a "copy" but giving a different value is a
>> proof of the insufficiency.
>>
>
> THAT IS OFF-TOPIC FOR THE SUBJECT OF THIS THREAD.
Nope, proves the point that "Pure Function" by your definition is
insufficient for a program to be a Turing machine equivalent.
I guess you are just conceeding that one.
>
>>>> That due to your "strange" definition of what D is, you are putting
>>>> yourself outside of the grounds of "Computation Theory", as that
>>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>>
>>>
>>> How you can fail to understand that this <is> such a template?
>>> When Ĥ is applied to ⟨Ĥ⟩
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>
>> Nope, not a "template" as H (from which you built your embedded H) is
>> a SPEICIF (but arbitary) machine that meets that specification, and
>> thus, so is H^.
>>
>
> Arbitrary MEANS template.
Nope.
If I say choose an arbitrary student in a class, and then do something,
I mean to choose any one student from the class and do it with them.
>
>> You don't seem to understand the maning of the terms.
>>
>
> You are the one the directly contradicted yourself
> It cannot be {A SPECIFIC MACHINE} and {AN ARBITRARY MACHINE}
Sure it can. Being Arbirary means I am not limiting which one you can
choose.
I guess you don't understand the meaning of the words.
>
>>>
>>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>>> rules, as both of those had D built with a COPY of H, which is one
>>>> of your problems with a "Pure Function" as the equivelent. You have
>>>> shown that your H fails to meet the requirements of a Turing Machine
>>>
>>> This post is only talking about the above specified H, you keep
>>> forgetting that.
>>
>> Which my question are trying to confirm exactly what you means by
>> that, and that you understand the implications of it.
>>
>
> My spec if clear and you clearly keep ignoring it.
Nope, and it is clear you don't understand the implications of your
oddly defined (for the field) terms.
>
>> Clearly you don't.
>>
>>>
>>>> equivalent, as you can't (or it seems you can't) make equivalent
>>>> copies, where all copies always give the same answer for the same
>>>> inputs. This is a fundamental property of Turing Machines, which is
>>>> why just bing a "Pure Function" isn't good enough.
>>>>
>>>
>>> For simulator H it is plenty good enough.
>>
>> Nope.
>>
>
> We know that simulation is Turing computable on the basis of UTMs
That is a non-sense sentence.
The existance of Universal Turing Machines (UTM) means that it is
possible to make a single Turing Machine that can "simulate" the
behavior of any other Turing machine, by giving a description of it as
an input. Note, the equivalence of the behavior of the UTM and the
machine descirbe only occurs when the UTM never stops until it reaches
the final state.
Thus we have the property, that the COMPLETE (and accurate, which is
assumed) simulation of the input produces the behavior of the machine
described.
If you create a machine that acts sort of like a UTM but stops before it
gets there, doesn't say ANYTHING about the behavior of the program
described.
You don't seem to understand that the ONLY "simulation" that you get by
mentioning UTMs is the complete and correct simulation that a UTM does.
There is no such thing as a UTM that stops before it gets to the end, if
a machine stop simulating before it reachs a final state, it just never
was a UTM.
>
> Are you going to try and get away with pretending that you don't know this?
Nope, but you seem to be.
>
>>>
>>>> These issus need to be handled or acknowledged, before agreement on
>>>> your question, as you have shown a history of taking a statement and
>>>> twisting it (perhaps not intentionally, but because you don't
>>>> understand what was being communicated) so we need to have a firm
>>>> understand of what you mean and evidence that you accept the
>>>> limititation causes by your altered definitions from the problem
>>>> that you initially claimed to have started on.
>>>>
>>>
>>> You just claimed that you do not understand that the Linz example is
>>> a template. That does not seem like an honest mistake to me.
>>
>> Linz STARTS from a templete, the ^ template (that he introduces later
>> in the proof), and then select a SINGLE (but arbitrary) decider H, and
>> from that he builds (with his template) a single input to give to that
>> decider H^.
>>
>
> SINGLE and arbitrary are mutually exclusive.
Nope.
> When Ĥ is applied to ⟨Ĥ⟩
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>
> *THIS SEEMS TO HELP YOU PAY BETTER ATTENTION*
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
>
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
> Specifies an infinite set of implementations for embedded_H.
Nope, Just shows you are too dumb to know the meaning of the words being
use.
Can you find a definiton where abritrary refers to selecting the WHOLE
set, and not a specific element out of the set.
You are confusing the fact that if you can prove a statement true "for
each" element of a set, we can show that we have proved it true "for all"
But the x gotten in the phrase "For each x in set Y ..." is just a
single value for the following section (but you can repeat the WHOLE
SECTION ANEW for every element in the set.
Thus, When we talk about being able to make a D for each H in the set of
Halt Decider, and then do Y with it, for the doing Y, we have just a
single H/D pair to look at, and only that pair. We don't get to look at
OTHER pairs that might come up on a different iteration.
Of course, you logic can't handle trying to do such a proof, so you need
to LIE and confuse the logic.
>
>> That is NOT what you are doing, and the fact you can't see the
>> difference shows your blindness to the truth,
>>
>>>
>>>> Of course, it also means that even if/when you get your agreement,
>>>> you are no closer to your halting proof, as you have shown that you
>>>> undestand that you conditions actually tell you NOTHING about the
>>>> actual behavior of halting.
>>>>
>>>
>>> You just claimed that you do not understand that the Linz example is
>>> a template. That does not seem like an honest mistake to me.
>>>
>>
>>
>> It isn't, it is a specific H applied to a specific input showwing that
>> this specific machine could not have been a correct decider.
>>
>> AFTER proving that for the specific machine that it was wrong, he can
>> point out that because he made no assumption about the details of that
>> H, we can select anew, ANY other machine as the H, and do the same
>> thing, and thus NO machine that met the original specification, which
>> includes ANY machine that would claim to be a Halt Decider, can
>> actually be correct.
>>
>
> Likewise for D correctly simulated by pure function H for
> every H/D pair Linz specifies every embedded_H/⟨Ĥ⟩ pair.
Nope.
Linz analyzed a SPECIFIC machine with a specific input, and showed it
got it wrong.
You just don't understand what you are talking about.
>
>> You just don't understand the logic of universal categorical logic,
>> even though you try to claim you evented it under a different naem.
>>
>
> No the whole problem seems to be your attention span.
No, the whole problem is you lack of ever learning the meaning of the
words you use, and being too stupid to learn.
>
>> He proves for one SPECIFIC, but arbitary case, using the fact that it
>> IS a specific case (but not which one) and that he can show he can
>> make an input that disproves that one, he can show that he can make an
>> input for any decider that claims to meet the specification.
>>
>> THAT is valid logic, but yours isn't, as all you show is that in your
>> full set of deciders, each looking at a different input machine (since
>> only machines have behavior, not templates) that particular decider
>> gave up before getting the answer.
>>
>> We can also show that the answer it "gueess" can't be correct about
>> the halting problem.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-23 22:59 -0500 |
| Message-ID | <v2p3b0$25mkh$2@dont-email.me> |
| In reply to | #105443 |
On 5/23/2024 10:47 PM, Richard Damon wrote:
> On 5/23/24 11:06 PM, olcott wrote:
>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>> On 5/23/24 10:22 PM, olcott wrote:
>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>
>>>>>
>>>>> Questions:
>>>>>
>>>>> By your definiton of "Correct Simulation", you do realize that you
>>>>> have broken connection between the simulaiton not completing and
>>>>> the program described by the input not halting?
>>>>>
>>>>
>>>> In other words you are requiring that the x86 instructions of D
>>>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>>>
>>> No, they must be simulated COMPLETELY.
>>>
>>
>> (a) *Clearly you are terrible at reading a spec*
>> (b) *non terminating computations cannot be simulated completely*
>
> Not by your definition,
>
> D(D) proves you wrong, since it HALTS when run, it terminates.
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
--
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-24 07:18 -0400 |
| Message-ID | <v2pt1h$1v3p0$3@i2pn2.org> |
| In reply to | #105444 |
On 5/23/24 11:59 PM, olcott wrote:
> On 5/23/2024 10:47 PM, Richard Damon wrote:
>> On 5/23/24 11:06 PM, olcott wrote:
>>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>>> On 5/23/24 10:22 PM, olcott wrote:
>>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> By your definiton of "Correct Simulation", you do realize that you
>>>>>> have broken connection between the simulaiton not completing and
>>>>>> the program described by the input not halting?
>>>>>>
>>>>>
>>>>> In other words you are requiring that the x86 instructions of D
>>>>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>>>>
>>>> No, they must be simulated COMPLETELY.
>>>>
>>>
>>> (a) *Clearly you are terrible at reading a spec*
>>> (b) *non terminating computations cannot be simulated completely*
>>
>> Not by your definition,
>>
>> D(D) proves you wrong, since it HALTS when run, it terminates.
> *D correctly simulated by pure function H cannot possibly halt*
The FUNCTION D halts (if the H(D,D) returns 0) but the simulation by the
H doesn'tr, because H gives up too soon.
WHO CARES about the simulation of D by H? Especially when your
definition of "Correct Simulation" that H does has divorced itself from
the question of the program halting. Unless my intent is to run programs
under you emulation system, there behavior under it is irrelevant.
Note, I have yet to give you an answer to your question under your
current "definitions" because they have deceptive implications.
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-24 14:57 -0500 |
| Message-ID | <v2qrer$2fesr$2@dont-email.me> |
| In reply to | #105451 |
On 5/24/2024 6:18 AM, Richard Damon wrote:
> On 5/23/24 11:59 PM, olcott wrote:
>> On 5/23/2024 10:47 PM, Richard Damon wrote:
>>> On 5/23/24 11:06 PM, olcott wrote:
>>>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>>>> On 5/23/24 10:22 PM, olcott wrote:
>>>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>>
>>>>>>>
>>>>>>> Questions:
>>>>>>>
>>>>>>> By your definiton of "Correct Simulation", you do realize that
>>>>>>> you have broken connection between the simulaiton not completing
>>>>>>> and the program described by the input not halting?
>>>>>>>
>>>>>>
>>>>>> In other words you are requiring that the x86 instructions of D
>>>>>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>>>>>
>>>>> No, they must be simulated COMPLETELY.
>>>>>
>>>>
>>>> (a) *Clearly you are terrible at reading a spec*
>>>> (b) *non terminating computations cannot be simulated completely*
>>>
>>> Not by your definition,
>>>
>>> D(D) proves you wrong, since it HALTS when run, it terminates.
>> *D correctly simulated by pure function H cannot possibly halt*
>
> The FUNCTION D halts
The strawman deception away form the subject of the subject
line will not be tolerated. I let Ben Bacarisse get away with
that for fifteen years.
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
*D correctly simulated by pure function H cannot possibly halt*
Not even after a quadrillion steps of correct simulation.
--
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-24 17:03 -0400 |
| Message-ID | <v2qvb9$1vblp$5@i2pn2.org> |
| In reply to | #105461 |
On 5/24/24 3:57 PM, olcott wrote:
> On 5/24/2024 6:18 AM, Richard Damon wrote:
>> On 5/23/24 11:59 PM, olcott wrote:
>>> On 5/23/2024 10:47 PM, Richard Damon wrote:
>>>> On 5/23/24 11:06 PM, olcott wrote:
>>>>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>>>>> On 5/23/24 10:22 PM, olcott wrote:
>>>>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Questions:
>>>>>>>>
>>>>>>>> By your definiton of "Correct Simulation", you do realize that
>>>>>>>> you have broken connection between the simulaiton not completing
>>>>>>>> and the program described by the input not halting?
>>>>>>>>
>>>>>>>
>>>>>>> In other words you are requiring that the x86 instructions of D
>>>>>>> (and possibly H) be simulated incorrectly and/or in the wrong order.
>>>>>>
>>>>>> No, they must be simulated COMPLETELY.
>>>>>>
>>>>>
>>>>> (a) *Clearly you are terrible at reading a spec*
>>>>> (b) *non terminating computations cannot be simulated completely*
>>>>
>>>> Not by your definition,
>>>>
>>>> D(D) proves you wrong, since it HALTS when run, it terminates.
>>> *D correctly simulated by pure function H cannot possibly halt*
>>
>> The FUNCTION D halts
>
> The strawman deception away form the subject of the subject
> line will not be tolerated. I let Ben Bacarisse get away with
> that for fifteen years.
>
> *D correctly simulated by pure function H cannot possibly halt*
And this is where your lies start.
the FUNCTIOPN halts.
The SIMULATION of the funciton doesn't reach an end.
Since your definition of "Simulation" isn't that of Computation Theory,
you can't truthfully talk about your simulation non-halting.
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
>
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
>
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
>
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
> *D correctly simulated by pure function H cannot possibly halt*
>
> Not even after a quadrillion steps of correct simulation.
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-24 16:27 -0500 |
| Message-ID | <v2r0ns$2ge4f$1@dont-email.me> |
| In reply to | #105469 |
On 5/24/2024 4:03 PM, Richard Damon wrote:
> On 5/24/24 3:57 PM, olcott wrote:
>> On 5/24/2024 6:18 AM, Richard Damon wrote:
>>> On 5/23/24 11:59 PM, olcott wrote:
>>>> On 5/23/2024 10:47 PM, Richard Damon wrote:
>>>>> On 5/23/24 11:06 PM, olcott wrote:
>>>>>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>>>>>> On 5/23/24 10:22 PM, olcott wrote:
>>>>>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Questions:
>>>>>>>>>
>>>>>>>>> By your definiton of "Correct Simulation", you do realize that
>>>>>>>>> you have broken connection between the simulaiton not
>>>>>>>>> completing and the program described by the input not halting?
>>>>>>>>>
>>>>>>>>
>>>>>>>> In other words you are requiring that the x86 instructions of D
>>>>>>>> (and possibly H) be simulated incorrectly and/or in the wrong
>>>>>>>> order.
>>>>>>>
>>>>>>> No, they must be simulated COMPLETELY.
>>>>>>>
>>>>>>
>>>>>> (a) *Clearly you are terrible at reading a spec*
>>>>>> (b) *non terminating computations cannot be simulated completely*
>>>>>
>>>>> Not by your definition,
>>>>>
>>>>> D(D) proves you wrong, since it HALTS when run, it terminates.
>>>> *D correctly simulated by pure function H cannot possibly halt*
>>>
>>> The FUNCTION D halts
>>
>> The strawman deception away form the subject of the subject
>> line will not be tolerated. I let Ben Bacarisse get away with
>> that for fifteen years.
>>
>> *D correctly simulated by pure function H cannot possibly halt*
>
> And this is where your lies start.
>
I WILL NO LONGER TOLERATE THE STRAW-MAN DECEPTION CHANGE THE
SUBJECT FAKE REBUTTAL THAT PREVENTS ANY CLOSURE ON ANY POINTS.
WE CAN GET TO THE OTHER POINTS ONLY WHEN WE ARE DONE WITH THIS ONE.
THE SUBJECT OF THE THREAD IS THE POINT OF THIS THREAD
--
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-24 18:17 -0400 |
| Message-ID | <v2r3mn$1vblq$7@i2pn2.org> |
| In reply to | #105470 |
On 5/24/24 5:27 PM, olcott wrote:
> On 5/24/2024 4:03 PM, Richard Damon wrote:
>> On 5/24/24 3:57 PM, olcott wrote:
>>> On 5/24/2024 6:18 AM, Richard Damon wrote:
>>>> On 5/23/24 11:59 PM, olcott wrote:
>>>>> On 5/23/2024 10:47 PM, Richard Damon wrote:
>>>>>> On 5/23/24 11:06 PM, olcott wrote:
>>>>>>> On 5/23/2024 9:41 PM, Richard Damon wrote:
>>>>>>>> On 5/23/24 10:22 PM, olcott wrote:
>>>>>>>>> On 5/23/2024 8:44 PM, Richard Damon wrote:
>>>>>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Questions:
>>>>>>>>>>
>>>>>>>>>> By your definiton of "Correct Simulation", you do realize that
>>>>>>>>>> you have broken connection between the simulaiton not
>>>>>>>>>> completing and the program described by the input not halting?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> In other words you are requiring that the x86 instructions of D
>>>>>>>>> (and possibly H) be simulated incorrectly and/or in the wrong
>>>>>>>>> order.
>>>>>>>>
>>>>>>>> No, they must be simulated COMPLETELY.
>>>>>>>>
>>>>>>>
>>>>>>> (a) *Clearly you are terrible at reading a spec*
>>>>>>> (b) *non terminating computations cannot be simulated completely*
>>>>>>
>>>>>> Not by your definition,
>>>>>>
>>>>>> D(D) proves you wrong, since it HALTS when run, it terminates.
>>>>> *D correctly simulated by pure function H cannot possibly halt*
>>>>
>>>> The FUNCTION D halts
>>>
>>> The strawman deception away form the subject of the subject
>>> line will not be tolerated. I let Ben Bacarisse get away with
>>> that for fifteen years.
>>>
>>> *D correctly simulated by pure function H cannot possibly halt*
>>
>> And this is where your lies start.
>>
>
> I WILL NO LONGER TOLERATE THE STRAW-MAN DECEPTION CHANGE THE
> SUBJECT FAKE REBUTTAL THAT PREVENTS ANY CLOSURE ON ANY POINTS.
>
> WE CAN GET TO THE OTHER POINTS ONLY WHEN WE ARE DONE WITH THIS ONE.
> THE SUBJECT OF THE THREAD IS THE POINT OF THIS THREAD
>
So, you are just stipulating that you reserve the right to lie?
You refuse to positively clarify what you mean, because you are going to
change the meaning in the future.
Until you agree to what your words mean and imply, we can't go forward,
so I guess you just plan to die as a proved pathological liar.
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@HetNet.nl> |
|---|---|
| Date | 2024-05-24 12:46 +0200 |
| Message-ID | <v2pr71$29rhj$2@dont-email.me> |
| In reply to | #105438 |
Op 24.mei.2024 om 03:44 schreef Richard Damon:
> On 5/23/24 1:04 PM, 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 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.
>>
>
> Questions:
>
> By your definiton of "Correct Simulation", you do realize that you have
> broken connection between the simulaiton not completing and the program
> described by the input not halting?
>
> Also, you do realize that by your requirement on H just being a "pure
> function" that does NOT say that you H qualified to be the computational
> equivalent for a Turing Machine?
>
> That due to your "strange" definition of what D is, you are putting
> yourself outside of the grounds of "Computation Theory", as that deals
> with the behavior of specific PROGRAMS, and not the "Program Templates"
> like your D, our the "Infinite set of H/D pairs"?
>
> Also, your "templagte D" is NOT built per either the Linz or Sipser
> rules, as both of those had D built with a COPY of H, which is one of
> your problems with a "Pure Function" as the equivelent. You have shown
> that your H fails to meet the requirements of a Turing Machine
> equivalent, as you can't (or it seems you can't) make equivalent copies,
> where all copies always give the same answer for the same inputs. This
> is a fundamental property of Turing Machines, which is why just bing a
> "Pure Function" isn't good enough.
>
> These issus need to be handled or acknowledged, before agreement on your
> question, as you have shown a history of taking a statement and twisting
> it (perhaps not intentionally, but because you don't understand what was
> being communicated) so we need to have a firm understand of what you
> mean and evidence that you accept the limititation causes by your
> altered definitions from the problem that you initially claimed to have
> started on.
>
> Of course, it also means that even if/when you get your agreement, you
> are no closer to your halting proof, as you have shown that you
> undestand that you conditions actually tell you NOTHING about the actual
> behavior of halting.
>
If olcott wants to be closer to the Linz or Sipser rules, he could do so
with a small modification: use different names for H. Use H1 when called
by main and use H2 when called by D. H1 and H2 are not required to be
exact copies of each other, but only to be functionally equivalent. By
doing so, a lot of useless discussions could be avoided.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-24 07:14 -0400 |
| Message-ID | <v2psq3$1v3p0$2@i2pn2.org> |
| In reply to | #105448 |
On 5/24/24 6:46 AM, Fred. Zwarts wrote:
> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>> On 5/23/24 1:04 PM, 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 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.
>>>
>>
>> Questions:
>>
>> By your definiton of "Correct Simulation", you do realize that you
>> have broken connection between the simulaiton not completing and the
>> program described by the input not halting?
>>
>> Also, you do realize that by your requirement on H just being a "pure
>> function" that does NOT say that you H qualified to be the
>> computational equivalent for a Turing Machine?
>>
>> That due to your "strange" definition of what D is, you are putting
>> yourself outside of the grounds of "Computation Theory", as that deals
>> with the behavior of specific PROGRAMS, and not the "Program
>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>
>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>> rules, as both of those had D built with a COPY of H, which is one of
>> your problems with a "Pure Function" as the equivelent. You have shown
>> that your H fails to meet the requirements of a Turing Machine
>> equivalent, as you can't (or it seems you can't) make equivalent
>> copies, where all copies always give the same answer for the same
>> inputs. This is a fundamental property of Turing Machines, which is
>> why just bing a "Pure Function" isn't good enough.
>>
>> These issus need to be handled or acknowledged, before agreement on
>> your question, as you have shown a history of taking a statement and
>> twisting it (perhaps not intentionally, but because you don't
>> understand what was being communicated) so we need to have a firm
>> understand of what you mean and evidence that you accept the
>> limititation causes by your altered definitions from the problem that
>> you initially claimed to have started on.
>>
>> Of course, it also means that even if/when you get your agreement, you
>> are no closer to your halting proof, as you have shown that you
>> undestand that you conditions actually tell you NOTHING about the
>> actual behavior of halting.
>>
>
> If olcott wants to be closer to the Linz or Sipser rules, he could do so
> with a small modification: use different names for H. Use H1 when called
> by main and use H2 when called by D. H1 and H2 are not required to be
> exact copies of each other, but only to be functionally equivalent. By
> doing so, a lot of useless discussions could be avoided.
Yes, he could, but when it was proposed that we make D call its own
identical copy of H, he rejected it saying it wasn't allowed.
Of course, the reason it isn't allowed is that it makes his method of
detecting that D calls (a copy of) H not work and his whole method falls
apart, as his H just never answers.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-24 14:52 -0500 |
| Message-ID | <v2qr6n$2fesr$1@dont-email.me> |
| In reply to | #105450 |
On 5/24/2024 6:14 AM, Richard Damon wrote:
> On 5/24/24 6:46 AM, Fred. Zwarts wrote:
>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>> On 5/23/24 1:04 PM, 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 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.
>>>>
>>>
>>> Questions:
>>>
>>> By your definiton of "Correct Simulation", you do realize that you
>>> have broken connection between the simulaiton not completing and the
>>> program described by the input not halting?
>>>
>>> Also, you do realize that by your requirement on H just being a "pure
>>> function" that does NOT say that you H qualified to be the
>>> computational equivalent for a Turing Machine?
>>>
>>> That due to your "strange" definition of what D is, you are putting
>>> yourself outside of the grounds of "Computation Theory", as that
>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>
>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>> rules, as both of those had D built with a COPY of H, which is one of
>>> your problems with a "Pure Function" as the equivelent. You have
>>> shown that your H fails to meet the requirements of a Turing Machine
>>> equivalent, as you can't (or it seems you can't) make equivalent
>>> copies, where all copies always give the same answer for the same
>>> inputs. This is a fundamental property of Turing Machines, which is
>>> why just bing a "Pure Function" isn't good enough.
>>>
>>> These issus need to be handled or acknowledged, before agreement on
>>> your question, as you have shown a history of taking a statement and
>>> twisting it (perhaps not intentionally, but because you don't
>>> understand what was being communicated) so we need to have a firm
>>> understand of what you mean and evidence that you accept the
>>> limititation causes by your altered definitions from the problem that
>>> you initially claimed to have started on.
>>>
>>> Of course, it also means that even if/when you get your agreement,
>>> you are no closer to your halting proof, as you have shown that you
>>> undestand that you conditions actually tell you NOTHING about the
>>> actual behavior of halting.
>>>
>>
>> If olcott wants to be closer to the Linz or Sipser rules, he could do
>> so with a small modification: use different names for H. Use H1 when
>> called by main and use H2 when called by D. H1 and H2 are not required
>> to be exact copies of each other, but only to be functionally
>> equivalent. By doing so, a lot of useless discussions could be avoided.
>
> Yes, he could, but when it was proposed that we make D call its own
> identical copy of H, he rejected it saying it wasn't allowed.
>
> Of course, the reason it isn't allowed is that it makes his method of
> detecting that D calls (a copy of) H not work and his whole method falls
> apart, as his H just never answers.
A copy of D crashes the libx86emu emulator unless the copy
is very small having less code than the full 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-24 17:03 -0400 |
| Message-ID | <v2qvb5$1vblp$4@i2pn2.org> |
| In reply to | #105460 |
On 5/24/24 3:52 PM, olcott wrote:
> On 5/24/2024 6:14 AM, Richard Damon wrote:
>> On 5/24/24 6:46 AM, Fred. Zwarts wrote:
>>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>
>>>>
>>>> Questions:
>>>>
>>>> By your definiton of "Correct Simulation", you do realize that you
>>>> have broken connection between the simulaiton not completing and the
>>>> program described by the input not halting?
>>>>
>>>> Also, you do realize that by your requirement on H just being a
>>>> "pure function" that does NOT say that you H qualified to be the
>>>> computational equivalent for a Turing Machine?
>>>>
>>>> That due to your "strange" definition of what D is, you are putting
>>>> yourself outside of the grounds of "Computation Theory", as that
>>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>>
>>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>>> rules, as both of those had D built with a COPY of H, which is one
>>>> of your problems with a "Pure Function" as the equivelent. You have
>>>> shown that your H fails to meet the requirements of a Turing Machine
>>>> equivalent, as you can't (or it seems you can't) make equivalent
>>>> copies, where all copies always give the same answer for the same
>>>> inputs. This is a fundamental property of Turing Machines, which is
>>>> why just bing a "Pure Function" isn't good enough.
>>>>
>>>> These issus need to be handled or acknowledged, before agreement on
>>>> your question, as you have shown a history of taking a statement and
>>>> twisting it (perhaps not intentionally, but because you don't
>>>> understand what was being communicated) so we need to have a firm
>>>> understand of what you mean and evidence that you accept the
>>>> limititation causes by your altered definitions from the problem
>>>> that you initially claimed to have started on.
>>>>
>>>> Of course, it also means that even if/when you get your agreement,
>>>> you are no closer to your halting proof, as you have shown that you
>>>> undestand that you conditions actually tell you NOTHING about the
>>>> actual behavior of halting.
>>>>
>>>
>>> If olcott wants to be closer to the Linz or Sipser rules, he could do
>>> so with a small modification: use different names for H. Use H1 when
>>> called by main and use H2 when called by D. H1 and H2 are not
>>> required to be exact copies of each other, but only to be
>>> functionally equivalent. By doing so, a lot of useless discussions
>>> could be avoided.
>>
>> Yes, he could, but when it was proposed that we make D call its own
>> identical copy of H, he rejected it saying it wasn't allowed.
>>
>> Of course, the reason it isn't allowed is that it makes his method of
>> detecting that D calls (a copy of) H not work and his whole method
>> falls apart, as his H just never answers.
>
> A copy of D crashes the libx86emu emulator unless the copy
> is very small having less code than the full D.
>
That is very strange, unless you have configured the emulator for very
small memory space, and that just shows a limitation to your computation
implementation, so, you are just admitting that you tools can't handle
the logic system.
That IS the requirement to be able to claim you are working per the
specification.
And how were you able to define a new copy H1 to look at H1(D,D) if you
couldn't instead have H(D,D) look at an D that called H1(D,D) as its
copy? That should have had the exact same memory issue.
I think you have been caught in an inconsistance.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-24 16:35 -0500 |
| Message-ID | <v2r17j$2ge4f$2@dont-email.me> |
| In reply to | #105468 |
On 5/24/2024 4:03 PM, Richard Damon wrote:
> On 5/24/24 3:52 PM, olcott wrote:
>> On 5/24/2024 6:14 AM, Richard Damon wrote:
>>> On 5/24/24 6:46 AM, Fred. Zwarts wrote:
>>>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>
>>>>>
>>>>> Questions:
>>>>>
>>>>> By your definiton of "Correct Simulation", you do realize that you
>>>>> have broken connection between the simulaiton not completing and
>>>>> the program described by the input not halting?
>>>>>
>>>>> Also, you do realize that by your requirement on H just being a
>>>>> "pure function" that does NOT say that you H qualified to be the
>>>>> computational equivalent for a Turing Machine?
>>>>>
>>>>> That due to your "strange" definition of what D is, you are putting
>>>>> yourself outside of the grounds of "Computation Theory", as that
>>>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>>>
>>>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>>>> rules, as both of those had D built with a COPY of H, which is one
>>>>> of your problems with a "Pure Function" as the equivelent. You have
>>>>> shown that your H fails to meet the requirements of a Turing
>>>>> Machine equivalent, as you can't (or it seems you can't) make
>>>>> equivalent copies, where all copies always give the same answer for
>>>>> the same inputs. This is a fundamental property of Turing Machines,
>>>>> which is why just bing a "Pure Function" isn't good enough.
>>>>>
>>>>> These issus need to be handled or acknowledged, before agreement on
>>>>> your question, as you have shown a history of taking a statement
>>>>> and twisting it (perhaps not intentionally, but because you don't
>>>>> understand what was being communicated) so we need to have a firm
>>>>> understand of what you mean and evidence that you accept the
>>>>> limititation causes by your altered definitions from the problem
>>>>> that you initially claimed to have started on.
>>>>>
>>>>> Of course, it also means that even if/when you get your agreement,
>>>>> you are no closer to your halting proof, as you have shown that you
>>>>> undestand that you conditions actually tell you NOTHING about the
>>>>> actual behavior of halting.
>>>>>
>>>>
>>>> If olcott wants to be closer to the Linz or Sipser rules, he could
>>>> do so with a small modification: use different names for H. Use H1
>>>> when called by main and use H2 when called by D. H1 and H2 are not
>>>> required to be exact copies of each other, but only to be
>>>> functionally equivalent. By doing so, a lot of useless discussions
>>>> could be avoided.
>>>
>>> Yes, he could, but when it was proposed that we make D call its own
>>> identical copy of H, he rejected it saying it wasn't allowed.
>>>
>>> Of course, the reason it isn't allowed is that it makes his method of
>>> detecting that D calls (a copy of) H not work and his whole method
>>> falls apart, as his H just never answers.
>>
>> A copy of D crashes the libx86emu emulator unless the copy
>> is very small having less code than the full D.
>>
>
> That is very strange, unless you have configured the emulator for very
> small memory space, and that just shows a limitation to your computation
> implementation, so, you are just admitting that you tools can't handle
> the logic system.
>
No need for that once we are have mutual agreement on H/D
getting mutual agreement on embedded_H / ⟨Ĥ⟩ is isomorphic.
I can explicitly show that your idea of D correctly simulated
by pure function H IS WRONG.
Once you agree to these easily verified facts we can move on to
the Linz proof having the acceptance of the H/D proof as the basis
for moving on.
If you want to keep insisting that D correctly simulated by pure
function H requires the x86 instructions of D or H to be incorrectly
emulated or emulated in the wrong order then we must get though this
first.
Paraphrase:
Your latest ruse is that a non-halting computation must simulated
to its non existent end.
--
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-24 18:18 -0400 |
| Message-ID | <v2r3mr$1vblq$8@i2pn2.org> |
| In reply to | #105471 |
On 5/24/24 5:35 PM, olcott wrote:
> On 5/24/2024 4:03 PM, Richard Damon wrote:
>> On 5/24/24 3:52 PM, olcott wrote:
>>> On 5/24/2024 6:14 AM, Richard Damon wrote:
>>>> On 5/24/24 6:46 AM, Fred. Zwarts wrote:
>>>>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>>>>> On 5/23/24 1:04 PM, 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 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.
>>>>>>>
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> By your definiton of "Correct Simulation", you do realize that you
>>>>>> have broken connection between the simulaiton not completing and
>>>>>> the program described by the input not halting?
>>>>>>
>>>>>> Also, you do realize that by your requirement on H just being a
>>>>>> "pure function" that does NOT say that you H qualified to be the
>>>>>> computational equivalent for a Turing Machine?
>>>>>>
>>>>>> That due to your "strange" definition of what D is, you are
>>>>>> putting yourself outside of the grounds of "Computation Theory",
>>>>>> as that deals with the behavior of specific PROGRAMS, and not the
>>>>>> "Program Templates" like your D, our the "Infinite set of H/D pairs"?
>>>>>>
>>>>>> Also, your "templagte D" is NOT built per either the Linz or
>>>>>> Sipser rules, as both of those had D built with a COPY of H, which
>>>>>> is one of your problems with a "Pure Function" as the equivelent.
>>>>>> You have shown that your H fails to meet the requirements of a
>>>>>> Turing Machine equivalent, as you can't (or it seems you can't)
>>>>>> make equivalent copies, where all copies always give the same
>>>>>> answer for the same inputs. This is a fundamental property of
>>>>>> Turing Machines, which is why just bing a "Pure Function" isn't
>>>>>> good enough.
>>>>>>
>>>>>> These issus need to be handled or acknowledged, before agreement
>>>>>> on your question, as you have shown a history of taking a
>>>>>> statement and twisting it (perhaps not intentionally, but because
>>>>>> you don't understand what was being communicated) so we need to
>>>>>> have a firm understand of what you mean and evidence that you
>>>>>> accept the limititation causes by your altered definitions from
>>>>>> the problem that you initially claimed to have started on.
>>>>>>
>>>>>> Of course, it also means that even if/when you get your agreement,
>>>>>> you are no closer to your halting proof, as you have shown that
>>>>>> you undestand that you conditions actually tell you NOTHING about
>>>>>> the actual behavior of halting.
>>>>>>
>>>>>
>>>>> If olcott wants to be closer to the Linz or Sipser rules, he could
>>>>> do so with a small modification: use different names for H. Use H1
>>>>> when called by main and use H2 when called by D. H1 and H2 are not
>>>>> required to be exact copies of each other, but only to be
>>>>> functionally equivalent. By doing so, a lot of useless discussions
>>>>> could be avoided.
>>>>
>>>> Yes, he could, but when it was proposed that we make D call its own
>>>> identical copy of H, he rejected it saying it wasn't allowed.
>>>>
>>>> Of course, the reason it isn't allowed is that it makes his method
>>>> of detecting that D calls (a copy of) H not work and his whole
>>>> method falls apart, as his H just never answers.
>>>
>>> A copy of D crashes the libx86emu emulator unless the copy
>>> is very small having less code than the full D.
>>>
>>
>> That is very strange, unless you have configured the emulator for very
>> small memory space, and that just shows a limitation to your
>> computation implementation, so, you are just admitting that you tools
>> can't handle the logic system.
>>
>
> No need for that once we are have mutual agreement on H/D
> getting mutual agreement on embedded_H / ⟨Ĥ⟩ is isomorphic.
But sincd they aren't, we can't.
First note, nothing you have actually implemented has an "embedded_H" as
your D just calls H and not a copy of it.
>
> I can explicitly show that your idea of D correctly simulated
> by pure function H IS WRONG.
The do so.
>
> Once you agree to these easily verified facts we can move on to
> the Linz proof having the acceptance of the H/D proof as the basis
> for moving on.
But until you actually post agreement to the terms, we can't move to there.
>
> If you want to keep insisting that D correctly simulated by pure
> function H requires the x86 instructions of D or H to be incorrectly
> emulated or emulated in the wrong order then we must get though this
> first.
I never said that, so you are proving yourself to be a LIAR, which is
why I am insisting on your agreement to a precise definition, with an
acceptance of the consequence of the terms.
Try to show where I said H needs to "incorrectly" simulate the input. I
am saying that to make the conclusion you want to make, the simulaiton
needs to meet all of your requirements, PLUS the fact that it must
continue to seeing the final state, or never halt.
If THAT simulation never halts, then you can conclude that the input
doesn't halt.
>
> Paraphrase:
> Your latest ruse is that a non-halting computation must simulated
> to its non existent end.
>
Which is, like typical for you, paraphrased poorly due to you lack of
understanding. What I am actually saying is that to show that a
computation being simulated is non-halting, you must show that the
correct simulation, of that exact input, which doesn't stop until it
reaches a final state, would be non-haltign.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-24 12:06 -0500 |
| Message-ID | <v2qhef$2dpfr$4@dont-email.me> |
| In reply to | #105448 |
On 5/24/2024 5:46 AM, Fred. Zwarts wrote:
> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>> On 5/23/24 1:04 PM, 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 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.
>>>
>>
>> Questions:
>>
>> By your definiton of "Correct Simulation", you do realize that you
>> have broken connection between the simulaiton not completing and the
>> program described by the input not halting?
>>
>> Also, you do realize that by your requirement on H just being a "pure
>> function" that does NOT say that you H qualified to be the
>> computational equivalent for a Turing Machine?
>>
>> That due to your "strange" definition of what D is, you are putting
>> yourself outside of the grounds of "Computation Theory", as that deals
>> with the behavior of specific PROGRAMS, and not the "Program
>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>
>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>> rules, as both of those had D built with a COPY of H, which is one of
>> your problems with a "Pure Function" as the equivelent. You have shown
>> that your H fails to meet the requirements of a Turing Machine
>> equivalent, as you can't (or it seems you can't) make equivalent
>> copies, where all copies always give the same answer for the same
>> inputs. This is a fundamental property of Turing Machines, which is
>> why just bing a "Pure Function" isn't good enough.
>>
>> These issus need to be handled or acknowledged, before agreement on
>> your question, as you have shown a history of taking a statement and
>> twisting it (perhaps not intentionally, but because you don't
>> understand what was being communicated) so we need to have a firm
>> understand of what you mean and evidence that you accept the
>> limititation causes by your altered definitions from the problem that
>> you initially claimed to have started on.
>>
>> Of course, it also means that even if/when you get your agreement, you
>> are no closer to your halting proof, as you have shown that you
>> undestand that you conditions actually tell you NOTHING about the
>> actual behavior of halting.
>>
>
> If olcott wants to be closer to the Linz or Sipser rules, he could do so
> with a small modification: use different names for H. Use H1 when called
> by main and use H2 when called by D. H1 and H2 are not required to be
> exact copies of each other, but only to be functionally equivalent. By
> doing so, a lot of useless discussions could be avoided.
*That violates this*
For any program H that might determine whether programs halt, a
"pathological" program D, called with some input, can pass its own
source and its input to H and then specifically do the opposite of what
H predicts D will do. No H can exist that handles this case.
https://en.wikipedia.org/wiki/Halting_problem
--
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-24 13:25 -0400 |
| Message-ID | <v2qihr$1vblq$3@i2pn2.org> |
| In reply to | #105452 |
On 5/24/24 1:06 PM, olcott wrote:
> On 5/24/2024 5:46 AM, Fred. Zwarts wrote:
>> Op 24.mei.2024 om 03:44 schreef Richard Damon:
>>> On 5/23/24 1:04 PM, 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 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.
>>>>
>>>
>>> Questions:
>>>
>>> By your definiton of "Correct Simulation", you do realize that you
>>> have broken connection between the simulaiton not completing and the
>>> program described by the input not halting?
>>>
>>> Also, you do realize that by your requirement on H just being a "pure
>>> function" that does NOT say that you H qualified to be the
>>> computational equivalent for a Turing Machine?
>>>
>>> That due to your "strange" definition of what D is, you are putting
>>> yourself outside of the grounds of "Computation Theory", as that
>>> deals with the behavior of specific PROGRAMS, and not the "Program
>>> Templates" like your D, our the "Infinite set of H/D pairs"?
>>>
>>> Also, your "templagte D" is NOT built per either the Linz or Sipser
>>> rules, as both of those had D built with a COPY of H, which is one of
>>> your problems with a "Pure Function" as the equivelent. You have
>>> shown that your H fails to meet the requirements of a Turing Machine
>>> equivalent, as you can't (or it seems you can't) make equivalent
>>> copies, where all copies always give the same answer for the same
>>> inputs. This is a fundamental property of Turing Machines, which is
>>> why just bing a "Pure Function" isn't good enough.
>>>
>>> These issus need to be handled or acknowledged, before agreement on
>>> your question, as you have shown a history of taking a statement and
>>> twisting it (perhaps not intentionally, but because you don't
>>> understand what was being communicated) so we need to have a firm
>>> understand of what you mean and evidence that you accept the
>>> limititation causes by your altered definitions from the problem that
>>> you initially claimed to have started on.
>>>
>>> Of course, it also means that even if/when you get your agreement,
>>> you are no closer to your halting proof, as you have shown that you
>>> undestand that you conditions actually tell you NOTHING about the
>>> actual behavior of halting.
>>>
>>
>> If olcott wants to be closer to the Linz or Sipser rules, he could do
>> so with a small modification: use different names for H. Use H1 when
>> called by main and use H2 when called by D. H1 and H2 are not required
>> to be exact copies of each other, but only to be functionally
>> equivalent. By doing so, a lot of useless discussions could be avoided.
>
> *That violates this*
> For any program H that might determine whether programs halt, a
> "pathological" program D, called with some input, can pass its own
> source and its input to H and then specifically do the opposite of what
> H predicts D will do. No H can exist that handles this case.
> https://en.wikipedia.org/wiki/Halting_problem
>
Nope, D, that pathological program, is supposed to be built with its own
COPY of the decider, since to BE a program, it needs a complete source set.
Since your curreent defined program envionment (incorrectly) mixes the
address and name space of the program being decided on and the decider,
the act of making a copy will entail giving the copy a new name.
Then we can pass to your decider H, the COMPLETE source code for the
progrma D, INCLUDING its copy of the decider, which has been given a new
name to handle your error of putting them into a common name space.
Since in the actual problem, the decider is given just the description
of the program to decide, and that doesn't need to be "compiled" into
its namespace, but can just be interpreted in its own environment, there
is no need for the renaming.
And, as the article says, it has been shown impossible to do that, so if
you want to refute that, you need to recreate EXACTLY what it describes,
and show how you get the right answer.
Changing the definition of the problem doesn't show a refutation of the
origianal problem.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.theory
csiph-web