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,702 of 59,235   
   olcott to Richard Damon   
   Re: I have just proven the error of all    
   29 Jul 25 20:24:40   
   
   XPost: comp.theory, sci.logic   
   From: polcott333@gmail.com   
      
   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.   
      
      
   --   
   Copyright 2025 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