home bbs files messages ]

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