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,283 of 59,235   
   Richard Damon to olcott   
   Re: People are still trying to get away    
   29 Jun 24 15:08:56   
   
   XPost: comp.theory, sci.logic   
   From: richard@damon-family.org   
      
   On 6/29/24 2:47 PM, olcott wrote:   
   > On 6/29/2024 1:38 PM, Richard Damon wrote:   
   >> On 6/29/24 2:06 PM, olcott wrote:   
   >>> On 6/29/2024 12:59 PM, Richard Damon wrote:   
   >>>> On 6/29/24 1:17 PM, olcott wrote:   
   >>>>> On 6/29/2024 11:45 AM, Richard Damon wrote:   
   >>>>>> On 6/29/24 12:09 PM, olcott wrote:   
   >>>>>>> People are still trying to get away with disagreeing with   
   >>>>>>> the semantics of the x86 language. That is isomorphic to   
   >>>>>>> trying to get away with disagreeing with arithmetic.   
   >>>>>>   
   >>>>>> Nope, we are not disagreeing with the semantics of the x86   
   >>>>>> language, we are disagreeing with your misunderstanding of how it   
   >>>>>> works.   
   >>>>>>   
   >>>>>>>   
   >>>>>>> typedef void (*ptr)();   
   >>>>>>> int H0(ptr P);   
   >>>>>>>   
   >>>>>>> void Infinite_Loop()   
   >>>>>>> {   
   >>>>>>>    HERE: goto HERE;   
   >>>>>>> }   
   >>>>>>>   
   >>>>>>> void Infinite_Recursion()   
   >>>>>>> {   
   >>>>>>>    Infinite_Recursion();   
   >>>>>>> }   
   >>>>>>>   
   >>>>>>> void DDD()   
   >>>>>>> {   
   >>>>>>>    H0(DDD);   
   >>>>>>> }   
   >>>>>>>   
   >>>>>>> int main()   
   >>>>>>> {   
   >>>>>>>    H0(Infinite_Loop);   
   >>>>>>>    H0(Infinite_Recursion);   
   >>>>>>>    H0(DDD);   
   >>>>>>> }   
   >>>>>>>   
   >>>>>>> Every C programmer that knows what an x86 emulator is knows   
   >>>>>>> that when H0 emulates the machine language of Infinite_Loop,   
   >>>>>>> Infinite_Recursion, and DDD that it must abort these emulations   
   >>>>>>> so that itself can terminate normally.   
   >>>>>>   
   >>>>>> No the x86 language "knows" NOTHING about H0 being a x86 emulator.   
   >>>>>> It is just a function that maybe happens to be a partial x86   
   >>>>>> emulator, but that is NOT a fundamental result of it being H0.   
   >>>>>>   
   >>>>>>>   
   >>>>>>> When this is construed as non-halting criteria then simulating   
   >>>>>>> termination analyzer H0 is correct to reject these inputs as   
   >>>>>>> non-halting by returning 0 to its caller.   
   >>>>>>   
   >>>>>> It is construed as non-halting BECAUSE it has been shown that your   
   >>>>>> H0 *WILL* terminate its PARTIAL emulation of the code it is   
   >>>>>> emulating and returning.   
   >>>>>>   
   >>>>>>>   
   >>>>>>> Simulating termination analyzers must report on the behavior   
   >>>>>>> that their finite string input specifies thus H0 must report   
   >>>>>>> that DDD correctly emulated by H0 remains stuck in recursive   
   >>>>>>> simulation.   
   >>>>>>   
   >>>>>> Right, so H0 is REQUIRED to return, and thus if the termination   
   >>>>>> analyser knows that H0 is a termination analyzer it knows that the   
   >>>>>> call to H0 MUST return, and thus DDD must be a terminating program.   
   >>>>>>   
   >>>>>> An H0 that doesn't know this, and can't figure out that H0 will   
   >>>>>> return, but just keeps emulating H0 emulating its input will just   
   >>>>>> fail to meet its own requirement to return.   
   >>>>>>   
   >>>>>>>   
   >>>>>>> >>>>>> 10/13/2022>   
   >>>>>>>      If simulating halt decider H correctly simulates its input D   
   >>>>>>>      until H correctly determines that its simulated D would never   
   >>>>>>>      stop running unless aborted then   
   >>>>>>>   
   >>>>>>>      H can abort its simulation of D and correctly report that D   
   >>>>>>>      specifies a non-halting sequence of configurations.   
   >>>>>>> >>>>>> 10/13/2022>   
   >>>>>>   
   >>>>>> Right, and the only definition Professor Sipser uses for "Correct   
   >>>>>> Simulation" is a simulation that EXACTLY REPRODUCES the behavior   
   >>>>>> of the directly executed program represented by the input. Your H   
   >>>>>> doesn't do that, nor correctly predicts the behavior of such a   
   >>>>>> simulation of the input (since that behavior is to halt) so it can   
   >>>>>> never proper avail itself of the second paragraph, so does so   
   >>>>>> erroneously getting the wrong answer.   
   >>>>>>   
   >>>>>>>   
   >>>>>>> People are trying to get away with disagreeing with the semantics   
   >>>>>>> of the x86 language by disagreeing that   
   >>>>>>>   
   >>>>>>> The call from DDD to HHH(DDD) when N steps of DDD are correctly   
   >>>>>>> emulated by any pure function x86 emulator HHH cannot possibly   
   >>>>>>> return.   
   >>>>>>   
   >>>>>> Except that the "N Steps of DDD correctly emulated" is NOT the   
   >>>>>> definition of the "behavior" of the input DDD.   
   >>>>>>   
   >>>>>> "inputs" Do not have "behavoir", that is a property of a program,   
   >>>>>> so the input only "represents" that program, in this case the   
   >>>>>> program DDD.   
   >>>>>>   
   >>>>>   
   >>>>> *According to the professor Sipser approved criteria YES IT IS*   
   >>>>>   
   >>>>   
   >>>> Nope. Where dp you see that in what he says? Remember, you need to   
   >>>> interpret the words by what he means them to say.   
   >>>>   
   >>>> His ONLY definition of "Correct Simulation" is a simulation that   
   >>>> exactly recreates the behavior of the program described by the   
   >>>> input, and that in one that does not stop its simulation. So, NOT   
   >>>> your "N Step"   
   >>>>   
   >>>   
   >>> *N steps of correct simulation are specified*   
   >>> H correctly simulates its input D until H   
   >>> H correctly simulates its input D until H   
   >>> H correctly simulates its input D until H   
   >>> H correctly simulates its input D until H   
   >>   
   >> Which does not determine the ACTUAL behavor   
   >>   
   >   
   > _DDD()   
   > [00002172] 55               push ebp      ; housekeeping   
   > [00002173] 8bec             mov ebp,esp   ; housekeeping   
   > [00002175] 6872210000       push 00002172 ; push DDD   
   > [0000217a] e853f4ffff       call 000015d2 ; call HHH(DDD)   
   > [0000217f] 83c404           add esp,+04   
   > [00002182] 5d               pop ebp   
   > [00002183] c3               ret   
   > Size in bytes:(0018) [00002183]   
   >   
   > That you already know that it does prove that DDD correctly   
   > emulated by HHH would never stop running unless aborted   
   > or out-of-memory error   
   >   
   > *proves that you are trying to get away with a bald-faced lie*   
   > I really hope that you repent before it is too late.   
   >   
   >   
      
   Nope, just shows your stupidity, as the above code has NO defined   
   behavior as it accesses code that is not defined by it.   
      
   When you include that code, your claim is non-sense, as the definition   
   of HHH becomes FIXED AND DEFINED and your terminology meaningless.   
      
   "unless" implies choices, which no longer exist, as HHH has been   
   specifed so it does or it doesn't.   
      
   If HHH DOES abort its simulation and returns, then DDD DOES return.   
      
   "DDD correctly emulated by HHH", when that emulation is allowed to be   
   partial, is NOT a valid property for the input, as it is not a property   
   of JUST the input. So, the ONLY possible meanings are that you are   
   defining HHH to NEVER abort, at which poiht the "unless" is meaningless   
   as something defined to never abort can't abort, or that you are just   
   using wrong definitons of terms.   
      
      
   [continued in next message]   
      
   --- 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