Deutsch English Français Italiano |
<S8CcnRadHexfe8X7nZ2dnZfqnPqdnZ2d@brightview.co.uk> View for Bookmarking (what is this?) Look up another Usenet article |
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.