Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.ai.philosophy    |    Perhaps we should ask SkyNet about this    |    59,235 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 57,273 of 59,235    |
|    olcott to Richard Damon    |
|    Re: H(D,D) cannot even be asked about th    |
|    15 Jun 24 16:56:43    |
      XPost: comp.theory, sci.logic       From: polcott333@gmail.com              On 6/15/2024 11:33 AM, Richard Damon wrote:       > 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.       >              When we can see that D correctly simulated by H cannot possibly       reach its simulated final state at machine address [00000d1d]       after one recursive simulation and the same applies for 2,3,...N       recursive simulations then we can abort the simulated input and       correctly report that D correctly simulated by H DOES NOT HALT.              That you call this a guess seems disingenuous at least and dishonest       at most. it is as if you are denying mathematical induction.              > 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).       >              Yes and when I say 2 + 3 = 5 you are not free to disagree and be       correct.              > This is the ONLY thing that matches your definition of Correct Simulation.       >              The x86 language defines the semantics of correct simulation that       you denigrate this to my opinion seems disingenuous at least and       dishonest at most.              > 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.       >              It is the sequence of x86 instructions specified by the machine       language of D that is being examined. We cannot simply ignore       the recursive simulation effect of the call from D to H(D,D).       That D makes this call is what make D correctly simulated by H       fail to halt.              > 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.       >              That D calls H in recursive simulation is what makes D correctly       simulated by H never halt. H is merely watching what D does       until it see that D correctly simulated by H cannot possibly halt       on the basis of something just like mathematical induction.              We can directly see that 1,2,3...N recursive simulations do       not result in D correctly simulated by H reaching its simulated       final state of [00000d1d].              > 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.       >              When Ĥ is applied to ⟨Ĥ⟩       Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qy ∞       Ĥ.q0 ⟨Ĥ⟩ ⊢* embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩ ⊢* Ĥ.qn              (a) Ĥ copies its input ⟨Ĥ⟩       (b) Ĥ invokes embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩       (c) embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩       (d) simulated ⟨Ĥ⟩ copies its input ⟨Ĥ⟩       (e) simulated ⟨Ĥ⟩ invokes simulated embedded_H ⟨Ĥ⟩ ⟨Ĥ⟩       (f) simulated embedded_H simulates ⟨Ĥ⟩ ⟨Ĥ⟩       (g) goto (d) with one more level of simulation              When embedded_H is a UTM we can see that Ĥ ⟨Ĥ⟩ never halts.              This by itself proves that the same thing applies when embedded_H       is based on a UTM that stops simulating and rejects its input at       any point after it sees              two complete simulations show a pair of identical TMD's are       simulating a pair of identical inputs. We can see this thus       proving recursive simulation.                     > 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]       >>       >              --       Copyright 2024 Olcott "Talent hits a target no one else can hit; Genius       hits a target no one else can see." Arthur Schopenhauer              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca