Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.logic > #333458 > unrolled thread
| Started by | olcott <polcott333@gmail.com> |
|---|---|
| First post | 2024-04-27 19:17 -0500 |
| Last post | 2024-05-02 00:15 -0400 |
| Articles | 20 on this page of 171 — 5 participants |
Back to article view | Back to sci.logic
Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 19:17 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 20:49 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 19:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 21:39 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 20:54 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 22:09 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 21:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-27 23:31 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-27 22:45 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 09:13 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:45 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 10:00 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 09:15 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 13:34 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 12:55 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:18 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:23 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:42 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 14:06 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 15:29 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 14:43 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 19:07 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 17:28 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-28 19:01 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-28 23:07 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-29 07:25 -0400
Re: Can D simulated by H terminate normally? POE olcott <polcott333@gmail.com> - 2024-04-29 09:47 -0500
Re: Can D simulated by H terminate normally? POE Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:44 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:00 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:14 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:06 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 09:14 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 08:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 11:08 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 10:33 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 12:08 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 12:50 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:06 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:19 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 14:39 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:52 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:18 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:26 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:36 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:48 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 19:05 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 22:48 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 07:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 01:07 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 07:33 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:55 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 22:56 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:11 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:10 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 21:59 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:50 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:02 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:06 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:13 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:17 -0400
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-18 09:11 -0400
Re: Can D simulated by H terminate normally? --- Message-ID provided olcott <polcott333@gmail.com> - 2024-05-18 11:24 -0500
Re: Can D simulated by H terminate normally? --- Message-ID provided Richard Damon <richard@damon-family.org> - 2024-05-18 12:49 -0400
Re: Can D simulated by H terminate normally? --- Message-ID provided olcott <polcott333@gmail.com> - 2024-05-18 12:20 -0500
Re: Can D simulated by H terminate normally? --- Message-ID provided Richard Damon <richard@damon-family.org> - 2024-05-18 13:40 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 13:54 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:15 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:24 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:42 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:18 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:28 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 15:42 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 14:57 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 16:02 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 16:00 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 18:22 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 17:44 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 19:06 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 18:24 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-18 19:38 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-18 22:59 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-19 14:16 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 08:06 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 06:37 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 00:17 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 10:37 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 10:32 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 13:17 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 08:14 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 13:17 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-20 11:01 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 10:18 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 13:17 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-19 14:46 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-19 19:31 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-20 13:28 -0500
Re: Can D simulated by H terminate normally? --- Message_ID Provided Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? --- Message_ID Provided immibis <news@immibis.com> - 2024-05-21 06:50 +0200
Re: Can D simulated by H terminate normally? --- Message_ID Provided olcott <polcott333@gmail.com> - 2024-05-21 00:05 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-19 19:06 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-19 21:10 -0400
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-19 21:52 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-19 23:11 -0400
Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:22 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 13:03 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 21:25 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 22:39 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 00:18 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 08:03 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 09:22 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 21:46 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 21:05 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-21 23:09 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-21 22:52 -0500
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-22 07:48 -0400
Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt "Fred. Zwarts" <F.Zwarts@HetNet.nl> - 2024-05-22 09:52 +0200
Re: Every D correctly simulated by H remains stuck in recursive simulation olcott <polcott333@gmail.com> - 2024-05-22 21:15 -0500
Re: Every D correctly simulated by H remains stuck in recursive simulation Richard Damon <richard@damon-family.org> - 2024-05-22 22:36 -0400
Re: Can D simulated by H terminate normally? Message_ID Provided V2 immibis <news@immibis.com> - 2024-05-20 13:31 +0200
Re: Can D simulated by H terminate normally? Message_ID Provided V2 olcott <polcott333@gmail.com> - 2024-05-20 10:23 -0500
Re: Can D simulated by H terminate normally? Message_ID Provided V2 Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:09 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-19 23:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-19 22:32 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 07:24 -0400
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt olcott <polcott333@gmail.com> - 2024-05-20 13:01 -0500
Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt Richard Damon <richard@damon-family.org> - 2024-05-20 20:57 -0400
Re: Can D simulated by H terminate normally? Alan Mackenzie <acm@muc.de> - 2024-04-29 14:37 +0000
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-05 12:38 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-05 14:15 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-06 11:02 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-06 22:20 -0400
Is Richard a Liar? olcott <polcott333@gmail.com> - 2024-05-14 10:42 -0500
Re: Olcott is a Liar! Richard Damon <richard@damon-family.org> - 2024-05-14 22:15 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:54 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 13:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:25 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:35 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 15:45 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 14:51 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-28 19:07 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-28 22:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 07:24 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-29 09:43 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-29 19:19 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 00:54 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 07:40 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 10:58 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-04-30 18:46 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-04-30 23:11 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 07:23 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 11:06 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 20:41 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 22:29 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-01 23:59 -0400
Re: Can D simulated by H terminate normally? olcott <polcott333@gmail.com> - 2024-05-01 23:09 -0500
Re: Can D simulated by H terminate normally? Richard Damon <richard@damon-family.org> - 2024-05-02 00:15 -0400
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-05-20 11:01 +0200 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2f3h9$3tefa$2@dont-email.me> |
| In reply to | #334351 |
On 19/05/24 15:14, olcott wrote:
> On 5/19/2024 7:16 AM, immibis wrote:
>> On 19/05/24 05:59, olcott wrote:
>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>
>>>>>>>>> Nice try but this has no effect on any D correctly simulated by H.
>>>>>>>>> When the directly executed H aborts its simulation it only returns
>>>>>>>>> to whatever directly executed it.
>>>>>>>>
>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>
>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>> the inner simulated ones abort because they are the exact same
>>>>>>>>> code.
>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>> return
>>>>>>>>> to its own caller.
>>>>>>>>
>>>>>>>> WHAT inner simulatioin?
>>>>>>>>
>>>>>>>>
>>>>>>>> My H begins as:
>>>>>>>>
>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>> static int flag = 0;
>>>>>>>> if(flag) return 0;
>>>>>>>> flag = 1;
>>>>>>>>
>>>>>>>> followed by essentially your code for H, except that you need to
>>>>>>>> disable the hack that doesn't simulate the call to H, but just
>>>>>>>> let it continue into H where it will immediately return to D and
>>>>>>>> D will then return.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>
>>>>>>>
>>>>>>> We are talking about every element of an infinite set where
>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>
>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>
>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>> reach the final state.
>>>>>
>>>>> *Show the error in my execution trace that I empirically*
>>>>> *proved has no error by H correctly simulating D to the*
>>>>> *point where H correctly simulates itself simulating D*
>>>>> (Fully operational empirically code proved this)
>>>>
>>>> See below:
>>>>
>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>> 00 int H(ptr x, ptr y);
>>>>> 01 int D(ptr x)
>>>>> 02 {
>>>>> 03 int Halt_Status = H(x, x);
>>>>> 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 }
>>>>
>>>> For Reference
>>>>
>>>> 14 int H(ptr x, ptr y)
>>>> 15 {
>>>> 16 static int flag = 0
>>>> 17 if (flag)
>>>> 18 return 0
>>>> 19 ... continuation of H that simulates its input
>>>>
>>>>>
>>>>> In the above case 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);
>>>>>
>>>>> keeps repeating (unless aborted)
>>>>> Line 01
>>>>> Line 02
>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>
>>>> Line 03: Calls H (line 14)
>>>> Line 16: Static already inited, so not changed.
>>>> Line 17: Flag is 1, so
>>>> Line 18: Return 0
>>>> Line 03: Set Halt_Status to 0
>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>> Line 06: return Halt_Status
>>>>
>>>> Simulation completed, program halted.
>>>>
>>>>
>>>>>
>>>>> Simulation invariant:
>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>
>>>>>
>>>>
>>>> Nope. Not for this H
>>>>
>>>>
>>>
>>> (a) That idea might work yet you did not say it correctly.
>>> For example line 11 is the first one invoked.
>>> (b) Computable functions cannot alter their behavior this way.
>>>
>>> (1) the function return values are identical for identical arguments (no
>>> variation with local static variables, non-local variables, mutable
>>> reference arguments or input streams, i.e., referential
>>> transparency), and
>>
>> Your function H works like Richard's function H. You just called the
>> variable "execution trace" instead of "flag".
>
> Since Richard did not respond to this post I am taking that
> as he understands that he is incorrect.
>
> He has known this whole time that we having only been talking
> about computable functions. Thus he knows his example using
> static data is no good.
>
But the function H that you wrote also uses static data.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 10:18 -0500 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2fpji$1pfh$5@dont-email.me> |
| In reply to | #334387 |
On 5/20/2024 4:01 AM, immibis wrote:
> On 19/05/24 15:14, olcott wrote:
>> On 5/19/2024 7:16 AM, immibis wrote:
>>> On 19/05/24 05:59, olcott wrote:
>>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>>
>>>>>>>>>> Nice try but this has no effect on any D correctly simulated
>>>>>>>>>> by H.
>>>>>>>>>> When the directly executed H aborts its simulation it only
>>>>>>>>>> returns
>>>>>>>>>> to whatever directly executed it.
>>>>>>>>>
>>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>>
>>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>>> the inner simulated ones abort because they are the exact same
>>>>>>>>>> code.
>>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>>> return
>>>>>>>>>> to its own caller.
>>>>>>>>>
>>>>>>>>> WHAT inner simulatioin?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My H begins as:
>>>>>>>>>
>>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>>> static int flag = 0;
>>>>>>>>> if(flag) return 0;
>>>>>>>>> flag = 1;
>>>>>>>>>
>>>>>>>>> followed by essentially your code for H, except that you need
>>>>>>>>> to disable the hack that doesn't simulate the call to H, but
>>>>>>>>> just let it continue into H where it will immediately return to
>>>>>>>>> D and D will then return.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We are talking about every element of an infinite set where
>>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>>
>>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>>
>>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>>> reach the final state.
>>>>>>
>>>>>> *Show the error in my execution trace that I empirically*
>>>>>> *proved has no error by H correctly simulating D to the*
>>>>>> *point where H correctly simulates itself simulating D*
>>>>>> (Fully operational empirically code proved this)
>>>>>
>>>>> See below:
>>>>>
>>>>>
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 00 int H(ptr x, ptr y);
>>>>>> 01 int D(ptr x)
>>>>>> 02 {
>>>>>> 03 int Halt_Status = H(x, x);
>>>>>> 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 }
>>>>>
>>>>> For Reference
>>>>>
>>>>> 14 int H(ptr x, ptr y)
>>>>> 15 {
>>>>> 16 static int flag = 0
>>>>> 17 if (flag)
>>>>> 18 return 0
>>>>> 19 ... continuation of H that simulates its input
>>>>>
>>>>>>
>>>>>> In the above case 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);
>>>>>>
>>>>>> keeps repeating (unless aborted)
>>>>>> Line 01
>>>>>> Line 02
>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> Line 03: Calls H (line 14)
>>>>> Line 16: Static already inited, so not changed.
>>>>> Line 17: Flag is 1, so
>>>>> Line 18: Return 0
>>>>> Line 03: Set Halt_Status to 0
>>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>>> Line 06: return Halt_Status
>>>>>
>>>>> Simulation completed, program halted.
>>>>>
>>>>>
>>>>>>
>>>>>> Simulation invariant:
>>>>>> D correctly simulated by H cannot possibly reach past its own line
>>>>>> 03.
>>>>>>
>>>>>>
>>>>>
>>>>> Nope. Not for this H
>>>>>
>>>>>
>>>>
>>>> (a) That idea might work yet you did not say it correctly.
>>>> For example line 11 is the first one invoked.
>>>> (b) Computable functions cannot alter their behavior this way.
>>>>
>>>> (1) the function return values are identical for identical arguments
>>>> (no
>>>> variation with local static variables, non-local variables, mutable
>>>> reference arguments or input streams, i.e., referential
>>>> transparency), and
>>>
>>> Your function H works like Richard's function H. You just called the
>>> variable "execution trace" instead of "flag".
>>
>> Since Richard did not respond to this post I am taking that
>> as he understands that he is incorrect.
>>
>> He has known this whole time that we having only been talking
>> about computable functions. Thus he knows his example using
>> static data is no good.
>>
> But the function H that you wrote also uses static data.
I am talking about a hypothetical function that does not
use static data. My current H does not use static data.
--
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-20 20:57 -0400 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2gri5$1kiah$11@i2pn2.org> |
| In reply to | #334393 |
On 5/20/24 11:18 AM, olcott wrote:
> On 5/20/2024 4:01 AM, immibis wrote:
>> On 19/05/24 15:14, olcott wrote:
>>> On 5/19/2024 7:16 AM, immibis wrote:
>>>> On 19/05/24 05:59, olcott wrote:
>>>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>>>
>>>>>>>>>>> Nice try but this has no effect on any D correctly simulated
>>>>>>>>>>> by H.
>>>>>>>>>>> When the directly executed H aborts its simulation it only
>>>>>>>>>>> returns
>>>>>>>>>>> to whatever directly executed it.
>>>>>>>>>>
>>>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>>>> the inner simulated ones abort because they are the exact
>>>>>>>>>>> same code.
>>>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>>>> return
>>>>>>>>>>> to its own caller.
>>>>>>>>>>
>>>>>>>>>> WHAT inner simulatioin?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My H begins as:
>>>>>>>>>>
>>>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>>>> static int flag = 0;
>>>>>>>>>> if(flag) return 0;
>>>>>>>>>> flag = 1;
>>>>>>>>>>
>>>>>>>>>> followed by essentially your code for H, except that you need
>>>>>>>>>> to disable the hack that doesn't simulate the call to H, but
>>>>>>>>>> just let it continue into H where it will immediately return
>>>>>>>>>> to D and D will then return.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are talking about every element of an infinite set where
>>>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>>>
>>>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>>>
>>>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>>>> reach the final state.
>>>>>>>
>>>>>>> *Show the error in my execution trace that I empirically*
>>>>>>> *proved has no error by H correctly simulating D to the*
>>>>>>> *point where H correctly simulates itself simulating D*
>>>>>>> (Fully operational empirically code proved this)
>>>>>>
>>>>>> See below:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> 00 int H(ptr x, ptr y);
>>>>>>> 01 int D(ptr x)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = H(x, x);
>>>>>>> 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 }
>>>>>>
>>>>>> For Reference
>>>>>>
>>>>>> 14 int H(ptr x, ptr y)
>>>>>> 15 {
>>>>>> 16 static int flag = 0
>>>>>> 17 if (flag)
>>>>>> 18 return 0
>>>>>> 19 ... continuation of H that simulates its input
>>>>>>
>>>>>>>
>>>>>>> In the above case 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);
>>>>>>>
>>>>>>> keeps repeating (unless aborted)
>>>>>>> Line 01
>>>>>>> Line 02
>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> Line 03: Calls H (line 14)
>>>>>> Line 16: Static already inited, so not changed.
>>>>>> Line 17: Flag is 1, so
>>>>>> Line 18: Return 0
>>>>>> Line 03: Set Halt_Status to 0
>>>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>>>> Line 06: return Halt_Status
>>>>>>
>>>>>> Simulation completed, program halted.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Simulation invariant:
>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nope. Not for this H
>>>>>>
>>>>>>
>>>>>
>>>>> (a) That idea might work yet you did not say it correctly.
>>>>> For example line 11 is the first one invoked.
>>>>> (b) Computable functions cannot alter their behavior this way.
>>>>>
>>>>> (1) the function return values are identical for identical
>>>>> arguments (no
>>>>> variation with local static variables, non-local variables, mutable
>>>>> reference arguments or input streams, i.e., referential
>>>>> transparency), and
>>>>
>>>> Your function H works like Richard's function H. You just called the
>>>> variable "execution trace" instead of "flag".
>>>
>>> Since Richard did not respond to this post I am taking that
>>> as he understands that he is incorrect.
>>>
>>> He has known this whole time that we having only been talking
>>> about computable functions. Thus he knows his example using
>>> static data is no good.
>>>
>> But the function H that you wrote also uses static data.
>
> I am talking about a hypothetical function that does not
> use static data. My current H does not use static data.
>
But you H gets the wrong answer, which you even admit. You have admitted
that D(D) WILL Halt when run, and since that is the DEFINITION of the
right answer to the Halting Problem, you H can not be a correct Halt
Decider.
All you are doing seems to be trying to come up with a worthless
alternate problem, your POOP, and showing that POOP can answer for one
particular machine by just defining that POOP defines the answer to what
H gives.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <richard@damon-family.org> |
|---|---|
| Date | 2024-05-19 13:17 -0400 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2dc7e$1g2n9$6@i2pn2.org> |
| In reply to | #334346 |
On 5/18/24 11:59 PM, olcott wrote:
> On 5/18/2024 6:38 PM, Richard Damon wrote:
>> On 5/18/24 7:24 PM, olcott wrote:
>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>> simulating, and if a call to H shows that it is currently doing
>>>>>>>> a simulation, just immediately return 0.
>>>>>>>
>>>>>>> Nice try but this has no effect on any D correctly simulated by H.
>>>>>>> When the directly executed H aborts its simulation it only returns
>>>>>>> to whatever directly executed it.
>>>>>>
>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>
>>>>>> You don't seem to understand how the C code actually works.
>>>>>>
>>>>>>>
>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>> the inner simulated ones abort because they are the exact same code.
>>>>>>> When the directly executed outermost H does abort it can only return
>>>>>>> to its own caller.
>>>>>>
>>>>>> WHAT inner simulatioin?
>>>>>>
>>>>>>
>>>>>> My H begins as:
>>>>>>
>>>>>> int H(ptr x, ptr y) {
>>>>>> static int flag = 0;
>>>>>> if(flag) return 0;
>>>>>> flag = 1;
>>>>>>
>>>>>> followed by essentially your code for H, except that you need to
>>>>>> disable the hack that doesn't simulate the call to H, but just let
>>>>>> it continue into H where it will immediately return to D and D
>>>>>> will then return.
>>>>>>
>>>>>>
>>>>>> Thus, your claim is shown to be wrong.
>>>>>>
>>>>>
>>>>> We are talking about every element of an infinite set where
>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>> recursive simulations of H simulating itself simulating D.
>>>>>
>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>> *its input it cannot possibly return to any simulated input*
>>>>
>>>> And my H never stops simulating, so that doesn't apply. It will
>>>> reach the final state.
>>>
>>> *Show the error in my execution trace that I empirically*
>>> *proved has no error by H correctly simulating D to the*
>>> *point where H correctly simulates itself simulating D*
>>> (Fully operational empirically code proved this)
>>
>> See below:
>>
>>
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> 00 int H(ptr x, ptr y);
>>> 01 int D(ptr x)
>>> 02 {
>>> 03 int Halt_Status = H(x, x);
>>> 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 }
>>
>> For Reference
>>
>> 14 int H(ptr x, ptr y)
>> 15 {
>> 16 static int flag = 0
>> 17 if (flag)
>> 18 return 0
>> 19 ... continuation of H that simulates its input
>>
>>>
>>> In the above case 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);
>>>
>>> keeps repeating (unless aborted)
>>> Line 01
>>> Line 02
>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>
>> Line 03: Calls H (line 14)
>> Line 16: Static already inited, so not changed.
>> Line 17: Flag is 1, so
>> Line 18: Return 0
>> Line 03: Set Halt_Status to 0
>> Line 04: if (Halt_Status) halts status is 0, so skip
>> Line 06: return Halt_Status
>>
>> Simulation completed, program halted.
>>
>>
>>>
>>> Simulation invariant:
>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>
>>>
>>
>> Nope. Not for this H
>>
>>
>
> (a) That idea might work yet you did not say it correctly.
> For example line 11 is the first one invoked.
No, I was showing what happens INSTEAD of your last line 03.
Are you so stupid that you need everything just fully explained to you?
> (b) Computable functions cannot alter their behavior this way.
But C programs are NOT "Computable Functions", they might be the example
to prove that a Functions is computable, but they are not "Computable
Functions" themselves, as "Computable Functions" are a sub-type of the
Mathematical concept of a "Function", which in this context, is a
mathematical mapping of input values to outputs.
A program, like H, isn't itself a mapping, but produces as a semantic
property of itself such a mapping, which if it matches the Function
being looked at, shows that function is computable.
This sort of error by you just show how mis-learned by rote your
knowledge base is. You just don't understand the meaning of many of the
words you use, cause you to make just plain dumb errors.
Note also, your requirements were never listed as such, when asked, you
said that the source code given was the sole definition, and H just
needed to be a C program that simulated its input.
>
> (1) the function return values are identical for identical arguments (no
> variation with local static variables, non-local variables, mutable
> reference arguments or input streams, i.e., referential transparency), and
SO, YOU H fails to meet that, since we have that H(D,D) returns 0 when
called by main, but you logic says that H(D,D) when called by D(D) never
returns. This is one of the reasons you seemed to have dropped back from
H being a "Turing Equivant" to Linz's H, because you do logic that
doesn't work with that limitation.
And, your stated requirements on H did not say it needed to be a "pure
function", just that it was a "C program".
Note, if you want to add the requirement that H MUST be a "pure
function", then the only correct determination of the behavior of a
function is its actual behavior, which means your H that determines that
H doesn't return is just wrong, since it does.
Aborted partial simulation, especially of a DIFFERENT input (using an H
other than the H that the D given to the H in question actually calls).
>
> (2) the function has no side effects (no mutation of local static
> variables, non-local variables, mutable reference arguments or
> input/output streams).
> https://en.wikipedia.org/wiki/Pure_function
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-19 14:46 -0500 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2dkuu$3hgb1$2@dont-email.me> |
| In reply to | #334359 |
On 5/19/2024 12:17 PM, Richard Damon wrote:
> On 5/18/24 11:59 PM, olcott wrote:
>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>> On 5/18/24 7:24 PM, olcott wrote:
>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>> simulating, and if a call to H shows that it is currently doing
>>>>>>>>> a simulation, just immediately return 0.
>>>>>>>>
>>>>>>>> Nice try but this has no effect on any D correctly simulated by H.
>>>>>>>> When the directly executed H aborts its simulation it only returns
>>>>>>>> to whatever directly executed it.
>>>>>>>
>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>
>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>
>>>>>>>>
>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>> the inner simulated ones abort because they are the exact same
>>>>>>>> code.
>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>> return
>>>>>>>> to its own caller.
>>>>>>>
>>>>>>> WHAT inner simulatioin?
>>>>>>>
>>>>>>>
>>>>>>> My H begins as:
>>>>>>>
>>>>>>> int H(ptr x, ptr y) {
>>>>>>> static int flag = 0;
>>>>>>> if(flag) return 0;
>>>>>>> flag = 1;
>>>>>>>
>>>>>>> followed by essentially your code for H, except that you need to
>>>>>>> disable the hack that doesn't simulate the call to H, but just
>>>>>>> let it continue into H where it will immediately return to D and
>>>>>>> D will then return.
>>>>>>>
>>>>>>>
>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>
>>>>>>
>>>>>> We are talking about every element of an infinite set where
>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>
>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>
>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>> reach the final state.
>>>>
>>>> *Show the error in my execution trace that I empirically*
>>>> *proved has no error by H correctly simulating D to the*
>>>> *point where H correctly simulates itself simulating D*
>>>> (Fully operational empirically code proved this)
>>>
>>> See below:
>>>
>>>
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>> 00 int H(ptr x, ptr y);
>>>> 01 int D(ptr x)
>>>> 02 {
>>>> 03 int Halt_Status = H(x, x);
>>>> 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 }
>>>
>>> For Reference
>>>
>>> 14 int H(ptr x, ptr y)
>>> 15 {
>>> 16 static int flag = 0
>>> 17 if (flag)
>>> 18 return 0
>>> 19 ... continuation of H that simulates its input
>>>
>>>>
>>>> In the above case 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);
>>>>
>>>> keeps repeating (unless aborted)
>>>> Line 01
>>>> Line 02
>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>
>>> Line 03: Calls H (line 14)
>>> Line 16: Static already inited, so not changed.
>>> Line 17: Flag is 1, so
>>> Line 18: Return 0
>>> Line 03: Set Halt_Status to 0
>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>> Line 06: return Halt_Status
>>>
>>> Simulation completed, program halted.
>>>
>>>
>>>>
>>>> Simulation invariant:
>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>
>>>>
>>>
>>> Nope. Not for this H
>>>
>>>
>>
>> (a) That idea might work yet you did not say it correctly.
>> For example line 11 is the first one invoked.
>
>
> No, I was showing what happens INSTEAD of your last line 03.
>
> Are you so stupid that you need everything just fully explained to you?
>
*You just admitted that you thought that lying is OK because*
*I did not specifically say that I expect correct answers*
On 5/19/2024 12:17 PM, Richard Damon wrote:
> On 5/19/24 9:59 AM, olcott wrote:
>> Richard has stated that he thinks that an example of
>> {D never simulated by H} ∈ {every D simulated by H}
>
> No, the H that didn't simulate its input shows that
> *once you allow H to not be required to be correct*,
> that we can then have a trivial function that is
> "just as correct" (since wrong answers were allowed).
>
>>
>> On 5/1/2024 7:28 PM, Richard Damon wrote:
>> Message-ID: <v0ummt$2qov3$2@i2pn2.org>
>>
http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv0ummt%242qov3%242%40i2pn2.org%3E
--
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-19 19:31 -0400 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2e24h$1g2n8$8@i2pn2.org> |
| In reply to | #334366 |
On 5/19/24 3:46 PM, olcott wrote:
> On 5/19/2024 12:17 PM, Richard Damon wrote:
>> On 5/18/24 11:59 PM, olcott wrote:
>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>
>>>>>>>>> Nice try but this has no effect on any D correctly simulated by H.
>>>>>>>>> When the directly executed H aborts its simulation it only returns
>>>>>>>>> to whatever directly executed it.
>>>>>>>>
>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>
>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>> the inner simulated ones abort because they are the exact same
>>>>>>>>> code.
>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>> return
>>>>>>>>> to its own caller.
>>>>>>>>
>>>>>>>> WHAT inner simulatioin?
>>>>>>>>
>>>>>>>>
>>>>>>>> My H begins as:
>>>>>>>>
>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>> static int flag = 0;
>>>>>>>> if(flag) return 0;
>>>>>>>> flag = 1;
>>>>>>>>
>>>>>>>> followed by essentially your code for H, except that you need to
>>>>>>>> disable the hack that doesn't simulate the call to H, but just
>>>>>>>> let it continue into H where it will immediately return to D and
>>>>>>>> D will then return.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>
>>>>>>>
>>>>>>> We are talking about every element of an infinite set where
>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>
>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>
>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>> reach the final state.
>>>>>
>>>>> *Show the error in my execution trace that I empirically*
>>>>> *proved has no error by H correctly simulating D to the*
>>>>> *point where H correctly simulates itself simulating D*
>>>>> (Fully operational empirically code proved this)
>>>>
>>>> See below:
>>>>
>>>>
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>> 00 int H(ptr x, ptr y);
>>>>> 01 int D(ptr x)
>>>>> 02 {
>>>>> 03 int Halt_Status = H(x, x);
>>>>> 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 }
>>>>
>>>> For Reference
>>>>
>>>> 14 int H(ptr x, ptr y)
>>>> 15 {
>>>> 16 static int flag = 0
>>>> 17 if (flag)
>>>> 18 return 0
>>>> 19 ... continuation of H that simulates its input
>>>>
>>>>>
>>>>> In the above case 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);
>>>>>
>>>>> keeps repeating (unless aborted)
>>>>> Line 01
>>>>> Line 02
>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>
>>>> Line 03: Calls H (line 14)
>>>> Line 16: Static already inited, so not changed.
>>>> Line 17: Flag is 1, so
>>>> Line 18: Return 0
>>>> Line 03: Set Halt_Status to 0
>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>> Line 06: return Halt_Status
>>>>
>>>> Simulation completed, program halted.
>>>>
>>>>
>>>>>
>>>>> Simulation invariant:
>>>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>>>
>>>>>
>>>>
>>>> Nope. Not for this H
>>>>
>>>>
>>>
>>> (a) That idea might work yet you did not say it correctly.
>>> For example line 11 is the first one invoked.
>>
>>
>> No, I was showing what happens INSTEAD of your last line 03.
>>
>> Are you so stupid that you need everything just fully explained to you?
>>
>
> *You just admitted that you thought that lying is OK because*
> *I did not specifically say that I expect correct answers*
>
So you ADMIT that your H won't return the correct answer?
Your final statement is that H is CORRECT about the behavior input, by
making the decision.
If you retract that, and admit that H is just making up a story by its
answer, then you are admitting that you are working on a pure fantasy
that means absoultely nothing.
I guess every time you claim something to be "correct" we can assume
that means that it might be correct, or it might be wrong, Peter Olcott
doesn't mean anything by calling something to be "Correct"
> On 5/19/2024 12:17 PM, Richard Damon wrote:
> > On 5/19/24 9:59 AM, olcott wrote:
> >> Richard has stated that he thinks that an example of
> >> {D never simulated by H} ∈ {every D simulated by H}
> >
> > No, the H that didn't simulate its input shows that
> > *once you allow H to not be required to be correct*,
> > that we can then have a trivial function that is
> > "just as correct" (since wrong answers were allowed).
> >
> >>
> >> On 5/1/2024 7:28 PM, Richard Damon wrote:
> >> Message-ID: <v0ummt$2qov3$2@i2pn2.org>
> >>
> http://al.howardknight.net/?STYPE=msgid&MSGI=%3Cv0ummt%242qov3%242%40i2pn2.org%3E
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 13:28 -0500 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2g4nt$49kb$2@dont-email.me> |
| In reply to | #334374 |
On 5/19/2024 6:31 PM, Richard Damon wrote:
> On 5/19/24 3:46 PM, olcott wrote:
>> On 5/19/2024 12:17 PM, Richard Damon wrote:
>>> On 5/18/24 11:59 PM, olcott wrote:
>>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>>
>>>>>>>>>> Nice try but this has no effect on any D correctly simulated
>>>>>>>>>> by H.
>>>>>>>>>> When the directly executed H aborts its simulation it only
>>>>>>>>>> returns
>>>>>>>>>> to whatever directly executed it.
>>>>>>>>>
>>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>>
>>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>>> the inner simulated ones abort because they are the exact same
>>>>>>>>>> code.
>>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>>> return
>>>>>>>>>> to its own caller.
>>>>>>>>>
>>>>>>>>> WHAT inner simulatioin?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> My H begins as:
>>>>>>>>>
>>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>>> static int flag = 0;
>>>>>>>>> if(flag) return 0;
>>>>>>>>> flag = 1;
>>>>>>>>>
>>>>>>>>> followed by essentially your code for H, except that you need
>>>>>>>>> to disable the hack that doesn't simulate the call to H, but
>>>>>>>>> just let it continue into H where it will immediately return to
>>>>>>>>> D and D will then return.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>>
>>>>>>>>
>>>>>>>> We are talking about every element of an infinite set where
>>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>>
>>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>>
>>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>>> reach the final state.
>>>>>>
>>>>>> *Show the error in my execution trace that I empirically*
>>>>>> *proved has no error by H correctly simulating D to the*
>>>>>> *point where H correctly simulates itself simulating D*
>>>>>> (Fully operational empirically code proved this)
>>>>>
>>>>> See below:
>>>>>
>>>>>
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 00 int H(ptr x, ptr y);
>>>>>> 01 int D(ptr x)
>>>>>> 02 {
>>>>>> 03 int Halt_Status = H(x, x);
>>>>>> 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 }
>>>>>
>>>>> For Reference
>>>>>
>>>>> 14 int H(ptr x, ptr y)
>>>>> 15 {
>>>>> 16 static int flag = 0
>>>>> 17 if (flag)
>>>>> 18 return 0
>>>>> 19 ... continuation of H that simulates its input
>>>>>
>>>>>>
>>>>>> In the above case 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);
>>>>>>
>>>>>> keeps repeating (unless aborted)
>>>>>> Line 01
>>>>>> Line 02
>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>
>>>>> Line 03: Calls H (line 14)
>>>>> Line 16: Static already inited, so not changed.
>>>>> Line 17: Flag is 1, so
>>>>> Line 18: Return 0
>>>>> Line 03: Set Halt_Status to 0
>>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>>> Line 06: return Halt_Status
>>>>>
>>>>> Simulation completed, program halted.
>>>>>
>>>>>
>>>>>>
>>>>>> Simulation invariant:
>>>>>> D correctly simulated by H cannot possibly reach past its own line
>>>>>> 03.
>>>>>>
>>>>>>
>>>>>
>>>>> Nope. Not for this H
>>>>>
>>>>>
>>>>
>>>> (a) That idea might work yet you did not say it correctly.
>>>> For example line 11 is the first one invoked.
>>>
>>>
>>> No, I was showing what happens INSTEAD of your last line 03.
>>>
>>> Are you so stupid that you need everything just fully explained to you?
>>>
>>
>> *You just admitted that you thought that lying is OK because*
>> *I did not specifically say that I expect correct answers*
>>
>
> So you ADMIT that your H won't return the correct answer?
>
> Your final statement is that H is CORRECT about the behavior input, by
> making the decision.
*This boiler plate will be the only reply*
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.
Enlarge the category a tiny little bit and then the time
becomes infeasible.
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
--
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-20 20:57 -0400 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2gri8$1kiah$12@i2pn2.org> |
| In reply to | #334400 |
On 5/20/24 2:28 PM, olcott wrote:
> On 5/19/2024 6:31 PM, Richard Damon wrote:
>> On 5/19/24 3:46 PM, olcott wrote:
>>> On 5/19/2024 12:17 PM, Richard Damon wrote:
>>>> On 5/18/24 11:59 PM, olcott wrote:
>>>>> On 5/18/2024 6:38 PM, Richard Damon wrote:
>>>>>> On 5/18/24 7:24 PM, olcott wrote:
>>>>>>> On 5/18/2024 6:06 PM, Richard Damon wrote:
>>>>>>>> On 5/18/24 6:44 PM, olcott wrote:
>>>>>>>>> On 5/18/2024 3:02 PM, Richard Damon wrote:
>>>>>>>>>> On 5/18/24 3:57 PM, olcott wrote:
>>>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>>>> The second method uses the fact that you have not restricted
>>>>>>>>>>>> what H is allowed to do, and thus H can remember that it is
>>>>>>>>>>>> simulating, and if a call to H shows that it is currently
>>>>>>>>>>>> doing a simulation, just immediately return 0.
>>>>>>>>>>>
>>>>>>>>>>> Nice try but this has no effect on any D correctly simulated
>>>>>>>>>>> by H.
>>>>>>>>>>> When the directly executed H aborts its simulation it only
>>>>>>>>>>> returns
>>>>>>>>>>> to whatever directly executed it.
>>>>>>>>>>
>>>>>>>>>> Why? My H does correctly simulate the D it was given.
>>>>>>>>>>
>>>>>>>>>> You don't seem to understand how the C code actually works.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> If the directly executed outermost H does not abort then none of
>>>>>>>>>>> the inner simulated ones abort because they are the exact
>>>>>>>>>>> same code.
>>>>>>>>>>> When the directly executed outermost H does abort it can only
>>>>>>>>>>> return
>>>>>>>>>>> to its own caller.
>>>>>>>>>>
>>>>>>>>>> WHAT inner simulatioin?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> My H begins as:
>>>>>>>>>>
>>>>>>>>>> int H(ptr x, ptr y) {
>>>>>>>>>> static int flag = 0;
>>>>>>>>>> if(flag) return 0;
>>>>>>>>>> flag = 1;
>>>>>>>>>>
>>>>>>>>>> followed by essentially your code for H, except that you need
>>>>>>>>>> to disable the hack that doesn't simulate the call to H, but
>>>>>>>>>> just let it continue into H where it will immediately return
>>>>>>>>>> to D and D will then return.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thus, your claim is shown to be wrong.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are talking about every element of an infinite set where
>>>>>>>>> H correctly simulates 1 to ∞ steps of D thus including 0 to ∞
>>>>>>>>> recursive simulations of H simulating itself simulating D.
>>>>>>>>>
>>>>>>>>> *At whatever point the directly executed H(D,D) stops simulating*
>>>>>>>>> *its input it cannot possibly return to any simulated input*
>>>>>>>>
>>>>>>>> And my H never stops simulating, so that doesn't apply. It will
>>>>>>>> reach the final state.
>>>>>>>
>>>>>>> *Show the error in my execution trace that I empirically*
>>>>>>> *proved has no error by H correctly simulating D to the*
>>>>>>> *point where H correctly simulates itself simulating D*
>>>>>>> (Fully operational empirically code proved this)
>>>>>>
>>>>>> See below:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> 00 int H(ptr x, ptr y);
>>>>>>> 01 int D(ptr x)
>>>>>>> 02 {
>>>>>>> 03 int Halt_Status = H(x, x);
>>>>>>> 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 }
>>>>>>
>>>>>> For Reference
>>>>>>
>>>>>> 14 int H(ptr x, ptr y)
>>>>>> 15 {
>>>>>> 16 static int flag = 0
>>>>>> 17 if (flag)
>>>>>> 18 return 0
>>>>>> 19 ... continuation of H that simulates its input
>>>>>>
>>>>>>>
>>>>>>> In the above case 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);
>>>>>>>
>>>>>>> keeps repeating (unless aborted)
>>>>>>> Line 01
>>>>>>> Line 02
>>>>>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>>>>
>>>>>> Line 03: Calls H (line 14)
>>>>>> Line 16: Static already inited, so not changed.
>>>>>> Line 17: Flag is 1, so
>>>>>> Line 18: Return 0
>>>>>> Line 03: Set Halt_Status to 0
>>>>>> Line 04: if (Halt_Status) halts status is 0, so skip
>>>>>> Line 06: return Halt_Status
>>>>>>
>>>>>> Simulation completed, program halted.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Simulation invariant:
>>>>>>> D correctly simulated by H cannot possibly reach past its own
>>>>>>> line 03.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> Nope. Not for this H
>>>>>>
>>>>>>
>>>>>
>>>>> (a) That idea might work yet you did not say it correctly.
>>>>> For example line 11 is the first one invoked.
>>>>
>>>>
>>>> No, I was showing what happens INSTEAD of your last line 03.
>>>>
>>>> Are you so stupid that you need everything just fully explained to you?
>>>>
>>>
>>> *You just admitted that you thought that lying is OK because*
>>> *I did not specifically say that I expect correct answers*
>>>
>>
>> So you ADMIT that your H won't return the correct answer?
>>
>> Your final statement is that H is CORRECT about the behavior input, by
>> making the decision.
>
> *This boiler plate will be the only reply*
> I am using categorically exhaustive reasoning that can work
> through every possibility that can possibly exist in a feasible
> amount of time as long as the category is very very narrow.
>
> Enlarge the category a tiny little bit and then the time
> becomes infeasible.
>
> The tiniest little divergence from the title of this
> thread and I totally ignore and erase everything else
> that you say.
>
And you will just get the same boiler plate back. just wasting your tine.
Since you can not precisely define you "categories" or the "attribute"
you are trying to study, it is impossible to do what you claim. If you
do have a better idea that you can not express, you will be unable to
prove to others that you answer is corrret, and you are just wasting
your time by refusing to engage in actual honest dialog to resolve the
issues.
If you just die before you acheive anything, it is your own fault,
because you were stuborn and stuck to working on an impossible problem.
YOU LOSS.
[toc] | [prev] | [next] | [standalone]
| From | immibis <news@immibis.com> |
|---|---|
| Date | 2024-05-21 06:50 +0200 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2h972$ecbj$3@dont-email.me> |
| In reply to | #334400 |
On 20/05/24 20:28, olcott wrote: > *This boiler plate will be the only reply* You know that we ignore your boiler plate, right?
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-21 00:05 -0500 |
| Subject | Re: Can D simulated by H terminate normally? --- Message_ID Provided |
| Message-ID | <v2ha2h$ehmg$3@dont-email.me> |
| In reply to | #334418 |
On 5/20/2024 11:50 PM, immibis wrote: > On 20/05/24 20:28, olcott wrote: >> *This boiler plate will be the only reply* > > You know that we ignore your boiler plate, right? *Lying meets the standard of losing defamation cases* You are a liar to the extent of losing a defamation case against you. The authorities can hunt you down by your IP address. -- Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-19 19:06 -0500 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2e45j$3kf2k$1@dont-email.me> |
| In reply to | #333601 |
On 5/1/2024 7:10 PM, Richard Damon wrote:
typedef int (*ptr)(); // ptr is pointer to int function
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 }
In the above case 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.
For every H/D pair of the above template D correctly simulated by
*pure function* H cannot possibly reach its own final state at
line 06 and halt.
<snip so that Message ID links to whole message>
We can use my unique time/date stamp as an alternative.
> Remember, YOU are the one saying you are needing to change the
> definition from the classical theory, where we have things well defined.
>
> YOU have decider that H is just whatever C code you want to write for
> it, and D is the input proved. (which doesn't actually match the Linz or
> Sipser proof, but fairly close).
>
> With THAT set of definitions we have a lot of options that break your
> incorrectly assumed results.
>
> The first method has been discussed here by Flibble. While the final
> answer he got to doesn't fit the requirements, the first part of the
> method DOES show that it is possible for an H to simulate to past line 3.
>
> THe basic idea is that if H(M,d) finds that its simulation of M(d) get
> to a call to H(M,d) then rather that your idea of just saying it will
> get stuck and declair the input invalid, since there ARE a number of
> possible inputs that there is a "correct" answer that H can give to
That D is calling H does not prove recursive simulation.
That D is calling H with its same parameters does seem
to prove non-halting recursive simulation.
My new H that is a pure function of its inputs uses that
as its basis.
> match the behavior of the direct execution of M(d), what H does is fork
> its simulation into two threads.
>
We already know that D correctly simulated by H cannot possibly
reach its own simulated final state at line 06 and halt in 1 to ∞
steps of correct simulation.
We can't monkey around with illegal communication from the
executed simulator to its simulated versions of itself.
The current H does not do that and does not need to do that.
> Thread 1 continues the simulation assuming that the call to H(M,d) will
> return a 1, and if that simulation reaches a halting state, then 1 is
> the answer, and thread 2 can be abandoned.
>
> Thread 2 continues the simulation assuming that the call to H(M,d) will
> return a 0, and if that simulation reaches a provable non-halting
> pattern, then 0 is the answer, and thread 1 can be abandoned.
>
> It may be the case that BOTH answer could be correct, in which case
> depending on exactly how the forking works and how long it takes each to
> get to the answer, either answer might be given, but then, both are
> correct.
>
> It may be the case that neither answer can be shown correct, if Thread
> one can prove that it will be non-halting and Thread 2 halts, then the
> decider has proven the machine to be "contrary" to it. But it might be
> the case that it never can figure that out, and it just doesn't answer.
>
> But, in all cases, it gets past the call to H(M,d), so your criteria,
> that NO H can get there is not meet.
>
>
> The second method uses the fact that you have not restricted what H is
> allowed to do, and thus H can remember that it is simulating, and if a
It has always been the case that the actual H must be a pure function
so that it can be a computable function. There were too many discussions
on this for you not to be aware that this was always a requirement. That
it was not a written requirement in my spec you saw as a loophole. It
is good that you caught this. I don't want any loopholes.
> call to H shows that it is currently doing a simulation, just
> immediately return 0. Thus, H can actually correct simulate the
> instruction at the call to H, as they will execute just a few
> instructions testing that condition and returning, and thus not run into
> the problem you ran into where H just couldn't simulate itself because
> it got bogged down.
>
There is no way that pure function H can tell its simulated versions
to do this.
> In this case it is actually true that the direct execution of D(D)
> differs from the correct simulation of the input by H, as H is no longer
> a "Computation" per the rules of Computation Theory, but you have
> admitted that you are abandoning those, so it doesn't matter (of course
> that make trying to get your results to apply to something similar
> harder, but that is why you need to try to come up with some actual
> definitons.)
*That is a whole other sequence of hundreds and hundreds of messages*
*and replies that cannot be mixed in to this point to divert attention*
*away from this point until we have complete closure on this point*
*That is a whole other sequence of hundreds and hundreds of messages*
*and replies that cannot be mixed in to this point to divert attention*
*away from this point until we have complete closure on this point*
*That is a whole other sequence of hundreds and hundreds of messages*
*and replies that cannot be mixed in to this point to divert attention*
*away from this point until we have complete closure on this point*
>
> So, by the rules of Compuation Theory, your H is not correct, but by
> your lack of rules, your conclusion that H can not simulate past the
> call are incorrect, so you proof is also broken.
>
--
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-19 21:10 -0400 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2e7up$1g2n9$13@i2pn2.org> |
| In reply to | #334375 |
On 5/19/24 8:06 PM, olcott wrote:
> On 5/1/2024 7:10 PM, Richard Damon wrote:
>
> typedef int (*ptr)(); // ptr is pointer to int function
> 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 }
>
> In the above case 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.
>
> For every H/D pair of the above template D correctly simulated by
> *pure function* H cannot possibly reach its own final state at
> line 06 and halt.
>
Ok, so adding that H is a pure function, that means that since your
outer H(D,D) is going to return 0, all logic must be compatible with the
fact that EVERY call to H(D,D) will also eventually return 0.
Remember also, THIS D is defined to call THIS H, that does exactly the
same as the H that is deciding it.
>
> <snip so that Message ID links to whole message>
> We can use my unique time/date stamp as an alternative.
>
>> Remember, YOU are the one saying you are needing to change the
>> definition from the classical theory, where we have things well defined.
>>
>> YOU have decider that H is just whatever C code you want to write for
>> it, and D is the input proved. (which doesn't actually match the Linz
>> or Sipser proof, but fairly close).
>>
>> With THAT set of definitions we have a lot of options that break your
>> incorrectly assumed results.
>>
>> The first method has been discussed here by Flibble. While the final
>> answer he got to doesn't fit the requirements, the first part of the
>> method DOES show that it is possible for an H to simulate to past line 3.
>>
>> THe basic idea is that if H(M,d) finds that its simulation of M(d) get
>> to a call to H(M,d) then rather that your idea of just saying it will
>> get stuck and declair the input invalid, since there ARE a number of
>> possible inputs that there is a "correct" answer that H can give to
>
> That D is calling H does not prove recursive simulation.
> That D is calling H with its same parameters does seem
> to prove non-halting recursive simulation.
Nope. Try to actuall PROVE it.
Remember in your proof that if ANY H abort its simulation and returns 0,
by your restrictions ALL H will eventually abort its simulation and
return 0.
>
> My new H that is a pure function of its inputs uses that
> as its basis.
But it isn't true.
Your logic ignores that since the outer H aborts its simulation and
returns 0, each simulation of H will also eventually (if simulated long
enough) abort its simulation and return 0.
Thus, H can not use the fact that D(D) calls H(D,D) to prove non-halting
recursive simulation.
>
>> match the behavior of the direct execution of M(d), what H does is
>> fork its simulation into two threads.
>>
>
> We already know that D correctly simulated by H cannot possibly
> reach its own simulated final state at line 06 and halt in 1 to ∞
> steps of correct simulation.
Only if you break your rules and make H not a pure function, as some of
your H never return while others return 0 in finite time.
ILLEGAL.
Thus, you infinite set needs to be trimmed, and that removes the one
case where you could actual show that THAT D was non-halting, and try to
foist it off as the answer to all the others.
>
> We can't monkey around with illegal communication from the
> executed simulator to its simulated versions of itself.
> The current H does not do that and does not need to do that.
But uses illegal logic looking at not-this-H machines looking at
not-this-D inputs, which just shows that an H that aborts its simulation
before it reaches a final state doesn't reach a final state.
That does NOT prove non-halting.
And since for EVERY input of that set, we could simulate the H/D pair
with an actual UTM to determine that it WILL Halt, and in how many steps
of simulation by H, all we have shown is that every D runs for a finite
number of step larger than the finite number of steps that its
corresponding H simulated. So as a class, we can prove that all will
halt, but none will simulate to the final state.
(remember the non-aborting machine must be eliminated from the set, as
it fails the "Pure Function" definition with respect to the original H)
>
>> Thread 1 continues the simulation assuming that the call to H(M,d)
>> will return a 1, and if that simulation reaches a halting state, then
>> 1 is the answer, and thread 2 can be abandoned.
>>
>> Thread 2 continues the simulation assuming that the call to H(M,d)
>> will return a 0, and if that simulation reaches a provable non-halting
>> pattern, then 0 is the answer, and thread 1 can be abandoned.
>>
>> It may be the case that BOTH answer could be correct, in which case
>> depending on exactly how the forking works and how long it takes each
>> to get to the answer, either answer might be given, but then, both are
>> correct.
>>
>> It may be the case that neither answer can be shown correct, if Thread
>> one can prove that it will be non-halting and Thread 2 halts, then the
>> decider has proven the machine to be "contrary" to it. But it might be
>> the case that it never can figure that out, and it just doesn't answer.
>>
>> But, in all cases, it gets past the call to H(M,d), so your criteria,
>> that NO H can get there is not meet.
>>
>>
>> The second method uses the fact that you have not restricted what H is
>> allowed to do, and thus H can remember that it is simulating, and if a
>
> It has always been the case that the actual H must be a pure function
> so that it can be a computable function. There were too many discussions
> on this for you not to be aware that this was always a requirement. That
> it was not a written requirement in my spec you saw as a loophole. It
> is good that you caught this. I don't want any loopholes.
H can not be a "Computable Function" as NO PROGRAM IS A MATHEMATICAL
FUNCTION and you prove your logic is built on type errors.
I guess you C programs aren't C programs and you whole world is just a lie.
Note also, the first method, the one based on the "Flibble" method, does
NOT violate the definiton of a "pure function", and if we presume the
ability to identify that D(D) is calling H(D,D) as your design needs
(even if this is impossible as actual Turing Equivalent machines for the
actual halting problem)
>
>> call to H shows that it is currently doing a simulation, just
>> immediately return 0. Thus, H can actually correct simulate the
>> instruction at the call to H, as they will execute just a few
>> instructions testing that condition and returning, and thus not run
>> into the problem you ran into where H just couldn't simulate itself
>> because it got bogged down.
>>
>
> There is no way that pure function H can tell its simulated versions
> to do this.
Why not? You create a second copy of the execution context, that you
will by some method eventually simulate both copies of.
In one, you simulate the CALL H(D,D) as if H just returned 0, and in the
second as if H just returned 1.
This is not conceptually any harder than your current method of having
the CALL H(D,D) create a new execution frame and start simulating a new
D(D).
>
>> In this case it is actually true that the direct execution of D(D)
>> differs from the correct simulation of the input by H, as H is no
>> longer a "Computation" per the rules of Computation Theory, but you
>> have admitted that you are abandoning those, so it doesn't matter (of
>> course that make trying to get your results to apply to something
>> similar harder, but that is why you need to try to come up with some
>> actual definitons.)
>
>
> *That is a whole other sequence of hundreds and hundreds of messages*
> *and replies that cannot be mixed in to this point to divert attention*
> *away from this point until we have complete closure on this point*
Why?
Yes, if you add the H must be a pure function, then you can eleminate
this path, but you also must elminate your logic that comes up with an
impossible answer, that one instance of the pure function H(D,D) creates
non-halting infinite simulation while another returns 0.
This is why you needed to drop the Turing Equivalence rules (like your
Pure Function rule) it shows that your logic MUST be wrong.
You never ever were able to prove that H sees an actual pattern that
actually proves non-halting behavior. It can't, as the actual behavior
of D(D) is to Halt.
Your whole logic is based on trying to convince people that D(D) can be
some how correctly decider to be non-halting when it halts, which just
proves that your logic is based on LIES.
>
> *That is a whole other sequence of hundreds and hundreds of messages*
> *and replies that cannot be mixed in to this point to divert attention*
> *away from this point until we have complete closure on this point*
>
> *That is a whole other sequence of hundreds and hundreds of messages*
> *and replies that cannot be mixed in to this point to divert attention*
> *away from this point until we have complete closure on this point*
>
>>
>> So, by the rules of Compuation Theory, your H is not correct, but by
>> your lack of rules, your conclusion that H can not simulate past the
>> call are incorrect, so you proof is also broken.
>>
>
>
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-19 21:52 -0500 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2edto$3pl2i$2@dont-email.me> |
| In reply to | #334376 |
On 5/19/2024 8:10 PM, Richard Damon wrote:
> On 5/19/24 8:06 PM, olcott wrote:
>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>
>> typedef int (*ptr)(); // ptr is pointer to int function
>> 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 }
>>
>> In the above case 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.
>>
>> For every H/D pair of the above template D correctly simulated by
>> *pure function* H cannot possibly reach its own final state at
>> line 06 and halt.
>>
>
> Ok, so adding that H is a pure function, that means that since your
> outer H(D,D) is going to return 0, all logic must be compatible with the
> fact that EVERY call to H(D,D) will also eventually return 0.
>
>
> Remember also, THIS D is defined to call THIS H, that does exactly the
> same as the H that is deciding it.
>
OK, good.
>>
>> <snip so that Message ID links to whole message>
>> We can use my unique time/date stamp as an alternative.
>>
>>> Remember, YOU are the one saying you are needing to change the
>>> definition from the classical theory, where we have things well defined.
>>>
>>> YOU have decider that H is just whatever C code you want to write for
>>> it, and D is the input proved. (which doesn't actually match the Linz
>>> or Sipser proof, but fairly close).
>>>
>>> With THAT set of definitions we have a lot of options that break your
>>> incorrectly assumed results.
>>>
>>> The first method has been discussed here by Flibble. While the final
>>> answer he got to doesn't fit the requirements, the first part of the
>>> method DOES show that it is possible for an H to simulate to past
>>> line 3.
>>>
>>> THe basic idea is that if H(M,d) finds that its simulation of M(d)
>>> get to a call to H(M,d) then rather that your idea of just saying it
>>> will get stuck and declair the input invalid, since there ARE a
>>> number of possible inputs that there is a "correct" answer that H can
>>> give to
>>
>> That D is calling H does not prove recursive simulation.
>> That D is calling H with its same parameters does seem
>> to prove non-halting recursive simulation.
>
> Nope. Try to actuall PROVE it.
>
That is off-topic for this post.
All that we need know is that no D simulated by any H
ever reaches its own line 06 and halts.
I start ignoring everything you say as soon as you go off-topic.
If you said anything below that it relevant to some other post
I will read it when you post it there.
--
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-19 23:11 -0400 |
| Subject | Re: Can D simulated by H terminate normally? Message_ID Provided V2 |
| Message-ID | <v2ef1c$1g2n9$14@i2pn2.org> |
| In reply to | #334377 |
On 5/19/24 10:52 PM, olcott wrote:
> On 5/19/2024 8:10 PM, Richard Damon wrote:
>> On 5/19/24 8:06 PM, olcott wrote:
>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> 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 }
>>>
>>> In the above case 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.
>>>
>>> For every H/D pair of the above template D correctly simulated by
>>> *pure function* H cannot possibly reach its own final state at
>>> line 06 and halt.
>>>
>>
>> Ok, so adding that H is a pure function, that means that since your
>> outer H(D,D) is going to return 0, all logic must be compatible with
>> the fact that EVERY call to H(D,D) will also eventually return 0.
>>
>>
>> Remember also, THIS D is defined to call THIS H, that does exactly the
>> same as the H that is deciding it.
>>
>
> OK, good.
Right, so it doesn't matter what any other D does, it matters what THIS
D does, and this D calls aths H.
Remember, you reinstated the Computation model by enforcing Pure Functions.
>
>>>
>>> <snip so that Message ID links to whole message>
>>> We can use my unique time/date stamp as an alternative.
>>>
>>>> Remember, YOU are the one saying you are needing to change the
>>>> definition from the classical theory, where we have things well
>>>> defined.
>>>>
>>>> YOU have decider that H is just whatever C code you want to write
>>>> for it, and D is the input proved. (which doesn't actually match the
>>>> Linz or Sipser proof, but fairly close).
>>>>
>>>> With THAT set of definitions we have a lot of options that break
>>>> your incorrectly assumed results.
>>>>
>>>> The first method has been discussed here by Flibble. While the final
>>>> answer he got to doesn't fit the requirements, the first part of the
>>>> method DOES show that it is possible for an H to simulate to past
>>>> line 3.
>>>>
>>>> THe basic idea is that if H(M,d) finds that its simulation of M(d)
>>>> get to a call to H(M,d) then rather that your idea of just saying it
>>>> will get stuck and declair the input invalid, since there ARE a
>>>> number of possible inputs that there is a "correct" answer that H
>>>> can give to
>>>
>>> That D is calling H does not prove recursive simulation.
>>> That D is calling H with its same parameters does seem
>>> to prove non-halting recursive simulation.
>>
>> Nope. Try to actuall PROVE it.
>>
>
> That is off-topic for this post.
> All that we need know is that no D simulated by any H
> ever reaches its own line 06 and halts.
Nope. Make a claim, you need to prove it.
>
> I start ignoring everything you say as soon as you go off-topic.
> If you said anything below that it relevant to some other post
> I will read it when you post it there.
>
And I will ignore everything that was said when you ignored muy point.
After all, we don't care about other H's and there simulation of other
D's, we care what THIS D does.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-19 22:22 -0500 |
| Subject | Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2efle$3q0ko$1@dont-email.me> |
| In reply to | #334379 |
On 5/19/2024 10:11 PM, Richard Damon wrote:
> On 5/19/24 10:52 PM, olcott wrote:
>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>> On 5/19/24 8:06 PM, olcott wrote:
>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>
>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>> 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 }
>>>>
>>>> In the above case 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.
>>>>
>>>> For every H/D pair of the above template D correctly simulated by
>>>> *pure function* H cannot possibly reach its own final state at
>>>> line 06 and halt.
>>>>
>>>
>>> Ok, so adding that H is a pure function, that means that since your
>>> outer H(D,D) is going to return 0, all logic must be compatible with
>>> the fact that EVERY call to H(D,D) will also eventually return 0.
>>>
>>>
>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>> the same as the H that is deciding it.
>>>
>>
>> OK, good.
>
> Right, so it doesn't matter what any other D does, it matters what THIS
> D does, and this D calls aths H.
>
> Remember, you reinstated the Computation model by enforcing Pure Functions.
>
>>
>>>>
>>>> <snip so that Message ID links to whole message>
>>>> We can use my unique time/date stamp as an alternative.
>>>>
>>>>> Remember, YOU are the one saying you are needing to change the
>>>>> definition from the classical theory, where we have things well
>>>>> defined.
>>>>>
>>>>> YOU have decider that H is just whatever C code you want to write
>>>>> for it, and D is the input proved. (which doesn't actually match
>>>>> the Linz or Sipser proof, but fairly close).
>>>>>
>>>>> With THAT set of definitions we have a lot of options that break
>>>>> your incorrectly assumed results.
>>>>>
>>>>> The first method has been discussed here by Flibble. While the
>>>>> final answer he got to doesn't fit the requirements, the first part
>>>>> of the method DOES show that it is possible for an H to simulate to
>>>>> past line 3.
>>>>>
>>>>> THe basic idea is that if H(M,d) finds that its simulation of M(d)
>>>>> get to a call to H(M,d) then rather that your idea of just saying
>>>>> it will get stuck and declair the input invalid, since there ARE a
>>>>> number of possible inputs that there is a "correct" answer that H
>>>>> can give to
>>>>
>>>> That D is calling H does not prove recursive simulation.
>>>> That D is calling H with its same parameters does seem
>>>> to prove non-halting recursive simulation.
>>>
>>> Nope. Try to actuall PROVE it.
>>>
>>
>> That is off-topic for this post.
>> All that we need know is that no D simulated by any H
>> ever reaches its own line 06 and halts.
>
> Nope. Make a claim, you need to prove it.
>
*In other different post not this one*
I am using categorically exhaustive reasoning that can work
through every possibility that can possibly exist in a feasible
amount of time as long as the category is very very narrow.
Enlarge the category a tiny little bit and then the time
becomes infeasible.
The tiniest little divergence from the title of this
thread and I totally ignore and erase everything else
that you say.
--
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-20 07:24 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2fbtp$1g2n8$10@i2pn2.org> |
| In reply to | #334380 |
On 5/19/24 11:22 PM, olcott wrote:
> On 5/19/2024 10:11 PM, Richard Damon wrote:
>> On 5/19/24 10:52 PM, olcott wrote:
>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>
>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>> 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 }
>>>>>
>>>>> In the above case 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.
>>>>>
>>>>> For every H/D pair of the above template D correctly simulated by
>>>>> *pure function* H cannot possibly reach its own final state at
>>>>> line 06 and halt.
>>>>>
>>>>
>>>> Ok, so adding that H is a pure function, that means that since your
>>>> outer H(D,D) is going to return 0, all logic must be compatible with
>>>> the fact that EVERY call to H(D,D) will also eventually return 0.
>>>>
>>>>
>>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>>> the same as the H that is deciding it.
>>>>
>>>
>>> OK, good.
>>
>> Right, so it doesn't matter what any other D does, it matters what
>> THIS D does, and this D calls aths H.
>>
>> Remember, you reinstated the Computation model by enforcing Pure
>> Functions.
>>
>>>
>>>>>
>>>>> <snip so that Message ID links to whole message>
>>>>> We can use my unique time/date stamp as an alternative.
>>>>>
>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>> definition from the classical theory, where we have things well
>>>>>> defined.
>>>>>>
>>>>>> YOU have decider that H is just whatever C code you want to write
>>>>>> for it, and D is the input proved. (which doesn't actually match
>>>>>> the Linz or Sipser proof, but fairly close).
>>>>>>
>>>>>> With THAT set of definitions we have a lot of options that break
>>>>>> your incorrectly assumed results.
>>>>>>
>>>>>> The first method has been discussed here by Flibble. While the
>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>> part of the method DOES show that it is possible for an H to
>>>>>> simulate to past line 3.
>>>>>>
>>>>>> THe basic idea is that if H(M,d) finds that its simulation of M(d)
>>>>>> get to a call to H(M,d) then rather that your idea of just saying
>>>>>> it will get stuck and declair the input invalid, since there ARE a
>>>>>> number of possible inputs that there is a "correct" answer that H
>>>>>> can give to
>>>>>
>>>>> That D is calling H does not prove recursive simulation.
>>>>> That D is calling H with its same parameters does seem
>>>>> to prove non-halting recursive simulation.
>>>>
>>>> Nope. Try to actuall PROVE it.
>>>>
>>>
>>> That is off-topic for this post.
>>> All that we need know is that no D simulated by any H
>>> ever reaches its own line 06 and halts.
>>
>> Nope. Make a claim, you need to prove it.
>>
>
> *In other different post not this one*
>
> I am using categorically exhaustive reasoning that can work
> through every possibility that can possibly exist in a feasible
> amount of time as long as the category is very very narrow.
But you can't PRECISELY define the category, or what you want to reason
about, so your logic is worthless as it is baseless.
>
> Enlarge the category a tiny little bit and then the time
> becomes infeasible.
>
> The tiniest little divergence from the title of this
> thread and I totally ignore and erase everything else
> that you say.
>
Then DEFINE what you are working on.
You already admitted that you category as you initialy defined it wasn't
the category you actually meant, as you needed to add restrictions not
stated.
Note, to define HERE, you can't refer to papers not mentioned in the
problem statement as defining what you are talking about. That is the
path of lies and desception.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 13:03 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2g390$3ugq$6@dont-email.me> |
| In reply to | #334389 |
On 5/20/2024 6:24 AM, Richard Damon wrote:
> On 5/19/24 11:22 PM, olcott wrote:
>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>> On 5/19/24 10:52 PM, olcott wrote:
>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>
>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>> 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 }
>>>>>>
>>>>>> In the above case 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.
>>>>>>
>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>> line 06 and halt.
>>>>>>
>>>>>
>>>>> Ok, so adding that H is a pure function, that means that since your
>>>>> outer H(D,D) is going to return 0, all logic must be compatible
>>>>> with the fact that EVERY call to H(D,D) will also eventually return 0.
>>>>>
>>>>>
>>>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>>>> the same as the H that is deciding it.
>>>>>
>>>>
>>>> OK, good.
>>>
>>> Right, so it doesn't matter what any other D does, it matters what
>>> THIS D does, and this D calls aths H.
>>>
>>> Remember, you reinstated the Computation model by enforcing Pure
>>> Functions.
>>>
>>>>
>>>>>>
>>>>>> <snip so that Message ID links to whole message>
>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>
>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>> definition from the classical theory, where we have things well
>>>>>>> defined.
>>>>>>>
>>>>>>> YOU have decider that H is just whatever C code you want to write
>>>>>>> for it, and D is the input proved. (which doesn't actually match
>>>>>>> the Linz or Sipser proof, but fairly close).
>>>>>>>
>>>>>>> With THAT set of definitions we have a lot of options that break
>>>>>>> your incorrectly assumed results.
>>>>>>>
>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>> simulate to past line 3.
>>>>>>>
>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>> answer that H can give to
>>>>>>
>>>>>> That D is calling H does not prove recursive simulation.
>>>>>> That D is calling H with its same parameters does seem
>>>>>> to prove non-halting recursive simulation.
>>>>>
>>>>> Nope. Try to actuall PROVE it.
>>>>>
>>>>
>>>> That is off-topic for this post.
>>>> All that we need know is that no D simulated by any H
>>>> ever reaches its own line 06 and halts.
>>>
>>> Nope. Make a claim, you need to prove it.
>>>
>>
>> *In other different post not this one*
>>
>> I am using categorically exhaustive reasoning that can work
>> through every possibility that can possibly exist in a feasible
>> amount of time as long as the category is very very narrow.
>
> But you can't PRECISELY define the category, or what you want to reason
> about, so your logic is worthless as it is baseless.
>
*POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
typedef int (*ptr)(); // ptr is pointer to int function
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 }
In the above case 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);
keeps repeating (unless aborted)
Line 01:
Line 02:
Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
Simulation invariant:
D correctly simulated by H cannot possibly reach past its own line 03.
For every H/D pair of the above template D correctly simulated by pure
function (thus computable function) H cannot possibly reach its own
final state at line 06 and 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-20 20:57 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possible reach its own line 06 and halt |
| Message-ID | <v2grhq$1kiah$6@i2pn2.org> |
| In reply to | #334398 |
On 5/20/24 2:03 PM, olcott wrote:
> On 5/20/2024 6:24 AM, Richard Damon wrote:
>> On 5/19/24 11:22 PM, olcott wrote:
>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>
>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>> 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 }
>>>>>>>
>>>>>>> In the above case 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.
>>>>>>>
>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>> line 06 and halt.
>>>>>>>
>>>>>>
>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>> eventually return 0.
>>>>>>
>>>>>>
>>>>>> Remember also, THIS D is defined to call THIS H, that does exactly
>>>>>> the same as the H that is deciding it.
>>>>>>
>>>>>
>>>>> OK, good.
>>>>
>>>> Right, so it doesn't matter what any other D does, it matters what
>>>> THIS D does, and this D calls aths H.
>>>>
>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>> Functions.
>>>>
>>>>>
>>>>>>>
>>>>>>> <snip so that Message ID links to whole message>
>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>
>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>> definition from the classical theory, where we have things well
>>>>>>>> defined.
>>>>>>>>
>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>> write for it, and D is the input proved. (which doesn't actually
>>>>>>>> match the Linz or Sipser proof, but fairly close).
>>>>>>>>
>>>>>>>> With THAT set of definitions we have a lot of options that break
>>>>>>>> your incorrectly assumed results.
>>>>>>>>
>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>> simulate to past line 3.
>>>>>>>>
>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>>> answer that H can give to
>>>>>>>
>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>> That D is calling H with its same parameters does seem
>>>>>>> to prove non-halting recursive simulation.
>>>>>>
>>>>>> Nope. Try to actuall PROVE it.
>>>>>>
>>>>>
>>>>> That is off-topic for this post.
>>>>> All that we need know is that no D simulated by any H
>>>>> ever reaches its own line 06 and halts.
>>>>
>>>> Nope. Make a claim, you need to prove it.
>>>>
>>>
>>> *In other different post not this one*
>>>
>>> I am using categorically exhaustive reasoning that can work
>>> through every possibility that can possibly exist in a feasible
>>> amount of time as long as the category is very very narrow.
>>
>> But you can't PRECISELY define the category, or what you want to
>> reason about, so your logic is worthless as it is baseless.
>>
>
> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>
> typedef int (*ptr)(); // ptr is pointer to int function
> 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 }
>
> In the above case 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);
>
> keeps repeating (unless aborted)
> Line 01:
> Line 02:
> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>
> Simulation invariant:
> D correctly simulated by H cannot possibly reach past its own line 03.
>
> For every H/D pair of the above template D correctly simulated by pure
> function (thus computable function) H cannot possibly reach its own
> final state at line 06 and halt.
>
Which thus doesn't correct simulate the call to H (since H proves that a
call to itself as H(D,D) WILL return the value 0)
Since you have an incorrect step in your simulation, you arguement is
just unsound.
Note, a correct simulation of a call to H(D,D) is NOT another simulation
of D(D), as H SIMULATES its input, not run it, and even if the
"simulation" is "debug stepping", the H still retains control, so if H
will abort its simulation at some point, such simulation is not
"infinite", even if the out H gives up before it gets to that point.
[toc] | [prev] | [next] | [standalone]
| From | olcott <polcott333@gmail.com> |
|---|---|
| Date | 2024-05-20 21:25 -0500 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2h0nm$d87m$1@dont-email.me> |
| In reply to | #334405 |
On 5/20/2024 7:57 PM, Richard Damon wrote:
> On 5/20/24 2:03 PM, olcott wrote:
>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>> On 5/19/24 11:22 PM, olcott wrote:
>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>
>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>> 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 }
>>>>>>>>
>>>>>>>> In the above case 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.
>>>>>>>>
>>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>> line 06 and halt.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>> eventually return 0.
>>>>>>>
>>>>>>>
>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>
>>>>>>
>>>>>> OK, good.
>>>>>
>>>>> Right, so it doesn't matter what any other D does, it matters what
>>>>> THIS D does, and this D calls aths H.
>>>>>
>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>> Functions.
>>>>>
>>>>>>
>>>>>>>>
>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>
>>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>>> definition from the classical theory, where we have things well
>>>>>>>>> defined.
>>>>>>>>>
>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>
>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>
>>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>>> simulate to past line 3.
>>>>>>>>>
>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of just
>>>>>>>>> saying it will get stuck and declair the input invalid, since
>>>>>>>>> there ARE a number of possible inputs that there is a "correct"
>>>>>>>>> answer that H can give to
>>>>>>>>
>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>
>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>
>>>>>>
>>>>>> That is off-topic for this post.
>>>>>> All that we need know is that no D simulated by any H
>>>>>> ever reaches its own line 06 and halts.
>>>>>
>>>>> Nope. Make a claim, you need to prove it.
>>>>>
>>>>
>>>> *In other different post not this one*
>>>>
>>>> I am using categorically exhaustive reasoning that can work
>>>> through every possibility that can possibly exist in a feasible
>>>> amount of time as long as the category is very very narrow.
>>>
>>> But you can't PRECISELY define the category, or what you want to
>>> reason about, so your logic is worthless as it is baseless.
>>>
>>
>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>
>> typedef int (*ptr)(); // ptr is pointer to int function
>> 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 }
>>
>> In the above case 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);
>>
>> keeps repeating (unless aborted)
>> Line 01:
>> Line 02:
>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>
>> Simulation invariant:
>> D correctly simulated by H cannot possibly reach past its own line 03.
>>
>> For every H/D pair of the above template D correctly simulated by pure
>> function (thus computable function) H cannot possibly reach its own
>> final state at line 06 and halt.
>>
>
> Which thus doesn't correct simulate the call to H
*Counter-factual, try again*
We are not talking about any of your misconceptions the term:
"simulate" is expressly defined.
This is the only post about this subject that I will respond
to from you. I have to paint half of my house and empty my
garage within about a week.
If you can find some source that conclusively proves that
not all pure functions are computable functions I would like
to see it. All of the experts that I could find seem to agree
that all pure functions in C would be computable functions
by a Turing machine.
I skimmed the rest of your posts and they were mostly
trying to get away with changing the subject to divert
attention away from the point at hand in this subject line.
I will not discuss and theory of computation stuff with you
until after you quit playing head games with the subject
of this post.
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
*THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
On 5/19/2024 12:17 PM, Richard Damon wrote:
> On 5/19/24 9:59 AM, olcott wrote:
>> Richard has stated that he thinks that an example of
>> {D never simulated by H} ∈ {every D simulated by H}
>
> No, the H that didn't simulate its input shows that
> *once you allow H to not be required to be correct*,
> that we can then have a trivial function that is
> "just as correct" (since wrong answers were allowed).
I am glad to see that it turned out that you were not a liar.
That was very reassuring. Seems to be a liar to me until I see
proof otherwise is not the same thing as calling you a liar.
If you think it is fun to endlessly talk in circles then
you will get very little dialogue with 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-20 22:39 -0400 |
| Subject | Re: Every D correctly simulated by H cannot possibly reach its own line 06 and halt |
| Message-ID | <v2h1gp$1kiah$14@i2pn2.org> |
| In reply to | #334414 |
On 5/20/24 10:25 PM, olcott wrote:
> On 5/20/2024 7:57 PM, Richard Damon wrote:
>> On 5/20/24 2:03 PM, olcott wrote:
>>> On 5/20/2024 6:24 AM, Richard Damon wrote:
>>>> On 5/19/24 11:22 PM, olcott wrote:
>>>>> On 5/19/2024 10:11 PM, Richard Damon wrote:
>>>>>> On 5/19/24 10:52 PM, olcott wrote:
>>>>>>> On 5/19/2024 8:10 PM, Richard Damon wrote:
>>>>>>>> On 5/19/24 8:06 PM, olcott wrote:
>>>>>>>>> On 5/1/2024 7:10 PM, Richard Damon wrote:
>>>>>>>>>
>>>>>>>>> typedef int (*ptr)(); // ptr is pointer to int function
>>>>>>>>> 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 }
>>>>>>>>>
>>>>>>>>> In the above case 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.
>>>>>>>>>
>>>>>>>>> For every H/D pair of the above template D correctly simulated by
>>>>>>>>> *pure function* H cannot possibly reach its own final state at
>>>>>>>>> line 06 and halt.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Ok, so adding that H is a pure function, that means that since
>>>>>>>> your outer H(D,D) is going to return 0, all logic must be
>>>>>>>> compatible with the fact that EVERY call to H(D,D) will also
>>>>>>>> eventually return 0.
>>>>>>>>
>>>>>>>>
>>>>>>>> Remember also, THIS D is defined to call THIS H, that does
>>>>>>>> exactly the same as the H that is deciding it.
>>>>>>>>
>>>>>>>
>>>>>>> OK, good.
>>>>>>
>>>>>> Right, so it doesn't matter what any other D does, it matters what
>>>>>> THIS D does, and this D calls aths H.
>>>>>>
>>>>>> Remember, you reinstated the Computation model by enforcing Pure
>>>>>> Functions.
>>>>>>
>>>>>>>
>>>>>>>>>
>>>>>>>>> <snip so that Message ID links to whole message>
>>>>>>>>> We can use my unique time/date stamp as an alternative.
>>>>>>>>>
>>>>>>>>>> Remember, YOU are the one saying you are needing to change the
>>>>>>>>>> definition from the classical theory, where we have things
>>>>>>>>>> well defined.
>>>>>>>>>>
>>>>>>>>>> YOU have decider that H is just whatever C code you want to
>>>>>>>>>> write for it, and D is the input proved. (which doesn't
>>>>>>>>>> actually match the Linz or Sipser proof, but fairly close).
>>>>>>>>>>
>>>>>>>>>> With THAT set of definitions we have a lot of options that
>>>>>>>>>> break your incorrectly assumed results.
>>>>>>>>>>
>>>>>>>>>> The first method has been discussed here by Flibble. While the
>>>>>>>>>> final answer he got to doesn't fit the requirements, the first
>>>>>>>>>> part of the method DOES show that it is possible for an H to
>>>>>>>>>> simulate to past line 3.
>>>>>>>>>>
>>>>>>>>>> THe basic idea is that if H(M,d) finds that its simulation of
>>>>>>>>>> M(d) get to a call to H(M,d) then rather that your idea of
>>>>>>>>>> just saying it will get stuck and declair the input invalid,
>>>>>>>>>> since there ARE a number of possible inputs that there is a
>>>>>>>>>> "correct" answer that H can give to
>>>>>>>>>
>>>>>>>>> That D is calling H does not prove recursive simulation.
>>>>>>>>> That D is calling H with its same parameters does seem
>>>>>>>>> to prove non-halting recursive simulation.
>>>>>>>>
>>>>>>>> Nope. Try to actuall PROVE it.
>>>>>>>>
>>>>>>>
>>>>>>> That is off-topic for this post.
>>>>>>> All that we need know is that no D simulated by any H
>>>>>>> ever reaches its own line 06 and halts.
>>>>>>
>>>>>> Nope. Make a claim, you need to prove it.
>>>>>>
>>>>>
>>>>> *In other different post not this one*
>>>>>
>>>>> I am using categorically exhaustive reasoning that can work
>>>>> through every possibility that can possibly exist in a feasible
>>>>> amount of time as long as the category is very very narrow.
>>>>
>>>> But you can't PRECISELY define the category, or what you want to
>>>> reason about, so your logic is worthless as it is baseless.
>>>>
>>>
>>> *POINT TO ANY ACTUAL MISTAKE OR AMBIGUITY WITH THIS VERSION*
>>>
>>> typedef int (*ptr)(); // ptr is pointer to int function
>>> 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 }
>>>
>>> In the above case 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);
>>>
>>> keeps repeating (unless aborted)
>>> Line 01:
>>> Line 02:
>>> Line 03: simulated D(D) invokes simulated H(D,D) that simulates D(D)
>>>
>>> Simulation invariant:
>>> D correctly simulated by H cannot possibly reach past its own line 03.
>>>
>>> For every H/D pair of the above template D correctly simulated by
>>> pure function (thus computable function) H cannot possibly reach its
>>> own final state at line 06 and halt.
>>>
>>
>> Which thus doesn't correct simulate the call to H
>
> *Counter-factual, try again*
> We are not talking about any of your misconceptions the term:
> "simulate" is expressly defined.
And how did your H "Correctly" simulate the call to H?
>
> This is the only post about this subject that I will respond
> to from you. I have to paint half of my house and empty my
> garage within about a week.
>
> If you can find some source that conclusively proves that
> not all pure functions are computable functions I would like
> to see it. All of the experts that I could find seem to agree
> that all pure functions in C would be computable functions
> by a Turing machine.
So, you just don't understand that "Computable Function" is a
Term-of-the-art to talk about the mathematical mapping, an NOT the
algorithm that shows the mapping is computable.
One key point that make "Pure Functions" not necessarily equivalent to a
Turing Machine is the ability to get "hidden inputs" from things like
their own program address, something a Turing Machine doesn't have.
This is what made your H and H1, even though "exact copies" of each
other (by using x86 instructions that access this otherwise hidden
information in a way that make it not obvious), act differently, when
two identical copies of Turing Machines ALWAYS act the same for the same
input.
So, YOU YOURSELF have provided the counter-example, but were too stupid
to understand it.
>
> I skimmed the rest of your posts and they were mostly
> trying to get away with changing the subject to divert
> attention away from the point at hand in this subject line.
>
> I will not discuss and theory of computation stuff with you
> until after you quit playing head games with the subject
> of this post.
>
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
> *THINKING THE WRONG ANSWERS ARE ALLOWED IS A HEAD GAME*
>
> On 5/19/2024 12:17 PM, Richard Damon wrote:
> > On 5/19/24 9:59 AM, olcott wrote:
> >> Richard has stated that he thinks that an example of
> >> {D never simulated by H} ∈ {every D simulated by H}
> >
> > No, the H that didn't simulate its input shows that
> > *once you allow H to not be required to be correct*,
> > that we can then have a trivial function that is
> > "just as correct" (since wrong answers were allowed).
>
> I am glad to see that it turned out that you were not a liar.
> That was very reassuring. Seems to be a liar to me until I see
> proof otherwise is not the same thing as calling you a liar.
Which just makes you a pathological liar, because you have a reckless
disregard for the truth, PRESUMING without the need of evidence.
Note, you positively claimed for two weeks that I did not say what I
claimed to. Since I showed that I did, that you PROVES you LIED for
those two weeks, and you just admitted that you were doing so.
Note, "Honest Mistake" does not ignore what someone says.
>
> If you think it is fun to endlessly talk in circles then
> you will get very little dialogue with me.
>
[toc] | [prev] | [next] | [standalone]
Page 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
Back to top | Article view | sci.logic
csiph-web