Path: ...!Xl.tags.giganews.com!local-2.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 30 May 2024 20:51:14 +0000
Subject: Re: D correctly simulated by H cannot possibly halt --- templates and
 infinite sets --- deciders
Newsgroups: comp.theory,sci.logic
References: <v3501h$lpnh$1@dont-email.me> <v3a3a3$1nupq$1@dont-email.me>
 <eTSdneRdKMnYCcX7nZ2dnZfqn_GdnZ2d@brightview.co.uk>
 <v3a5ha$1oamo$1@dont-email.me>
 <_BmdneCBVewsOMX7nZ2dnZfqn_adnZ2d@brightview.co.uk>
 <v3ab1i$1paor$1@dont-email.me>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Thu, 30 May 2024 21:51:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Firefox/91.0 SeaMonkey/2.53.17
MIME-Version: 1.0
In-Reply-To: <v3ab1i$1paor$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <S8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d@brightview.co.uk>
Lines: 152
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-E09dA53+KShnZZojf1l7fsnUMJKf/5lpjhKkvYmDj0gvFWtt297KlTVOrBYGGo4pWx5miaSXYIgYs0I!K3w6whY0qip/Cj8mKRgOyu45okfX6LguJcTv4OU9uGpzmaNNNydLgTX4byLTEF78cBbdbccO76jJ!C1S+rkiHn/bJZxljsQeXbyRhFh7p
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Bytes: 8310

On 30/05/2024 17:55, olcott wrote:
> On 5/30/2024 11:13 AM, Mike Terry wrote:
>> On 30/05/2024 16:21, olcott wrote:
>>> On 5/30/2024 9:59 AM, Mike Terry wrote:
>>>> On 30/05/2024 15:43, olcott wrote:
>>>>> On 5/28/2024 11:16 AM, olcott wrote:
>>>>>>
>>>>>> When Ĥ is applied to ⟨Ĥ⟩
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞
>>>>>> Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn
>>>>>>
>>>>>> *Formalizing the Linz Proof structure*
>>>>>> ∃H  ∈ Turing_Machines
>>>>>> ∀x  ∈ Turing_Machines_Descriptions
>>>>>> ∀y  ∈ Finite_Strings
>>>>>> such that H(x,y) = Halts(x,y)
>>>>>>
>>>>>
>>>>> A decider computes the mapping from finite string inputs to
>>>>> its own accept or reject state.
>>>>>
>>>>> A decider does not and cannot compute the mapping from
>>>>> Turing_Machine inputs to its own accept or reject state.
>>>>>
>>>>> Halts(x,y) would report on the direct execution of x(y) thus ignores
>>>>> the pathological behavior of x correctly simulated by pure function H.
>>>>> This makes Halts(x,y) an incorrect measure of the correctness of H(x,y).
>>>>>
>>>>> This is easier to see when we can see every single detail of all of
>>>>> the steps as an x86 execution trace of D correctly simulated by pure
>>>>> function H.
>>>>>
>>>>> typedef int (*ptr)();  // ptr is pointer to int function in C
>>>>> 00       int HH(ptr p, ptr i);
>>>>> 01       int DD(ptr p)
>>>>> 02       {
>>>>> 03         int Halt_Status = HH(p, p);
>>>>> 04         if (Halt_Status)
>>>>> 05           HERE: goto HERE;
>>>>> 06         return Halt_Status;
>>>>> 07       }
>>>>> 08
>>>>> 09       int main()
>>>>> 10       {
>>>>> 11         HH(DD,DD);
>>>>> 12         return 0;
>>>>> 13       }
>>>>>
>>>>> *Begin simulation of DD by HH*
>>>>> Begin Local Halt Decider Simulation   Execution Trace Stored at:113075
>>>>> [00001c22][00113061][00113065] 55         push ebp
>>>>> [00001c23][00113061][00113065] 8bec       mov ebp,esp
>>>>> [00001c25][0011305d][00103031] 51         push ecx
>>>>> [00001c26][0011305d][00103031] 8b4508     mov eax,[ebp+08]
>>>>> [00001c29][00113059][00001c22] 50         push eax         ; push DD
>>>>> [00001c2a][00113059][00001c22] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001c2d][00113055][00001c22] 51         push ecx         ; push DD
>>>>> [00001c2e][00113051][00001c33] e80ff7ffff call 00001342    ; call HH
>>>>> New slave_stack at:14da95
>>>>> [00001c22][0015da89][0015da8d] 55         push ebp
>>>>> [00001c23][0015da89][0015da8d] 8bec       mov ebp,esp
>>>>> [00001c25][0015da85][0014da59] 51         push ecx
>>>>> [00001c26][0015da85][0014da59] 8b4508     mov eax,[ebp+08]
>>>>> [00001c29][0015da81][00001c22] 50         push eax         ; push DD
>>>>> [00001c2a][0015da81][00001c22] 8b4d08     mov ecx,[ebp+08]
>>>>> [00001c2d][0015da7d][00001c22] 51         push ecx         ; push DD
>>>>> [00001c2e][0015da79][00001c33] e80ff7ffff call 00001342    ; call HH
>>>>> Local Halt Decider: Recursive Simulation Detected Simulation Stopped
>>>>>
>>>>> DD correctly simulated by HH cannot possibly reach its own simulated
>>>>> final state at line 06 in any number of steps including an infinite
>>>>> number of steps because DD correctly simulated by HH remains stuck in
>>>>> recursive simulation.
>>>>>
>>>>
>>>> Your HH/DD above are nonsense functions - you have admitted that HH uses static variables 
>>>> deliberately to detect whether it is the outer (unsimulated) HH or an inner (simulated) HH.  In 
>>>> the event of the latter it branches into a completely different code branch from the outer HH, 
>>>> so the "simulated" behaviour of HH is /nothing like/ the behaviour of outer HH.
>>>>
>>>> Any traces from such a HH/DD are completely worthless.
>>>>
>>>> You know this, and yet you still claim to have a "fully operational" code etc..  So that is a 
>>>> LIE, just like when you claimed to have a fully operation TM implementing your ideas a few years 
>>>> back.
>>>>
>>>>
>>>> Mike.
>>>
>>> The fact that it uses static variables has no effect what-so-ever
>>> on the fact that DD correctly simulated by HH cannot possibly
>>> reach its own simulated final state at line 06.
>>
>> But DD is NOT correctly simulated by HH.  HH uses static variables to modify its behaviour when 
>> simulated, so the "simulation" is rubbish.
>>
> 
> Merely from the C source code it can be verified that DD correctly
> simulated by pure simulator HH or pure function HH cannot possibly
> reach its own simulated final state at line 06 and halt because
> every DD remains stuck in recursive simulation the whole time that
> it is correctly simulated.
> 
> Thus the fact that one implementation of HH is is not a pure function
> makes no ultimate difference in this analysis and is a mere distraction
> away from the point.

