Path: ...!weretis.net!feeder9.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: Richard Damon <richard@damon-family.org>
Newsgroups: comp.theory,sci.logic,comp.ai.philosophy
Subject: Re: H(D,D) cannot even be asked about the behavior of D(D) V3
 ---IGNORING ALL OTHER REPLIES
Date: Sat, 15 Jun 2024 12:33:14 -0400
Organization: i2pn2 (i2pn.org)
Message-ID: <v4kfoa$2218$19@i2pn2.org>
References: <v4kf3h$3h3iu$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sat, 15 Jun 2024 16:33:14 -0000 (UTC)
Injection-Info: i2pn2.org;
	logging-data="67624"; mail-complaints-to="usenet@i2pn2.org";
	posting-account="diqKR1lalukngNWEqoq9/uFtbkm5U+w3w6FQ0yesrXg";
User-Agent: Mozilla Thunderbird
X-Spam-Checker-Version: SpamAssassin 4.0.0
Content-Language: en-US
In-Reply-To: <v4kf3h$3h3iu$7@dont-email.me>
Bytes: 4090
Lines: 71

On 6/15/24 12:22 PM, olcott wrote:
> On 6/13/2024 8:24 PM, Richard Damon wrote:
>  > On 6/13/24 11:32 AM, olcott wrote:
>  >>
>  >> It is contingent upon you to show the exact steps of how H computes
>  >> the mapping from the x86 machine language finite string input to
>  >> H(D,D) using the finite string transformation rules specified by
>  >> the semantics of the x86 programming language that reaches the
>  >> behavior of the directly executed D(D)
>  >>
>  >
>  > Why? I don't claim it can.
> 
> The first six steps of this mapping are when instructions
> at the machine address range of [00000cfc] to [00000d06]
> are simulated/executed.
> 
> After that the behavior of D correctly simulated by H diverges
> from the behavior of D(D) because the call to H(D,D) by D
> correctly simulated by H cannot possibly return to D.

Nope, the steps of D correctly simulated by H will EXACTLY match the 
steps of D directly executed, until H just gives up and guesses.

By your defintions, the ONLY correct simulation of D by H MUST follow 
the call H into the instructions of H, and then continue there forever 
until H either gives up simulating, or it happens to simulate the return 
from H to D (which doesn't look like it will ever happen).

This is the ONLY thing that matches your definition of Correct Simulation.

And that means that you definition of the "Input" is shown to be 
incorrect (or insufficient for H to do what it needs to do). The input 
CAN NOT be just those instructions shown below, but must include the 
contents of ALL the memory used by the program.

And this comes out naturally, because to ask about the program 
represented by the input, the input needs to represent a FULL PROGRAM, 
which includes ALL of the algorithm used by the code, so ALL of the program.

Thus, the input "D", includes its copy of H that was DEFINED by Linz and 
Sipser to be part of the machine, and when you do your logic, you can't 
change that code.

If this means that you can't do your imagining of different Hs, then you 
can't do that operation.

Any H you imagine being given the same input as this H, must see the 
code for that original H, not the new hypothetical H you are imagining.

Which sort of blows you your whole argument.

> 
> _D()
> [00000cfc](01) 55          push ebp
> [00000cfd](02) 8bec        mov ebp,esp
> [00000cff](03) 8b4508      mov eax,[ebp+08]
> [00000d02](01) 50          push eax       ; push D
> [00000d03](03) 8b4d08      mov ecx,[ebp+08]
> [00000d06](01) 51          push ecx       ; push D
> [00000d07](05) e800feffff  call 00000b0c  ; call H
> [00000d0c](03) 83c408      add esp,+08
> [00000d0f](02) 85c0        test eax,eax
> [00000d11](02) 7404        jz 00000d17
> [00000d13](02) 33c0        xor eax,eax
> [00000d15](02) eb05        jmp 00000d1c
> [00000d17](05) b801000000  mov eax,00000001
> [00000d1c](01) 5d          pop ebp
> [00000d1d](01) c3          ret
> Size in bytes:(0034) [00000d1d]
>