XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   On 7/30/2025 5:59 AM, Richard Damon wrote:   
   > On 7/29/25 11:12 PM, olcott wrote:   
   >> On 7/29/2025 8:51 PM, Richard Damon wrote:   
   >>> On 7/29/25 9:24 PM, olcott wrote:   
   >>>> On 7/29/2025 5:37 PM, Richard Damon wrote:   
   >>>>> On 7/29/25 12:53 PM, olcott wrote:   
   >>>>>> On 7/28/2025 8:56 PM, Richard Damon wrote:   
   >>>>>>> On 7/28/25 7:58 PM, olcott wrote:   
   >>>>>>>> On 7/28/2025 6:49 PM, Richard Damon wrote:   
   >>>>>>>>> On 7/28/25 7:20 PM, olcott wrote:   
   >>>>>>>>>> On 7/28/2025 5:57 PM, Richard Damon wrote:   
   >>>>>>>>>>> On 7/28/25 9:54 AM, olcott wrote:   
   >>>>>>>>>>>> On 7/28/2025 8:21 AM, joes wrote:   
   >>>>>>>>>>>>> Am Mon, 28 Jul 2025 07:11:11 -0500 schrieb olcott:   
   >>>>>>>>>>>>>> On 7/28/2025 2:30 AM, joes wrote:   
   >>>>>>>>>>>>>>> Am Sun, 27 Jul 2025 21:58:05 -0500 schrieb olcott:   
   >>>>>>>>>>>>>>>> On 7/27/2025 9:48 PM, Richard Damon wrote:   
   >>>>>>>>>>>>>>>>> On 7/27/25 8:20 PM, olcott wrote:   
   >>>>>>>>>>>>>   
   >>>>>>>>>>>>>>>>>> When DDD is emulated by HHH1 it need not emulate   
   >>>>>>>>>>>>>>>>>> itself at all.   
   >>>>>>>>>>>>>>>>> But "itself" doesn't matter to x86 instructions,   
   >>>>>>>>>>>>>>>> By itself I mean the exact same machine code bytes at   
   >>>>>>>>>>>>>>>> the exact same   
   >>>>>>>>>>>>>>>> machine address.   
   >>>>>>>>>>>>>>> Yeah, so when you change HHH to abort later, you also   
   >>>>>>>>>>>>>>> change DDD.   
   >>>>>>>>>>>>>> HHH is never changed.   
   >>>>>>>>>>>>   
   >>>>>>>>>>>>> It is changed in the hypothetical unaborted simulation. HHH   
   >>>>>>>>>>>>> is reporting   
   >>>>>>>>>>>>> on UTM(HHH', DDD) where HHH' calls UTM(DDD), and not on the   
   >>>>>>>>>>>>> halting DDD,   
   >>>>>>>>>>>>> and definitely not on HHH(DDD), itself.   
   >>>>>>>>>>>>>   
   >>>>>>>>>>>>   
   >>>>>>>>>>>> All halt deciders are required to predict the behavior   
   >>>>>>>>>>>> of their input. HHH does correctly predict that DDD correctly   
   >>>>>>>>>>>> simulated by HHH cannot possibly reach its own simulated   
   >>>>>>>>>>>> "return" instruction final halt state.   
   >>>>>>>>>>>>   
   >>>>>>>>>>>   
   >>>>>>>>>>> How is it a "correct prediction" if it sees something   
   >>>>>>>>>>> different than what that DDD does.   
   >>>>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> What DDD does is keep calling HHH(DDD) in recursive   
   >>>>>>>>>> simulation until HHH kills this whole process.   
   >>>>>>>>>   
   >>>>>>>>> But the behavior of the program continues past that (something   
   >>>>>>>>> you don't seem to understand) and that behavior will also have   
   >>>>>>>>> its HHH terminate the DDD it is simulating and return 0 to DDD   
   >>>>>>>>> and then Halt.   
   >>>>>>>>>   
   >>>>>>>>> Your problem is you don't understand that the simulating HHH   
   >>>>>>>>> doesn't define the behavior of DDD, it is the execution of DDD   
   >>>>>>>>> that defines what a correct simulation of it is.   
   >>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>>> Remember, to have simulated that DDD, it must have include   
   >>>>>>>>>>> the code of the HHH that it was based on, which is the HHH   
   >>>>>>>>>>> that made the prediction, and thus returns 0, so DDD will halt.   
   >>>>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> We are not asking: Does DDD() halt.   
   >>>>>>>>>> That is (as it turns out) an incorrect question.   
   >>>>>>>>>   
   >>>>>>>>> No, that is EXACTLY the question.   
   >>>>>>>>>   
   >>>>>>>>> I guess you are just admitting that you whole world is based on   
   >>>>>>>>> LYING about what things are supposed to be.   
   >>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> Turing machines cannot directly report on the behavior   
   >>>>>>>>>> of other Turing machines they can at best indirectly   
   >>>>>>>>>> report on the behavior of Turing machines through the   
   >>>>>>>>>> proxy of finite string machine descriptions such as ⟨M⟩.   
   >>>>>>>>>   
   >>>>>>>>> Right, and HHH was given the equivalenet of (M) by being given   
   >>>>>>>>> the code of *ALL* of DDD   
   >>>>>>>>>   
   >>>>>>>>> I guess you don't understand that fact, even though you CLAIM   
   >>>>>>>>> the input is the proper representation of DDD.   
   >>>>>>>>>   
   >>>>>>>>>>   
   >>>>>>>>>> Thus the behavior specified by the input finite string   
   >>>>>>>>>> overrules and supersedes the behavior of the direct   
   >>>>>>>>>> execution.   
   >>>>>>>>>   
   >>>>>>>>> No, it is DEFINED to be the behavior of the direct execution of   
   >>>>>>>>> the program it represent.   
   >>>>>>>>>   
   >>>>>>>>   
   >>>>>>>> *That has always been the fatal flaw of all of the proofs*   
   >>>>>>>   
   >>>>>>> No, your failure to follow the rules is what makes you just a liar.   
   >>>>>>>   
   >>>>>>   
   >>>>>> _DDD()   
   >>>>>> [00002192] 55         push ebp   
   >>>>>> [00002193] 8bec       mov ebp,esp   
   >>>>>> [00002195] 6892210000 push 00002192  // push DDD   
   >>>>>> [0000219a] e833f4ffff call 000015d2  // call HHH   
   >>>>>> [0000219f] 83c404     add esp,+04   
   >>>>>> [000021a2] 5d         pop ebp   
   >>>>>> [000021a3] c3         ret   
   >>>>>> Size in bytes:(0018) [000021a3]   
   >>>>>>   
   >>>>>> When the above code is in the same memory space as HHH   
   >>>>>> such that DDD calls HHH(DDD) and then HHH does emulate   
   >>>>>> itself emulating DDD then this does specify recursive   
   >>>>>> emulation.   
   >>>>>>   
   >>>>>> Anyone or anything that disagrees would be disagreeing   
   >>>>>> with the definition of the x86 language.   
   >>>>>>   
   >>>>>   
   >>>>> So, if HHH accesses that memory, it becomes part of the input.   
   >>>>>   
   >>>>   
   >>>> It becomes part of the input in the sense that the   
   >>>> correct simulation of the input to HHH(DDD) is not   
   >>>> the same as the correct simulation of the input to   
   >>>> HHH1(DDD) because DDD only calls HHH(DDD) and does   
   >>>> not call HHH1(DDD).   
   >>>>   
   >>>> DDD correctly simulated by HHH cannot possibly   
   >>>> halt thus HHH(DDD)==0 is correct.   
   >>>>   
   >>>> DDD correctly simulated by HHH1 does halt thus   
   >>>> HHH(DDD)==1 is correct.   
   >>>>   
   >>>>   
   >>>   
   >>> It either *IS* or it *ISN'T* there is no middle.   
   >>>   
   >>   
   >> This just occurred to me:   
   >> *HHH(DDD)==0 is also correct for another different reason*   
   >>   
   >> Even if we construed the HHH that DDD calls a part of the   
   >> program under test it is true that neither the simulated   
   >> DDD nor the simulated HHH cannot possibly reach their own   
   >> final halt state.   
   >>   
   >>   
   >   
   > Sure they do, when correctly simulated. What doens't happne is that the   
   > PARTIAL simulation (and thus not correct) of HHH can't reach that state.   
   >   
      
   _DDD()   
   [0000219e] 55             push ebp   
   [0000219f] 8bec           mov ebp,esp   
   [000021a1] 689e210000     push 0000219e   
   [000021a6] e843f4ffff     call 000015ee   
   [000021ab] 83c404         add esp,+04   
   [000021ae] 5d             pop ebp   
   [000021af] c3             ret   
   Size in bytes:(0018) [000021af]   
      
   We have been over this too many times. If DDD was   
   incorrectly emulated by HHH then you could show   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)