You introduced the trace into the discussion, as evidence of something.  But the trace is produced 
by a /specific/ HH/DD pair which are incorrectly implemented, and so are evidence of nothing.

> 
>>>
>>> It is very easy to verify that DD correctly simulated by HH cannot
>>> possibly reach its own simulated final state and halt on the basis
>>> of the execution trace that I provided and this x86 source-code for DD.
>>>
>>> _DD()
>>> [00001c22] 55         push ebp
>>> [00001c23] 8bec       mov ebp,esp
>>> [00001c25] 51         push ecx
>>> [00001c26] 8b4508     mov eax,[ebp+08]
>>> [00001c29] 50         push eax        ; push DD
>>> [00001c2a] 8b4d08     mov ecx,[ebp+08]
>>> [00001c2d] 51         push ecx        ; push DD
>>> [00001c2e] e80ff7ffff call 00001342   ; call HH
>>> [00001c33] 83c408     add esp,+08
>>> [00001c36] 8945fc     mov [ebp-04],eax
>>> [00001c39] 837dfc00   cmp dword [ebp-04],+00
>>> [00001c3d] 7402       jz 00001c41
>>> [00001c3f] ebfe       jmp 00001c3f
>>> [00001c41] 8b45fc     mov eax,[ebp-04]
>>> [00001c44] 8be5       mov esp,ebp
>>> [00001c46] 5d         pop ebp
>>> [00001c47] c3         ret
>>> Size in bytes:(0038) [00001c47]
>>>
>>> You are correct that HH is not a pure function yet this has no effect
>>> on the provided execution trace.
>>
>> Nonsense - if HH is not correctly simulating DD+HH then the trace is just rubbish.
>>
>> Mike.
>>
> 
> That HH is not a pure function does not show that the simulation
> is incorrect because:

It shows that the simulation is "rubbish" and any trace produced by it can just be ignored.

Err, that's it.

Mike.