Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connections
Warning: mysqli::query(): Couldn't fetch mysqli in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\index.php on line 66
Article <_BmdneCBVewsOMX7nZ2dnZfqn_adnZ2d@brightview.co.uk>
Deutsch   English   Français   Italiano  
<_BmdneCBVewsOMX7nZ2dnZfqn_adnZ2d@brightview.co.uk>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!Xl.tags.giganews.com!local-1.nntp.ord.giganews.com!nntp.brightview.co.uk!news.brightview.co.uk.POSTED!not-for-mail
NNTP-Posting-Date: Thu, 30 May 2024 16:13:36 +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>
From: Mike Terry <news.dead.person.stones@darjeeling.plus.com>
Date: Thu, 30 May 2024 17:13:36 +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: <v3a5ha$1oamo$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <_BmdneCBVewsOMX7nZ2dnZfqn_adnZ2d@brightview.co.uk>
Lines: 125
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-bW9uuhzf2IDIOAYPfrOJgzoCRjYARs4tEkJ4c3J6dpaLqiR8py0/iZAE3+8rYsla+GthkzlYWVS726T!tOPuY8hq7gndbB1hgWmUmOjtlxeSlvPwhc7zFmunGzCWBuhhRJFtrhGBTlWQY+iUMXnjhz+WAMCn!Mi1dvBg5+iOYyT+erCBxLJlAUbb2
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: 6973

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.

> 
> 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.